What Is Verified
adapterOS produces execution receipts for every inference run. Each receipt contains a cryptographic record of the computation: input hash, model identity and version, active adapter configuration, execution parameters (seed, quantization policy, tolerance bounds), and output hash. These fields are hash-linked into a tamper-evident chain, so any modification or deletion is structurally detectable.
This means an auditor, compliance officer, or downstream system can answer specific questions with cryptographic evidence: which model processed the input, which adapter was active, which configuration was in effect, and whether the recorded output matches what was produced. These are provenance questions, and the receipt format is designed to answer them clearly.
What Is Not Verified
Receipts do not evaluate the content of model outputs. They cannot determine whether an output is factually correct, logically sound, contextually appropriate, or safe for a given use case. A receipt proves that a specific computation occurred with specific inputs and configuration. It does not prove that the result of that computation is right.
This is not a gap to close; it is a deliberate boundary. Model output correctness depends on training data quality, task-specific evaluation, and domain expertise outside the runtime. Conflating provenance with correctness leads to overclaiming, which adapterOS is designed to avoid.
Determinism Boundary
Deterministic execution in adapterOS applies to adapter routing and policy evaluation: given identical inputs and identical hardware configuration, the same adapter path is selected and the same execution policy is enforced. This is achieved through pinned versions, fixed seeds, and Q15 quantization boundaries.
GPU-level floating-point arithmetic introduces hardware-dependent variance that cannot be eliminated without unacceptable performance cost. adapterOS handles this by documenting and bounding the variance rather than hiding it. Tolerance declarations are part of the receipt, so downstream systems know the precision envelope of any given run. The hardware variance documentation specifies the exact scope.
Where Human Oversight Applies
Verification supports human review; it does not replace it. The receipt chain provides evidence for review workflows: what ran, when, with what configuration, and what output was produced. Whether that output is acceptable for a given use case remains a decision for domain experts, compliance officers, and quality assurance processes.
Regulatory frameworks like CMMC and AS9100 require documented, auditable processes. They do not require AI outputs to be correct in an absolute sense. adapterOS provides the process documentation and audit trail. The organization provides the review, validation, and sign-off.
Receipt Field Reference
Each execution receipt includes: input content hash (SHA-256), model identifier and pinned version, active adapter identifier and version, execution parameters (seed, quantization policy, tolerance bounds), equipment profile of the executing device, output content hash (SHA-256), timestamp, and position in the hash-linked log chain. The full receipt format and verification workflow are documented in Execution Receipts and the Problem of Citable AI.