Evidence and trust
What an evidence receipt can and cannot prove, why trust roots belong to the verifier, and the three levels that matter most.
Don't trust the agent. Check the evidence.
What evidence is
For every change the runtime writes an append-only chain of records under the runner identity: decisions, actions, denials, verifier results and outcomes. The chain is exported as a portable evidence/v1 directory that the open verifier checks offline, without the engine and without network access. Decisions that were denied are in the chain, which is why a clean-looking history is more than a list of successes.
Evidence chain inspector
What does verification actually establish, and which inputs does it depend on?
Hash-linked records (drawing 6 of 12)
- seq 1link
previous_record_hash empty (sequence 1)
signature verified - seq 2link
links to previous
signature verified - seq 3link
links to previous
signature verified - seq 4link
links to previous
signature verified - seq 5link
links to previous
signature verified - seq 12 (head)link
terminal state: Closed
signature verified
attestation.json
signed summary, re-derived from the chain
verifiedhead-checkpoint + inclusion proof
checked under the pinned log key and origin
verifiedVerifier inputs (what you bring, not what the export says)
- ✓ pinned runner key(s)
- ✓ pinned log key + origin
- provenance/signers.json and any checkpoint in the export are claims, not trust.
numi evidence verify --runner-key keys/runner.pub --log-key keys/log.pub --log-origin numinance.test/log --complete exports/closed-author
simulated output, shape as in the real CLI
change: chg_01010101010101010101010101010101 records: 12, head sha256:8dec4e3d… state: ended Closed level: verified chain: records link, hash and end as stated signatures: verified under the pinned runner keys anchor: head proved under the pinned log attestation: signed, re-derived from the chain result: verified
exit 0
level: verifiedexit 0
Provenance and chain integrity hold under keys and a log you pinned.
What this does NOT prove, at any level
- The code is correct.
- The tests are thorough.
- The model reasoned well.
- Completeness against a compromised host: events it never logged are not in the chain.
Level verified, exit 0. No findings or weaknesses.
Text description
Illustrative and simulated: no export is read. The rules are those of docs/evidence/verification.md; the baseline report is the real output of the open verifier on the conformance export exports/closed-author.
- You must choose exactly one key mode. Pinned runner keys (
--runner-key) are the only way to reachverified.--trust-bundle-keystakes the keys the export claims and tops out atself-consistent.--skip-signaturestops out atunauthenticated. - A pinned log (
--log-keywith--log-origin) is needed to prove the head. Without it the result isunanchored(exit 5) unless--allow-unanchoredis given. - Any finding makes the level
failed(exit 3). Edit or remove a record:chain_broken. A chain signed by a key you did not pin:signer_untrusted. With keys from the export or signatures skipped, the same forged-but-consistent chain is not caught, which is why those levels are weaker. - Exit codes: 0 verified, 3 failed, 5 consistent but weaker than verified.
Verified does not prove the code is correct, the tests are thorough, the model reasoned well, or that a compromised host logged every event.
Trust roots belong to the verifier
A chain whose hashes agree proves only that the records agree with each other, and anyone can build one. Trust comes from keys and a log origin the caller chooses in advance. There is no built-in root, and a key supplied by the export itself never earns the top result.
Three levels to know
The verifier reports a level. The three that matter most:
| Level | Meaning | How you get it |
|---|---|---|
verified | The chain links and hashes correctly, signatures check under keys you pinned, and the head is proved under the log you pinned. | Pin runner key, log key and log origin. |
self-consistent | The export agrees with itself, but its signatures were checked only against keys the export states. | --trust-bundle-keys. |
unauthenticated | No signature was checked. | --skip-signatures. |
Other levels (failed, incomplete, unsigned, unanchored) cover broken, partial or unanchored exports. The exit code is 0 for verified, 5 for a consistent export weaker than verified, and 3 for failure. See trust levels for the full list.
What a receipt can prove
Under keys you pinned, verified shows that:
- the records were produced by the runner identity you trust and have not been altered or reordered;
- the chain ended as it states, for example
Closed; - parts declared not applicable, such as deployment at PR level, are consistent with the chain;
- a particular decision, denial or verifier result is on the record.
What it cannot prove
verified is about provenance and integrity. It does not prove:
- that the code is correct or the tests are thorough;
- that the model reasoned well;
- that a compromised host logged every event it should have;
- statements the export marks
unsourced, such as credential scopes or network policy when no broker or proxy statement is attested.
Treat evidence as the basis for a good review, not a substitute for one. No page on this site is an audit or certification claim.
Failure modes
A wrong pinned key produces FAIL signer_untrusted, exit 3. A missing key mode is a usage error, because the verifier never defaults to trusting the export.
Next steps
Reliability and recovery
How independent verification, bounded repair, canary releases, rollback and escalation limit the cost of a wrong change.
Open versus proprietary
The three distinct objects - the open numi CLI, the numinance-spec repository and the proprietary runtime - and where the Apache-2.0 boundary sits.