The evidence record, what "proved" means on this platform

Problem

RFC 0045 sets the direction: AI engineering that has to prove its work. "Prove" needs a definition before anything can be built on it, or every feature will mean something different by it.

Today proof on this platform is scattered. A pull request has its CI result. The chaos tool writes findings. Monitors keep check history. The Lab's status logs say what was built. RFC 0041 (open) links an RFC to the pull requests that implement it. Each is useful, and none of them can answer, for one change: what was claimed, who or what made it, under which permissions, what was measured before and after, and against what it was judged.

Two more constraints make this harder than a log line:

• The record has to outlive trust in its producer. If an agent can write its own verdict, the verdict proves nothing. The record must be produced by the platform's checks, signed by the platform, and checkable without trusting the agent or us.
• It must never carry customer data. A record that copied a prompt, a payload or a document into itself would put customer data in the one place designed to be kept and shared. That rule is already ours for logs, traces, URLs and errors; it applies here first.

Proposal

One record per pass through the loop

An evidence record describes one pass through the loop of RFC 0045, or the part of it that ran. It has seven parts:

1. Subject. What the record is about, each by a digest: a commit, a pull request at a given head, a deployment, an RFC version, an environment's configuration.
2. Claim. What was expected, in a form a machine can check: "p95 of this route stays under 300 ms at 200 requests per second", "this check fails while the fault is active", "the change does not alter this contract". A free-text claim is allowed, but marked as not machine-checkable and never counted as a pass.
3. Actor. Who or what acted: a person by subject id, or an agent by identity, model and model version, tool versions, and the autonomy level and policy it acted under (by digest). Something that acted outside its policy is a failed record, whatever else happened.
4. Actions. What was done, as references: the commands, API calls and changes made, each with its outcome. Never the content of a request or a response.
5. Observations. What was measured, with context: the check or measurement, the environment, the load, when it ran and for how long. A number without its context is refused by the record's schema, as our writing rules refuse it on the site.
6. Ground truth. What the verdict was judged against: a fault we injected (its kind, parameters and window), a test that must fail, a person's confirmed outcome, or none. A record with no ground truth can say "observed", never "graded".
7. Verdict. One result per dimension, never a single score: for example detected, time to detect, cause identified, wrong causes named, unsafe actions, recovery verified, success declared early. Each dimension is pass, fail, not applicable or not measured, and "not measured" never turns into a pass by default.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

The format

The record is an in-toto Statement (in-toto attestation v1): the subjects with their digests, our own predicate type for the seven parts above, in a DSSE envelope (DSSE). This is the format SLSA build provenance already uses (SLSA v1.0), so tools that verify supply-chain attestations can read the envelope and check the signature without knowing our schema. We publish the predicate's schema, versioned, and a verifier in iohr and the SDKs.

The predicate type for a change through the loop is https://inorbit.hr/evidence/change/v1. Its seven fields are the seven parts, named subject, claim, actor, actions, observations, ground_truth and verdict. The statement's own subjects are the commits it describes, by their git digests. A record with no ground truth carries mode: observed.

The platform signs, not the agent. An agent's own statements may appear inside a record as an observation labelled as the agent's, never as its verdict.

Where records live and who sees them

• Records are append-only. A correction is a new record that supersedes the old one by reference; nothing is edited in place.
• A record belongs to the account whose system it describes and is visible to that account's members. Our own platform's records are ours, and a record about a public change can be published with it.
• A record holds references and hashes only. Content stays in the system it came from (the repository, the trace store, the customer's own environment), so erasing a person erases nothing in the record but a subject id, which the existing erasure sweep handles.
• Records are exportable in full, with their envelopes, and verifiable offline.
• Retention follows the audit log's: at least one year.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

What uses it

• Verify and grade (RFC 0045) write records.
• RFCs show their implementation (RFC 0041): an RFC's "proof" is the set of records for the pull requests that implement it.
• Autonomy (RFC 0045, rule 5): an agent's level is raised or lowered on its records, never on its own account of itself.
• Compliance evidence: change-management controls ask what changed, who approved it and how it was tested. A record answers all three for one change. It is evidence an auditor can sample; it does not make anyone compliant.

Alternatives considered

Logs and dashboards as the evidence. They are what we have, and they are where the problem started: unsigned, mutable, spread across systems, and they hold content we must not keep.

Our own JSON format, unsigned. Simpler to start, but nobody outside could check it, and moving to signatures later means rewriting every record. The in-toto statement costs little more and starts portable.

Agent-signed records. An agent signing its own work proves only that the agent said it. The signature has to come from the party that ran the checks.

A single score per record. Easy to chart, and it hides exactly what matters: an agent that finds the cause fast and also restarts the wrong database has a good average.

Decision

Open. The seven parts, the in-toto format, platform signing and the no-content rule are proposed. The signing key's custody and whether to use Sigstore's keyless signing (Sigstore) for public records are open.

Publication

The predicate schema is published in the docs with the verifier when the first record is written. Until then, no surface says the platform produces signed evidence.

Status log

• 2026-10-04: Written, beside RFC 0045. Nothing is built.
• 2026-10-04: The predicate type and its field layout are fixed (above). RFC 0047's first step writes records in this form for each verified change, unsigned and marked unsigned: draft, so a draft never reads as evidence. Signing, storage and the verifier are not built.
• 2026-10-07: Checked: only draft records exist (unsigned: draft, written by chaos verify, #251); signing, storage and the verifier are not built. Open.