The Agentic Evidence Model

How every transformation produces portable, replayable, independently-verifiable proof. Evidence is not logging.

  • Document: APQC-EVIDENCE-007 — Evidence Model
  • Status: Draft 0.1
  • Version: 0.1
  • Date: 2026-07-02
  • Editor / Authoring body: H33.ai, Inc.

This specification defines the Evidence Graph — the answer to what is proven? in the three-graph core. Every migration and governance framework in existence says, in effect, "log it." None specifies that each transformation MUST produce cryptographically-verifiable, portable, replayable proof that a third party can confirm without trusting the producer. That gap is what this document closes. Written to stand alone and remain valid regardless of implementer.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

  • APQC-CORE-001 — Constitution. APQC-GLOSSARY-000 — Glossary. APQC-AUTH-006 — Authority Model.

0.2 Informative References

  • APQC-MODEL-003 — Conceptual Model. APQC-LIFECYCLE-004 — Lifecycle (Stages 8–9, Verification and Evidence).
  • APQC-AUTH-006 (the authority each evidence object binds); APQC-ARCH-005; APQC-MATURITY-008; APQC-REFERENCE-010.

0.4 Conformance Dependencies

  • Depends on: APQC-CORE-001, APQC-GLOSSARY-000, APQC-MODEL-003, APQC-AUTH-006.
  • Referenced by: APQC-ARCH-005, APQC-MATURITY-008, APQC-REFERENCE-010.

1. Purpose

A transformation of critical infrastructure is only trustworthy to the degree it can be proven — after the fact, by someone who was not present and does not trust the actor. This specification defines the objects, structure, and properties of that proof: what an Evidence Object is, how Evidence Objects link into a graph and a chain, and the invariants (integrity, completeness, portability, retention, survivability, independent verification, continuity, replay) that separate evidence from logging.

The distinction that governs the entire document — stated once here as a definition and repeated throughout as a normative refrain — is this: a log (APQC-GLOSSARY-000) is a chronological record a system emits about itself, for its own operators; it is editable, issuer-bound, and mortal with its system. Evidence is the body of portable, independently-verifiable artifacts recording what was actually done, confirmable without trusting — or contacting — the producer, for the full retention horizon. Evidence is not logging. The two are not points on a spectrum; they are different kinds of object with different trust models, and the whole discipline of Agentic Post-Quantum Conversion rests on requiring the second and never accepting the first as a substitute.

This specification is deliberately implementation-independent. It defines what evidence is and the properties it MUST satisfy. It defines no wire format, no algorithm, no product. Where a concrete realization is illustrative, it appears in §14 (Reference implementation), which is informative; §§2–13 are normative.

1.1 Relationship to verification, validation, proof, and attestation

Because these four terms are routinely conflated and because that conflation is exactly the error this discipline exists to prevent, their relationship to evidence is fixed here in the canonical sense of APQC-GLOSSARY-000, and MUST be used precisely throughout any conforming work:

  • Verification is the act of confirming that a transformation occurred as intended, independently of the actor. Verification is performed against evidence.
  • Validation is confirming a transformed asset is correct and functional against its specification (e.g., known-answer tests, interoperability). Validation is a technique employed during verification and may itself be recorded as evidence, but it is not evidence.
  • Attestation is the signing mechanism that binds a claim to the authority under which it was made. Attestation produces proof.
  • Proof is the portable artifact an attestation yields — the thing a third party checks. Evidence is the body of such proofs, structured into the Evidence Graph.

In one line: attestation produces proof; proof is checked by verification; validation is one check verification performs; evidence is the durable, graph-structured corpus of proofs. None of these is a log.

2. Evidence is not logging

This sentence is normative and recurs throughout: evidence is not logging. This section makes the distinction rigorous, because the single most common way a transformation program fails to be provable is by treating its logs as though they were evidence.

2.1 What a log is

A log is a record a system emits about itself, for its own operators. Three properties define it:

  1. It is editable by whoever controls the system. A log line is a row in a table, a line in a file, an event in a stream. The party that operates the system can append, truncate, rewrite, or delete it. Write-once storage and access controls reduce the ease of tampering but do not change the trust model: you are trusting the operator not to tamper, and trusting their controls to have held.
  2. It is meaningful only inside its own context. A log line references internal identifiers, schemas, and clocks. Removed from the emitting system, it degrades to an opaque string. It carries no self-contained way to be understood or checked by an outsider.
  3. It is mortal with its system. When the vendor is acquired, the database is decommissioned, the format is deprecated, or the team turns over, the log's meaning and verifiability go with them. A log five years after the system that wrote it is, at best, an assertion by a dead witness.

A log answers "what did this system say happened." It requires you to trust the system.

2.2 What evidence is

Evidence is a portable, cryptographically-verifiable artifact that binds what changed, when, and under whose authority, and that a third party can confirm without trusting — or contacting — the producer, for the full retention horizon. Evidence answers "what provably happened," and it survives the producer.

The word provably is load-bearing. Evidence does not ask to be believed. It carries, within itself and against public parameters, everything a skeptical outsider needs to check it — and it is constructed so that any alteration of what it binds destroys the check. The root of trust is moved off the producer's word and onto mathematics and independent anchors.

2.3 Point-by-point comparison

The distinction is not stylistic. Across every dimension an auditor cares about, a log and an Evidence Object behave differently:

 Dimension        │ Log                              │ Evidence Object
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Editability      │ Mutable by the operator;         │ Immutable in effect: any edit breaks
                  │ tampering may leave no trace.    │ the signature and is detectable.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Trust model      │ Trust the issuer and their       │ Trust mathematics + public parameters;
                  │ controls ("we didn't change it").│ the issuer's good faith is not required.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Portability      │ Meaningful only in its native    │ Self-describing; verifiable anywhere,
                  │ system/schema/clock.             │ by anyone, outside the origin system.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Verifiability    │ "Check" = re-reading what the    │ Cryptographic verification against a
                  │ system asserts; no independent   │ commitment, a signature, and an
                  │ check exists.                    │ authority path — offline.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Survivability    │ Dies with the vendor, database,  │ Outlives the tool, vendor, org, and
                  │ format, or team.                 │ personnel that produced it.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Admissibility    │ Weak: authenticity rests on      │ Strong: authenticity is intrinsic and
                  │ custodial testimony that the     │ independently reconstructable; no
                  │ record was not altered.          │ custodial testimony required.
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Time             │ Timestamp is a field the issuer  │ Time is bound and, when anchored, is
                  │ writes; freely backdatable.      │ independently unalterable (existence-
                  │                                  │ at-a-time, not merely a claimed clock).
──────────────────┼──────────────────────────────────┼─────────────────────────────────────
 Authority        │ Actor is an identifier string;   │ Bound to a delegated authority path
                  │ no proof the actor was permitted.│ (APQC-AUTH-006); the act was legitimate,
                  │                                  │ not merely performed.

2.4 The failure that results from treating logs as evidence

The failure is specific and predictable. A program logs every change diligently, in a well-run SIEM, with tight access controls, and declares itself "fully auditable." Years later, an auditor, regulator, insurer, or successor organization asks a question the logs cannot answer: prove — to me, who does not trust you and cannot inspect your systems — that this specific change occurred, at that time, under proper authority, and that nothing is missing.

At that moment three things happen at once. First, the logs are only as trustworthy as the operator, whose testimony is exactly what is in dispute. Second, the emitting system may be gone, or its format unreadable, or its clock unaccountable — so even a cooperative operator cannot reconstruct authenticity. Third, there is no way to prove completeness: a log cannot demonstrate that no line was silently dropped, because a missing log line leaves no log line. The "fully auditable" migration is, at the moment auditing actually matters, unprovable — and unprovable is indistinguishable from did not happen.

The discipline requires evidence precisely because "we migrated" must remain demonstrable when nothing about the original system can be trusted or even reached. Evidence is not logging.

3. The Evidence Object

3.1 Definition

The atomic unit of the model is the Evidence Object: a compact, canonical, cryptographically-signed commitment produced for every material transformation. (In the reference implementation this unit is a substrate, APQC-GLOSSARY-000; the neutral term used throughout this specification is Evidence Object.) A conforming Evidence Object MUST bind, at minimum:

  • What — a commitment (not a copy) to the change, revealing nothing sensitive (Least Exposure, APQC-CORE-001 P4).
  • When — a trustworthy time, resistant to backdating.
  • Who / under what authority — the acting agent and the delegated authority (APQC-AUTH-006) that permitted the action.
  • Integrity binding — a signature (or signatures) over all of the above, post-quantum in strength, so the object is unforgeable and quantum-durable.

An Evidence Object commits to the transformation without exposing it, is verifiable in isolation, and is the smallest thing a verifier can independently check.

3.2 Rationale

Why a commitment rather than a copy? Because evidence must be simultaneously (a) provable and (b) safe to hand to anyone, for decades. A copy of the change would leak sensitive material (keys, secrets, regulated data), violate Least Exposure, and grow storage without bound. A commitment — a fixed-length cryptographic binding to the exact bytes of the change — proves what changed to anyone who later holds the original bytes, while revealing nothing to anyone who does not. This separation of commitment (always portable, always safe) from disclosure (produced only to a party entitled to see it) is what lets one artifact serve both the regulator who must verify and the confidentiality regime that must not leak (see §13.1).

Why bind authority, not merely identity? A signature proves a key signed. It does not prove the signer was permitted to make this change. Authority is what makes a signature legitimate, not merely valid (APQC-AUTH-006 §2). An Evidence Object that binds only "who" records a fact of no governance value; one that binds "under what authority" records that the act was within a right traceable to a Root.

3.3 Field model (semi-formal, neutral)

The following ASCII schema is a conceptual field model, not a wire format. Field names are descriptive; a conforming implementation MAY name, order, and encode them differently, provided each binding below is present and covered by the integrity binding. Nothing here mandates a particular algorithm, encoding, or size.

EvidenceObject
├── version            : identifies the parameter set in force at production time
├── subject
│   ├── asset_ref      : commitment/reference to the asset transformed (Knowledge Graph)
│   └── change_commit  : cryptographic commitment to the exact change (NOT the change)
│                        e.g. H(canonical(before ∥ after ∥ salt)) — hiding + binding
├── time
│   ├── claimed_time   : producer-asserted instant (weak alone; see anchor)
│   └── anchor_ref     : OPTIONAL reference to an independent existence-at-a-time record
├── actor
│   └── agent_id       : the acting agent's identity (who signed)
├── authority
│   ├── authority_ref  : the delegated grant permitting this action (Authority Graph)
│   └── auth_path_commit: commitment binding the Root→agent path in force at time
├── linkage
│   ├── prev_ref       : hash-link to the prior object in the Chain of Evidence (§5)
│   └── graph_edges    : refs into Evidence/Authority/Knowledge graphs (§4)
└── integrity
    └── signatures[]   : ≥1 signatures over ALL of the above (multi-family; §13.2)
                         each: {family, public_key_ref, sig_bytes}

The integrity binding MUST cover every other field, including linkage and authority. If any field can be altered without invalidating a signature, that field is not evidence-bearing and the object does not conform (§6.1).

3.4 Worked example

A discovery-execution agent converts a TLS endpoint's signing key from ECDSA-P256 to ML-DSA-65 under a grant scoped to "convert signature primitives on estate segment 7."

At the moment of change the agent produces an Evidence Object binding: asset_ref = commitment to the endpoint identity; change_commit = H(canonical(P256-pubkey ∥ ML-DSA-65-pubkey ∥ salt)), which reveals neither key; claimed_time = the conversion instant, with anchor_ref pointing to a public-ledger entry made within seconds; agent_id = the execution agent; authority_ref = the specific grant, with auth_path_commit binding the Root→agent delegation path as it stood at that instant; prev_ref = the hash of the previous conversion in segment 7's chain; and three signatures from three independent families over the whole. The object is a few dozen bytes plus signatures. It is handed to the auditor, emailed to the insurer, and filed for twenty years. None of them can see the keys; all of them can verify the change occurred, when, and under a valid authority path — offline.

3.5 Edge cases

  • A change with no sensitive content still commits, not copies. Uniformity is a security property: if some objects carry cleartext and others commitments, the presence of a commitment leaks that this change was sensitive. All Evidence Objects commit.
  • A failed transformation is still a material event. If a conversion is attempted under valid authority and fails, that outcome MAY warrant an Evidence Object (a proven failure is evidence; see APQC-CORE-001, "failure is publishable"). What MUST NOT be produced is an object for an action lacking a valid authority path — an unauthorized action produces no effect and no evidence (APQC-AUTH-006 §4; §6.7 below).
  • Batch changes. A single logical transformation touching many assets MAY produce one object committing to the set (a Merkle root over per-asset commitments) or one object per asset; either is conforming provided Completeness (§6.2) over the declared scope remains provable.

4. The Evidence Graph

4.1 Definition and structure

Evidence Objects link into the Evidence Graph: the cryptographically-verifiable history of every transformation, cross-linked to the Authority Graph (the grant each object cites) and the Knowledge Graph (the asset each object changed). The Evidence Graph is the discipline's memory — the durable answer to what is proven? Where the Authority Graph records what may be done, the Evidence Graph records what was done, provably. It is not a log of execution; it is a set of proofs about execution (APQC-MODEL-003 §3.7).

Nodes are Evidence Objects. Edges are of three kinds:

  • Chain edges (prev_ref) — temporal/tamper-evident ordering within a scope (§5).
  • Authority edges (authority_ref, auth_path_commit) — into the Authority Graph, binding each proof to the right under which it was produced.
  • Knowledge edges (asset_ref) — into the Knowledge Graph, binding each proof to the asset it changed.

The three graphs are distinct (they answer known / permitted / proven) but joined at the Evidence Object, which is the only place all three meet. This tri-linkage is what makes replay (§9) possible: from a single object one can traverse up to the authority that permitted the act and across to the asset it changed, at the version in force when it happened.

   KNOWLEDGE GRAPH                AUTHORITY GRAPH
   (what is known)                (what is permitted)
        │                                │
   asset_ref                       authority_ref
        │                                │
        ▼                                ▼
   ┌────────────────────────────────────────────┐
   │              EVIDENCE GRAPH                  │
   │            (what is proven)                  │
   │                                              │
   │   EO_1 ◄──prev── EO_2 ◄──prev── EO_3 ...     │   chain edges
   │    │              │              │           │
   │  asset          asset          asset         │   knowledge edges
   │  auth           auth           auth          │   authority edges
   └────────────────────────────────────────────┘

An Evidence Object whose authority edge does not resolve to a valid Root→agent path in the Authority Graph as it stood at the object's bound time is malformed: it claims a proof of a governed act while pointing at no governing right (§6.7, failure case §12.5).

4.3 Edge cases

  • Vendor change mid-history. The graph MUST remain traversable across a change of producing tool (§8, Continuity). Cross-links are references and commitments, not live pointers into one vendor's database; they survive the tool.
  • An asset changed many times. Multiple Knowledge edges from different Evidence Objects may target the same asset across its conversion history; ordering among them is established by chain edges, not by trusting any timestamp field alone.

5. Chain of Evidence

5.1 Definition

A Chain of Evidence is an ordered, tamper-evident linkage of Evidence Objects such that the sequence and completeness of a series of transformations is itself provable — no object can be inserted, removed, or reordered without detection. The chain establishes not only that each change occurred, but that the set of changes is whole and in order, supporting Completeness (§6.2).

Each object binds a reference to its predecessor (prev_ref = a cryptographic hash of the prior object). Because each object's integrity binding covers its prev_ref, and each successor's prev_ref covers it in turn, the chain forms a tamper-evident sequence: altering, inserting, deleting, or reordering any object breaks the hash-link at that point and every point after it.

5.2 Why ordering must be intrinsic, not asserted

Timestamps can be backdated (§12.4). If the only evidence of order were the claimed_time field, an operator could reorder history by rewriting clocks. The chain makes order a structural property: object N cryptographically contains object N−1. Order is therefore checkable without trusting any clock, and (when the chain head is anchored, §7) the whole ordered set inherits an independent time bound.

5.3 Worked example: detecting a deletion

An operator wishes to hide that a non-compliant conversion happened — object EO_5 — by deleting it from a chain of 100.

Independent verification (§7) walks the chain: for each object it recomputes H(EO_k) and checks it equals EO_{k+1}.prev_ref. When EO_5 is removed, EO_6's prev_ref still commits to H(EO_5), but the object now presented at that position is EO_7 (or a gap). The recomputed hash of the object preceding EO_6 no longer matches EO_6.prev_ref. The verifier halts with chain break at position 6. The deletion is not merely suspected — it is proven, because the surviving objects cryptographically remember the shape of the object that was removed. To hide EO_5 the operator would have to re-sign EO_6 through EO_100 with the original signing keys under the original authority paths and re-anchor them — which, if signing keys are protected and anchors are public and immutable, is infeasible.

This is the property a log cannot offer: a deleted log line leaves no log line, and thus no proof of deletion. Evidence is not logging.

5.4 Edge cases

  • Concurrent chains. Parallel execution agents MAY maintain separate chains (e.g., per estate segment) that are periodically joined by an Evidence Object committing to multiple chain heads. Completeness is then defined over the join, not over a single linear sequence.
  • Chain head protection. The security of an entire chain against wholesale rewrite reduces to the protection of (a) the signing keys and (b) the anchor of the chain head. Both are addressed in §13.

6. Evidence properties

The following properties are the invariants that make an Evidence Object and the graph it belongs to evidence rather than logging. Each is normative.

6.1 Integrity

Every Evidence Object MUST be tamper-evident: any alteration of what/when/who/authority/linkage MUST invalidate it. Integrity rests on cryptographic signing over a canonical encoding, not on access control around a store. Access control protects a log; it makes tampering harder but leaves the trust model ("trust the operator") intact. Integrity, in this model, makes tampering self-revealing: the artifact carries its own alarm.

Rationale. If integrity depended on a store's access controls, then possession of the store — by the operator, an attacker, a successor org, or a court — would be sufficient to alter history undetectably. By binding integrity to signatures over canonical bytes, alteration requires the signing keys, and even then leaves the chain (§5) and any anchors (§7) inconsistent. Canonical encoding matters: two byte-representations of the same object MUST NOT both verify against one signature, or an adversary could smuggle a second meaning past a verifier (a canonicalization/collision attack). Conforming implementations MUST define and enforce a single canonical form before signing.

6.2 Completeness

The evidence set MUST be provably whole for its scope: it MUST be possible to demonstrate that every material transformation produced an object and that none is missing. Completeness is what lets "we migrated everything" be verified rather than asserted. Silent gaps are a conformance failure.

How completeness is proven. Assertion cannot prove completeness (a missing item asserts nothing). Structural evidence can, by making absence detectable. Two mechanisms, combinable:

  1. Scope enumeration bound to the Knowledge Graph. The scope of a completeness claim is a committed set of assets (a Merkle root over the target population at a stated version). Each Evidence Object's Knowledge edge names an asset in that set. Completeness is the proof that the set of Knowledge edges covers the committed population — every asset in scope has at least one object, and the coverage is checkable against the committed set, not against the producer's word.
  2. Chain contiguity. Within a scope, the Chain of Evidence (§5) is unbroken from a committed genesis to a committed head. A gap in the chain is a gap in coverage and is detectable as a chain break (§5.3).

Worked completeness-proof example. An organization must prove it converted all 4,812 signing keys in a regulated segment.

  • Before execution, discovery commits the segment: pop_root = MerkleRoot(sorted(asset_commit_i for i in 4,812 assets)), published and anchored.
  • Each conversion emits an Evidence Object whose asset_ref is one asset_commit_i and whose chain edge links it into the segment chain.
  • The completeness proof handed to the auditor is: (a) the committed pop_root; (b) the segment chain from genesis to head; (c) a mapping showing each of the 4,812 leaves of pop_root is the asset_ref of exactly one Evidence Object in the chain.
  • The auditor recomputes pop_root from the leaves, walks the chain checking hash-links, and checks the bijection. If leaf 2,913 has no corresponding Evidence Object, the mapping fails at 2,913 — a named, proven gap, not a vague suspicion. If all 4,812 map, completeness is proven against a set that was fixed before execution and cannot be quietly shrunk after the fact.

Rationale. Completeness is the property enterprises most often claim and least often can prove. Binding the claim to a pre-committed, anchored population is what converts "trust us, that's all of them" into "here is the set we committed to; here is a proof each member was converted."

6.3 Portability

Evidence MUST be movable — emailed, filed, handed to a regulator, stored anywhere — and remain verifiable outside the system that produced it. Evidence locked inside a vendor platform is, for the purposes of this model, not evidence (it is a log with better marketing; §12.2). Portability requires that an object be self-describing: its version field names the parameter set needed to interpret it, and verification depends only on the object plus public parameters, never on a live service.

6.4 Retention

Evidence MUST remain verifiable for the full retention horizon of the data or decision it concerns — years to decades — without dependence on the continued operation of any particular vendor or system. Retention is not merely storing bytes; it is storing bytes that remain checkable under the parameters in force when they were produced (see Continuity, §8). A perfectly preserved object that can no longer be verified because its parameter set is lost has failed retention.

6.5 Survivability

Evidence Survivability is the requirement that proof outlive the tool, the vendor, the organization, and the personnel that produced it. If the producer disappeared tomorrow, verification MUST still succeed. Survivability is Portability extended across time and across the death of the producer. It is the property that distinguishes evidence most sharply from logging: a log is mortal with its system by definition; evidence is constructed to survive its system's death.

Test. The operative thought experiment (formalized as a conformance test, §11.6): delete the producer. Remove the vendor, the database, the dashboard, the team. Hand a third party only the Evidence Objects and public parameters. If verification still succeeds, the artifact is evidence. If it does not, it was a log.

7. Independent Verification

7.1 Definition

Evidence MUST be independently verifiable: a party with no relationship to the producer, using only the evidence and public parameters, MUST be able to confirm it offline, without contacting the producer. This is the property that moves the root of trust off the producer's word. If verification requires the producer's cooperation, availability, or good faith, the artifact is a log, not evidence (§2). Anchoring an object's commitment to a public ledger MAY additionally provide an independent, unalterable timestamp (existence-at-a-time) that neither the producer nor the verifier can change.

7.2 The offline verification procedure (step-by-step)

The following is the canonical procedure a third party runs, with no contact with the producer. It uses only: the Evidence Object(s), the named public parameters (version), the public keys named in the signatures, the Authority Root and the authority-path commitments, and — if present — the public anchor. Each step has an explicit pass/fail.

 OFFLINE VERIFICATION FLOW
 ─────────────────────────
   [Evidence Object(s)] + [public params] + [Authority Root] + [anchor?]
            │
            ▼
   (1) CANONICALIZE  ── re-encode the object to its single canonical form
            │           FAIL → non-canonical: reject (possible smuggling)
            ▼
   (2) VERIFY SIGNATURES ── check every signature in signatures[] over the
            │               canonical bytes, against the named public keys.
            │               Require the mandated quorum of families to pass.
            │               FAIL → integrity broken: reject
            ▼
   (3) CHECK AUTHORITY ── resolve authority_ref to a Root→agent path;
            │             recompute auth_path_commit; confirm the path was
            │             valid, unexpired, unrevoked AT the bound time
            │             (Authority Replay, AUTH-006 §10).
            │             FAIL → unauthorized/unbound: reject
            ▼
   (4) WALK THE CHAIN ── for each linked object, recompute H(prev) and
            │            check == this.prev_ref; genesis-to-head contiguous.
            │            FAIL → chain break at position k: reject (tamper)
            ▼
   (5) CHECK COMPLETENESS ── recompute pop_root from committed leaves;
            │                confirm bijection leaves ↔ Knowledge edges.
            │                FAIL → named missing asset: reject (gap)
            ▼
   (6) CHECK TIME ANCHOR ── if anchor_ref present, confirm the commitment
            │               appears in the public record at/after claimed_time;
            │               existence-at-a-time established independently.
            │               FAIL → time unsupported: downgrade time trust
            ▼
   [VERIFIED]  ── what changed, when, by whom, under what authority,
                  and that the set is whole and ordered — all confirmed
                  offline, without the producer.

Every step is a pure function of inputs already in the verifier's hands. No network call to the producer occurs at any point; the only optional external read is a public anchor, which the producer does not control. This is the concrete meaning of "moves the root of trust off the producer."

7.3 Worked example

An insurer, three years after a breach at a client, must independently confirm that the client's signing infrastructure was PQ-converted before the loss date. The insurer receives a folder of Evidence Objects, a parameter file, the Authority Root fingerprint, and anchor references. Their analyst runs steps (1)–(6) on a laptop with no network access to the (now-bankrupt) vendor. Signatures verify; authority paths resolve to the Root and were valid at the bound times; the chain is contiguous; completeness maps to the committed population; anchors place the conversions before the loss date. The insurer concludes — without trusting or contacting anyone — that conversion occurred and when. A log folder would have proven nothing here, because there would have been no one left to vouch for it and nothing intrinsic to check.

8. Evidence Continuity

Evidence Continuity is the requirement that the Evidence Graph remain coherent and verifiable across time, vendor change, format evolution, and organizational change. Older evidence MUST remain verifiable under the parameters in force when it was produced; migrating tools MUST NOT orphan prior evidence. Continuity is the evidence-side counterpart to Authority Continuity (APQC-AUTH-006 §9).

Mechanism. Continuity is achieved by (a) each object naming its own parameter set (version), so a verifier decades later knows exactly which algorithms and canonical form to apply; (b) retaining the public parameters and Root history alongside the objects, not inside a vendor; and (c) never rewriting old objects when the discipline adopts new parameters — new evidence uses new parameters; old evidence remains checkable under old ones. When a signature family is later deprecated, continuity is preserved because conforming objects carried multiple independent families from the start (§13.2): the object remains verifiable through any surviving family while new production moves to a stronger set.

Edge case — format evolution. If the canonical encoding evolves, old objects MUST NOT be re-encoded (that would break their signatures). The old canonical form is retained as part of the version parameter set and applied when verifying old objects. Continuity is thus versioned coexistence, never migration of evidence.

9. Evidence Replay

9.1 Definition

Evidence Replay is the operation of deterministically reconstructing a past transformation — or an entire incident — from the Evidence Graph: what happened, in what order, under whose authority, and with what result, examined like a recording rather than inferred from fragments. Replay is why evidence is actionable where logs are not: at the moment of an incident, a verifier follows the objects (and the authorities they cite) and watches the event reconstructed, offline, years later. Evidence Replay composes with Authority Replay (APQC-AUTH-006 §10) to reconstruct both what happened and what was permitted at any past instant.

Determinism. Replay MUST be deterministic: the same Evidence Graph and parameters yield the same reconstruction for every verifier, every time. Determinism is what makes replay evidence rather than interpretation. It is achieved by reconstructing solely from committed, signed content and the chain order (§5) — never from mutable state, live queries, or the verifier's assumptions (§13.5).

9.2 Worked example: incident reconstruction ("watch it like a movie")

Eighteen months after a conversion program, a regulator opens an inquiry into whether a specific production key was converted improperly during a change-freeze window. The investigator does not ask the operator what happened; they replay:

  1. Locate. Find the Evidence Object whose Knowledge edge commits to the key in question.
  2. Order. Walk the Chain of Evidence around it; establish, structurally (not by clock), that it sits between EO_n and EO_{n+2}.
  3. Time. Read claimed_time and confirm it against the public anchor — placing the conversion, provably, inside the freeze window.
  4. Authority (Authority Replay). Resolve the object's authority edge and reconstruct the Authority Graph as it stood at that instant: was there a valid Root→agent path permitting production signature conversion, and did any ancestor attach a "no production action during freeze" Delegation Constraint (APQC-AUTH-006 §6)?
  5. Verdict. If such a constraint was in force, the authority path should have failed closed — and either (a) no Evidence Object should exist (the action was inconceivable), or (b) the object exists but its authority edge resolves to a path that violated an inherited constraint, which is itself a proven governance breach. Either way, the reconstruction is deterministic and offline: the regulator watches the freeze-window conversion, its ordering, its timing, and its (in)valid authority replay like frames of a film.

No fragment-stitching, no operator testimony, no live system. Contrast a log-only world: the investigator would receive a stream of the operator's own assertions about a system possibly no longer running, with no intrinsic way to confirm order, time, authority, or completeness. Evidence is not logging.

10. Normative requirements

A conforming Evidence Model implementation:

  • E1. MUST produce an Evidence Object (§3) for every material transformation; assertion without an object is not evidence (§2).
  • E2. MUST bind each object to its authority (APQC-AUTH-006); MUST NOT produce an object for an unauthorized action (§3.5, §6.7).
  • E3. MUST make every object tamper-evident and post-quantum signed (§6.1), over a single canonical encoding.
  • E4. MUST support provable Completeness over a defined, pre-committed scope (§6.2) and a tamper-evident Chain of Evidence (§5).
  • E5. MUST make evidence Portable, Retained, and Survivable independent of the producer (§6.3–6.5).
  • E6. MUST support Independent Verification offline, without producer involvement (§7), via a procedure that is a pure function of the object and public parameters.
  • E7. MUST preserve Evidence Continuity across time, vendor, and format change (§8); MUST NOT orphan or rewrite prior evidence when parameters evolve.
  • E8. MUST support deterministic Evidence Replay of any past transformation or incident (§9), reconstructed solely from committed, signed content and chain order.

10.1 A note on §6.7 (referenced by E2)

For clarity: the authority-binding obligation has two halves. Positive: every object binds a resolvable authority path (§4.2). Negative: no object is produced for an action lacking a valid path — such an action produces no effect and no evidence (APQC-AUTH-006 §4; APQC-CORE-001 P2). An implementation that emits an "evidence" object recording an unauthorized action has produced a log of a violation, not evidence of a governed act, and fails E2.

11. Conformance tests

The following tests are numbered, checkable, and written Given/When/Then. A conforming implementation MUST pass all of them. Tests marked [adversarial] deliberately attempt to break the property; passing means the attempt is detected/prevented, not that it succeeds.

CT-E1 — Object for every material change. Given a defined scope of N material transformations; When the workload executes all N under valid authority; Then the Evidence Graph contains an Evidence Object for each, and a completeness check (§6.2) over the committed scope maps all N with no gap.

CT-E1a — Silent-gap detection [adversarial]. Given a completed scope with a committed pop_root; When one Evidence Object is removed from the delivered set; Then the completeness check MUST report a named missing asset (the specific unmapped leaf), not merely "verification failed" and not "success."

CT-E2 — Authority binding present and resolvable. Given any Evidence Object; When a verifier resolves its authority edge; Then it MUST resolve to a Root→agent path that was valid, unexpired, and unrevoked at the object's bound time (via Authority Replay, AUTH-006 §10).

CT-E2a — Producer-of-unauthorized-action [adversarial]. Given an action for which no valid authority path exists; When execution is attempted; Then the action MUST fail closed and no Evidence Object is produced (E2 negative half). An implementation that emits an object here FAILS.

CT-E3 — Tamper-evidence [adversarial]. Given a verified Evidence Object; When any single bit of any bound field (what/when/who/authority/linkage) is flipped; Then at least one required signature MUST fail verification and the object MUST be rejected.

CT-E3a — Non-canonical smuggling [adversarial]. Given an object and a semantically-different re-encoding that hashes differently; When both are presented; Then only the single canonical form MUST verify; the alternate encoding MUST be rejected at the canonicalization step (§7.2 step 1).

CT-E3b — Single-family compromise [adversarial]. Given an object signed by ≥2 independent signature families; When one family is assumed fully broken (its signatures forgeable); Then verification MUST still detect tampering via a surviving family — i.e., a forgery valid under the broken family alone MUST be rejected for lack of the required quorum.

CT-E4 — Chain tamper-evidence [adversarial]. Given a Chain of Evidence of length M; When one object is inserted, deleted, or reordered; Then the chain walk (§7.2 step 4) MUST report a chain break at the affected position.

CT-E5 — Producer-absent verification [adversarial]. Given a set of Evidence Objects and public parameters; When the producing tool, vendor, database, and personnel are all made unavailable (the "delete the producer" test, §6.5); Then offline verification (§7.2) MUST still succeed using only the objects and public parameters.

CT-E5a — Portability across custody. Given an Evidence Object; When it is exported, transmitted through an unrelated channel, and re-imported by a party with different tooling; Then it MUST verify unchanged, with no dependence on the origin system.

CT-E6 — Offline determinism. Given the same Evidence Graph and parameters; When verification (§7.2) is run by two independent parties with no network access to the producer; Then both MUST reach identical pass/fail results at every step.

CT-E6a — Backdating resistance [adversarial]. Given an anchored Evidence Object; When an operator rewrites claimed_time to an earlier instant; Then step (6) MUST detect that the anchored existence-at-a-time postdates the forged claimed_time, and the time claim MUST be rejected as unsupported.

CT-E7 — Continuity across parameter change. Given Evidence Objects produced under parameter set V1; When the implementation adopts a newer set V2 and continues producing evidence; Then the V1 objects MUST remain verifiable under V1 parameters without re-encoding or re-signing, and MUST NOT be orphaned by the tool change.

CT-E8 — Deterministic replay. Given an incident spanning K Evidence Objects; When replay (§9) is performed; Then the reconstruction (order, timing, authority state, outcome) MUST be identical across independent verifiers and derived solely from committed, signed content and chain order — never from live or mutable state.

12. Failure cases / anti-patterns

Each of the following resembles evidence and is not. Naming them is normative: a conforming implementation MUST NOT exhibit them.

12.1 Evidence that needs the producer online to verify

Pattern: verification calls back to the producer's API, license server, or database to confirm an object. Why it fails: the root of trust remains the producer (and the producer's continued existence). This is a log behind a verification-shaped façade. It fails E6 and dies with the producer (fails E5). If the producer must be reachable, it is not evidence (§2, §7).

12.2 Vendor-locked evidence

Pattern: objects verifiable only inside one platform, in a proprietary format, with no self-contained parameters. Why it fails: it is unmovable (fails E5/Portability) and mortal with the vendor (fails E5/Survivability). "Evidence locked inside a vendor platform is, for the purposes of this model, not evidence" (§6.3).

12.3 Silent completeness gaps

Pattern: the system emits objects for the changes it happened to notice, with no committed scope, so a missing change produces nothing and is never noticed. Why it fails: completeness cannot be proven against an uncommitted set; "we converted everything" collapses to "we converted the ones we recorded." Fails E4. A missing object must be a named, detectable gap (CT-E1a), which requires a pre-committed population (§6.2).

12.4 Backdatable timestamps

Pattern: time is a self-asserted field with no independent anchor; ordering rests on that field. Why it fails: the operator can move events in time and reorder history, defeating replay and freeze-window governance (§9.2). Fails E6a/E8. Order MUST be structural (chain, §5) and time SHOULD be anchored (§7, §13.3).

12.5 Evidence unbound from authority

Pattern: objects record who signed but not under what right, or cite an authority that does not resolve to a Root path. Why it fails: a valid signature by an unauthorized key is "valid and meaningless" (APQC-AUTH-006 §2). Such an object proves an act occurred but not that it was legitimate; it cannot support governance replay (§9.2). Fails E2. Authority binding, not identity binding, is what makes evidence governable.

12.6 Access-control-as-integrity

Pattern: integrity is claimed on the basis of a locked-down, append-only store rather than signatures over content. Why it fails: the trust model is still "trust the operator and their controls." Possession of the store defeats it, silently. Fails E3. Integrity MUST be intrinsic (§6.1).

13. Implementation notes (informative)

This section is informative. It sketches how the normative properties above are typically realized, without mandating any mechanism, algorithm, or product.

13.1 Commitment vs disclosure

An Evidence Object carries a commitment — a hiding, binding function of the change (e.g., a salted hash over a canonical before ∥ after). The commitment is always safe to publish and never leaks (Least Exposure). Disclosure — revealing the underlying bytes to a party entitled to see them — is a separate, later act: the holder of the original bytes presents them, and any verifier recomputes the commitment to confirm they are exactly what was committed. This split lets one artifact serve both the regulator who must verify existence/ordering/authority (commitment alone suffices) and the narrow party entitled to content (disclosure on demand), with no third artifact and no standing leak.

13.2 Multi-family signatures, and why more than one family

Signing each object under two or more independent signature families (families whose security rests on unrelated mathematical assumptions — e.g., a lattice family and a hash-based family) buys three things a single family cannot: (a) survivability of a cryptanalytic break — if one family is later broken, tamper-evidence and non-forgeability survive through another (CT-E3b); (b) continuity across deprecation (§8) — old evidence stays verifiable through a surviving family while new production adopts stronger parameters; and (c) defense in depth against implementation bugs in any one library. The verifier requires a quorum of families to pass, so no single family's failure — cryptanalytic or accidental — silently validates a forgery. This is why "post-quantum signed" in the normative body is realized as multiple independent post-quantum families, not one.

13.3 Public-ledger anchoring for independent timestamp

Publishing an object's commitment to a public, append-only ledger establishes existence-at-a-time: the commitment demonstrably existed no later than the ledger position, and neither the producer nor the verifier can move it. Anchoring binds time, not content (the ledger sees only a commitment). It is what defeats backdating (§12.4, CT-E6a) and gives an entire chain an external time reference independent of every party's clock. Anchoring is a MAY in the normative body because the property (independent, unalterable time) is what is required; a public ledger is one way to obtain it.

13.4 Retention and verification over decades

Long-horizon verifiability is an operational discipline: retain the public parameters and Root history alongside the objects (never inside a single vendor); store the canonical-form definition per version; and periodically exercise verification (a stored proof never re-checked is an assumption, not a fact). Compactness helps: when each object is small (the reference implementation targets tens of bytes plus signatures), a decade of per-change evidence is measured in gigabytes, not terabytes — small enough to retain indefinitely, replicate widely, and hand to anyone.

13.5 Making replay deterministic

Determinism (§9.1, E8) is engineered by reconstructing only from committed, signed content and structural chain order — and never from mutable state, live queries, wall-clock reads at replay time, or unordered sets. Concretely: order comes from prev_ref links, not timestamp sorting; authority state comes from the committed auth_path_commit resolved via Authority Replay, not from the current Authority Graph; and outcomes come from committed fields, not from re-deriving them against today's environment. Two verifiers, on different hardware, decades apart, must produce byte-identical reconstructions — which is possible precisely because every input to replay is fixed and signed.

14. Reference implementation (informative)

The reference implementation seals each transformation into a compact post-quantum attestation substrate that commits to the change without exposing it, binds it to the authority under which it occurred, verifies offline against multiple independent signature families, and may be anchored on a public ledger for an independent timestamp — such that a decade of per-change evidence is measured in gigabytes, not terabytes, and remains verifiable with no vendor in the path. See APQC-REFERENCE-010. This section is informative; §§2–13 are normative and implementation-independent.

15. Not In Scope

This specification does not define: logging or SIEM systems (which it explicitly contrasts, §2); specific signature, hash, or commitment algorithms (cryptographic primitives are NIST's domain); ledger or anchoring technologies; storage systems or retention products; wire formats, encodings, or vendor APIs; or the mechanics of any workload's transformation. It defines what evidence is and the invariants it must satisfy — integrity, completeness, portability, retention, survivability, independent verification, continuity, and replay — not any implementation of them. And it insists, throughout, on the one distinction from which all of these follow: evidence is not logging.