From 123af5468977d48dad07436edf78950dc5e8276e Mon Sep 17 00:00:00 2001 From: tcconnally Date: Mon, 3 Aug 2026 17:19:18 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20continuous=20attestation=20=E2=80=94=20?= =?UTF-8?q?admission=20vs=20runtime=20evidence=20(ledger#201)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Implements ledger#201 from the 2026-08-03 research sweep. New docs/continuous-attestation.md formalizes the Dynamic Evidence Ledger: - admission vs continuous attestation distinction (PDD, arXiv:2605.12981) - attestation block E_t = H(E_{t-1}, P, Iv, Rt, At, t) mapped to Ledger fields - mechanical vs reasoning provenance as separate primitives (arXiv:2603.21692) - typed attestations with replayable verify (Pramana, arXiv:2605.20312) - CT-style independent auditability (arXiv:2509.18415, arXiv:2604.06693) - violation → repair context → re-admission loop - explicit non-claims: monitorable projection, not world guarantees README integrity section links the new doc. --- README.md | 2 + docs/continuous-attestation.md | 135 +++++++++++++++++++++++++++++++++ 2 files changed, 137 insertions(+) create mode 100644 docs/continuous-attestation.md diff --git a/README.md b/README.md index 001eea2..47e91ed 100644 --- a/README.md +++ b/README.md @@ -87,6 +87,8 @@ This writes an immutable event into the local SQLite-backed hash chain. Existing Ledger integrity is not a marketing assertion. It is checked from the recorded chain and can be exposed through the existing admin verification endpoint in a controlled deployment. - [Ledger integrity](docs/ledger-integrity.md) +- [Continuous attestation](docs/continuous-attestation.md) — admission vs. runtime evidence; attestation blocks; mechanical vs. reasoning provenance +- [Evidence receipts](docs/evidence-receipts.md) — task-scoped, machine-readable views of hash-chained events - [API reference](docs/api.md) - [Schema](docs/schema.md) - [Reconciliation](docs/reconciliation.md) — optional provider-cost and Stripe settlement reconciliation diff --git a/docs/continuous-attestation.md b/docs/continuous-attestation.md new file mode 100644 index 0000000..2192340 --- /dev/null +++ b/docs/continuous-attestation.md @@ -0,0 +1,135 @@ +# Continuous Attestation: Admission vs. Runtime Evidence + +> **Perseus resolves. Vault remembers. Ledger proves.** This document turns the +> "prove it later" promise into a continuous one: admission is not a one-time event; +> compliance is a sequence of recorded claims over monitorable behavior. + +Related: [Evidence Receipts](evidence-receipts.md) · [Ledger Integrity](ledger-integrity.md) · +[Schema](schema.md) · [Three-Tier Model](three-tier-model.md) + +## 1. The problem + +Ledger records *what happened*. That is necessary but not sufficient for governed +autonomous systems: a component that passed admission can later drift, degrade, or be +attacked (stale evidence, superseded policy, dependency drift, adversarial inputs). The +research literature converges on the same answer (Protocol-Driven Development, +arXiv:2605.12981; Proof of Execution, arXiv:2607.05397): **compliance is continuously +attested**, not once admitted. The protocol (contract) remains the durable governing +object; evidence continues to accumulate after deployment. + +## 2. Admission vs. continuous attestation + +| | Admission (build/decision time) | Continuous attestation (runtime) | +|---|---|---| +| Question | "Is this artifact/action admissible under the contract?" | "Does the deployed behavior still satisfy the monitorable projection of the contract?" | +| Evidence | Signed Evidence Chain: protocol, implementation hash, validator outputs, attestation | Append-only ledger blocks: observations, invariant checks, violations, remediation | +| Failure | No acceptance evidence is produced | Violation block is recorded and becomes structured repair context | +| Authority | Validator decides | Runtime Verification Layer enforces *outside* the artifact (block, quarantine, rate-limit, roll back) | + +The static/dynamic distinction is a *boundary condition*, not a defect: build-time evidence +proves compliance relative to preserved validator inputs, validator assumptions, and the +protocol observation model. It is not a perpetual guarantee of future executions. + +## 3. The attestation block + +Each runtime attestation interval produces one signed, hash-chained evidence block: + +```text +E_t = H(E_{t-1}, P, Iv, Rt, At, t) +``` + +| Field | Meaning | Ledger mapping | +|---|---|---| +| `E_{t-1}` | previous evidence block | `prev_hash` of the prior event | +| `P` | governing protocol/contract | `policy_version` (hash-covered) | +| `Iv` | deployed implementation version | `model_config` / artifact identity | +| `Rt` | runtime observations over interval t | `evidence_hashes` + event facts | +| `At` | attestation decision | the event's action/result + `human_review` | +| `t` | interval identifier | event timestamp/sequence | + +The ledger evolves append-only: `L_t = L_{t-1} ∥ E_t`. The deployed instance is +time-indexed by implementation and evidence state: `D_t = (P, Iv, L_t)` — the protocol is +the durable specification while operational evidence evolves. + +## 4. Mechanical vs. reasoning provenance + +The evidence model separates two primitives (Reasoning Provenance, arXiv:2603.21692): + +1. **Mechanical provenance** — what happened: events, hashes, traces, causal lineage. + This is Ledger's current model (event rows, `prev_hash`/`row_hash` chains). +2. **Structured reasoning provenance** — *why* each action was chosen, what each + observation concluded, how conclusions shaped strategy, and which evidence supports + the final verdict. This is a schema-level primitive for population analytics, not an + optional comment field. + +Clients should send both where available: mechanical facts through the existing ingest +contract, and reasoning provenance as hash-covered evidence references (rationale +digests, evidence-support links) — never raw rationale text. Ledger canonicalizes +digests, never payload content. + +## 5. Typed attestations with replayable verify + +Attestation records carry a claim type so verification is deterministic (Pramāṇa, +arXiv:2605.20312): + +- **measurement** — an observed fact; verify against the recorded observation digest. +- **inference** — a derived conclusion; verify against its inputs and the derivation rule. +- **analogy** — a mapping claim; verify against the referenced source. +- **citation** — an attribution; verify against the cited artifact digest. + +Each typed claim is linked to a source digest and a deterministic or replayable +`verify()` operation. The ledger records audit-complete emission/suppression/disclosure +semantics: if a claim is emitted, its verification inputs must be reproducible from the +preserved record. + +## 6. Independent auditability + +Third-party verification is a first-class goal (Context Lineage, arXiv:2509.18415; Aegon, +arXiv:2604.06693): + +- Domain-separated event leaves with signed tree heads/checkpoints (Ledger already + supports external `chain_checkpoints` — see `ledger-integrity.md`). +- Inclusion and consistency proofs so an auditor can verify "this event was recorded" + and "nothing was retroactively modified" without trusting the operator. +- A proof-server API surface for independent queries. + +The existing `/api/audit` verification block (`chain_ok`, `verified_events`, method) is the +starting point; continuous attestation extends it from one-time verification to +periodic, interval-indexed attestation queries. + +## 7. Wiring: violation → repair context → re-admission + +Runtime attestation failure should close the governance loop (PDD remediation +orchestrator): + +1. A violation block is appended (signed, hash-chained). +2. The violation identifies the violated contract clause, relevant telemetry, and + environment metadata (as hash references). +3. The block becomes structured **repair context** for the next generation/admission + attempt. +4. Any proposed fix re-enters validation before replacement — admission remains + necessary, deployed behavior is continuously measured against the monitorable + projection. + +## 8. What this document does *not* claim + +- Ledger does not decide policy; it records what happened under which authority and + evidence. Continuous attestation records attestation *decisions* made by the governing + controller. +- Attestation covers the **monitorable projection** of the protocol — the observations + available to the runtime verifier — not an unobservable guarantee about the world. +- "Replayable" is not "reproducible in the world": replay under captured inputs and + declared dependencies does not guarantee external sources match at replay time. + +## References + +- Protocol-Driven Development — arXiv:2605.12981 (Dynamic Evidence Ledger; monitorable + runtime projection; remediation orchestrator) +- Proof of Execution — arXiv:2607.05397 (execution = (C, T, R); validator invariants; + replay envelope) +- Reasoning Provenance for Autonomous AI Agents — arXiv:2603.21692 +- Pramāṇa: Protocol-Layer Claim Verification — arXiv:2605.20312 +- Context Lineage Assurance (CT-style Merkle logs) — arXiv:2509.18415 +- Aegon: Ledger-Bound Tokens + CT-Style Audit — arXiv:2604.06693 +- Sovereign Execution Broker — arXiv:2606.20520 (certificate-bound authority, revocation + epochs, live-state drift)