Evidence levels: what it means for an agent action to be evidenced
Not every line in an agent log carries the same weight. A record the agent wrote about itself is weaker than a record backed by an independent system signal, which is weaker still than a record a named human explicitly accepted. Proofroom labels every material event with exactly one of three evidence levels: self_reported (self-reported), system_confirmed (system-confirmed), and operator_confirmed (operator-confirmed). The label answers "who says so?" without pretending all records are equal.
Why levels exist
Buyers, reviewers, and operators routinely over-read undifferentiated activity logs. A timestamp and a sentence look authoritative even when nothing independent corroborates them. Evidence levels are an honesty device: they separate claims from corroboration and from human acceptance, so a sceptical reader can calibrate trust to the actual source of each record.
Mixing levels in one export without labelling them is a common failure mode. Proofroom renders the level on every event, receipt, and coverage surface that references the action.
self_reported (self-reported)
The agent or its host stack submitted the event. No independent system has confirmed that the underlying action took place as described. This is the default level and the weakest of the three.
Self-reported records are useful for narrative, debugging, and reconstructing what the agent believed it did. They are easy to fabricate if the recorder is compromised or mistaken, and they should be read as claims that may still need corroboration when stakes are high.
Typical examples: the agent logs that it drafted a summary, chose a tool, or completed a workflow step, with no external reference attached.
system_confirmed (system-confirmed)
An independent system signal backs the record. The confirming system is not the same process that authored the self-report. Proofroom checks that the referenced external object exists and captures metadata about it. Confirmation covers existence and reference integrity, not the quality, wisdom, or correctness of the action.
Typical examples: a GitHub pull request referenced as github:pr:owner/repo#42 is confirmed via the GitHub API; a webhook from a third-party system acknowledges that an outbound message was accepted; a hash matches an object in external storage. Confirmation checks that a named reference on an existing receipt resolves externally. It does not scan GitHub for actions that were never receipted. Test-origin confirmations do not raise a room to action_verified.
System-confirmed is stronger than self-reported because something outside the agent's narrative vouched for a fact. It is still not a human judgment about whether the action should have happened.
operator_confirmed (operator-confirmed)
A named human resolved an approval for this action through the approval inbox or another configured operator channel. This is the strongest of the three levels for governance questions: a specific person accepted responsibility for that step at that time.
Operator-confirmed does not mean the underlying work was wise, accurate, or fit for every purpose. It means a human explicitly stood behind the record as something they authorised and accepted into the trail.
Typical examples: a refund above a threshold was queued, and an operator resolved the approval; free-text destined for a public proof room was reviewed before publication; a critical action required human sign-off before proceeding.
What chain integrity does and does not mean
Every event in Proofroom is hash-linked to the previous event. Recomputing the chain from stored rows detects alteration after write. A valid chain means the stored history has not been tampered with since ingestion. It does not mean the history is complete, nor that every event is true. Completeness depends on what was submitted. Truth at the self-reported level depends on the agent and its instrumentation.
Third parties can check chain heads and individual receipts without calling the Proofroom API. See Signed Action Receipts and /verify.
Choosing the right level
Send the honest level at capture time. Do not label an event system_confirmed unless you supply a reference Proofroom can check against an external system. Do not label an event operator_confirmed unless a named human actually resolved an approval tied to that action. Promoting a claim after the fact without the underlying signal is worse than leaving it self-reported.
When in doubt, use self_reported. Honesty about weakness preserves credibility when stronger levels appear.
How Proofroom approaches this
Proofroom implements exactly these three levels in code and refuses invented vocabulary. There are no additional evidence levels in the product model. Marketing copy, documentation, and live proof rooms are checked in CI so terminology cannot drift back to deprecated ladders.
Every Action Receipt states its evidence level, what the level does and does not establish, and a mandatory limitation note. Approval workflows promote eligible events to operator_confirmed when a named operator resolves them. External reference checks promote eligible events to system_confirmed when the reference validates.
Coverage scoring treats evidence level as structural input: buyers can see whether a room relies heavily on self-reported narrative or includes system and operator corroboration. The score is descriptive, not a quality judgment.
For what the trail cannot establish regardless of level, see What an AI agent audit trail cannot tell you.