Don’t trust us. Verify.
Evidence, not assertions.
Every adapterOS answer ships a signed execution receipt your own team can re-check — without calling us, and without the source material ever leaving your environment. This page shows exactly what that evidence looks like and how to verify it.
Anatomy of an execution receipt
A receipt binds the input, the pinned model and adapter, the exact configuration, and the output into one signed, hash-chained record. It contains hashes, not your data — so it is safe to export and verify, and proves what ran without disclosing what was read.
{
"schema": "adapteros.receipt/v1",
"focus": "stk.contracts-review.7f2a",
"policy_pack": "legal-review@3",
"input_hash": "blake3:9f2c1e…a83b",
"model": "pinned:llama-3.1-8b-instruct@sha256:4c1d…e90",
"adapter": "sealed:contracts-lora@v7",
"config": { "seed": 42, "temperature": 0.0, "sampler": "greedy" },
"output_hash": "blake3:c3d47f…1180",
"proof_tier": "evidence",
"citations": ["doc:MSA-v4#sec-8.2", "doc:addendum#p3"],
"timestamp": "2026-05-03T14:30:11Z",
"prev_receipt": "blake3:71a0…5e2",
"signature": "ed25519:5b8e…9c4"
}Illustrative structure; values are examples. A live receipt is signed by your deployment and emitted with every answer. Read the full technical briefing →
Every answer carries a proof tier
adapterOS never hides uncertainty. Each answer is labelled with how well it is backed — so a reviewer knows, at a glance, whether it can stand on its own.
exact
The answer is a verbatim, located span from the source set. Nothing inferred.
evidence
The answer is supported by cited sources a reviewer can open and check.
lineage
The answer is derived across sources; the derivation path is recorded for review.
degraded
Sources could not be persisted or fully grounded. The answer downgrades visibly rather than pretending confidence.
Verify it yourself
Verification needs only the receipt and the inputs you already hold. None of these steps contact MLNavigator.
- Recompute the hashes. Hash your input and the output with BLAKE3 and confirm they match input_hash and output_hash.
- Check the signature. Verify the Ed25519 signature against your deployment’s published key. A valid signature binds input, model, config, and output together.
- Walk the chain. Each receipt references the previous one’s hash. Following prev_receipt makes any insertion, deletion, or reorder detectable.
- Replay. Re-run the pinned model and adapter with the recorded config and seed; a matching output_hash proves the result is reproducible, not a one-off.
- Confirm no egress. Watch the network: core inference makes no outbound calls and sends no telemetry. The boundary is observable, not promised.
- Match the SBOM. Compare the deployment’s SBOM against what is actually installed, so you know exactly what is running.
The replay invariant
same input + pinned model/adapter + recorded config/seed → identical output_hash
Determinism is what turns a receipt from a claim into a check. Because the same conditions reproduce the same output, anyone holding the input can confirm the answer independently — today, or years later in an audit.
What a pilot leaves you with
A pilot is scoped to one workflow, but the evidence is yours to keep and to show your reviewers — whether or not you proceed.
Receipt set
Signed, hash-chained receipts for every answer produced during the pilot.
Replay harness
The pinned model, adapter, and config needed to reproduce any answer on demand.
Verification runbook + SBOM
The exact steps and the component manifest your security team uses to attest to the deployment.
This page practices what it sells
We hold our own surfaces to the same discipline: this page declares the exact build it was served from, so its provenance is checkable too.
served from build 0.2.1 · commit baa6427bc9fc631f223a6cec34ba594e04b5c625
See it on your own documents
A fixed-scope pilot runs adapterOS on one of your workflows, in your environment, and hands back the receipts and replay harness to verify everything above for yourself.