Document and support Dynamic Evidence Ledger continuous-attestation semantics

[tcconnally]

Body:

Motivation

PDD (arXiv:2605.12981) formalizes the Dynamic Evidence Ledger: an append-only chain where each block is a signed digest of the previous block, the governing protocol, the deployed artifact version, runtime observations over the interval, and the attestation decision:
E_t = H(E_{t-1}, P, Iv, Rt, At, t).
This is precisely Ledger's hash-chained event model, but our current docs describe one-shot event recording; the continuous-attestation reading (admission is not a one-time event; compliance is a sequence of recorded claims over monitorable behavior) is not documented.

Proposed work

1. Add a docs page (e.g., docs/continuous-attestation.md) describing:
   • admission vs continuous attestation distinction,
   • monitorable runtime projection (Φ^r_P over observations available to the verifier),
   • the attestation-block formula and how it maps to existing Ledger event fields (actor, boundary, evidence, config, action, result).
2. Add an example of a "violation block → repair context → re-admission" event sequence with the existing CLI/API.
3. If feasible, add an optional attestation event subtype in the ingestion contract that carries protocol_ref, artifact_version, interval, decision, and prev_block linkage.

Acceptance criteria

• Docs page links from README; example runs against the local ledger.
• Any contract change keeps plutus_agent/plutus CLI and /v1/usage compatibility surfaces intact.

References

• PDD arXiv:2605.12981

---

[tcconnally]

Battery synthesis follow-up (2026-08-03, corrected copy) — Reasoning Provenance (arXiv:2603.21692) argues Ledger's model should explicitly separate two primitives instead of one evidence blob:

1. Mechanical provenance — events, hashes, traces, causal lineage (what happened; current model).
2. Structured reasoning provenance — normalized, queryable records of why each action was chosen, what each observation concluded, how conclusions shaped strategy, and which evidence supports the final verdict (schema-level, population-analytics-ready).

Also worth citing: Aegon (arXiv:2604.06693) for a Certificate-Transparency-style Merkle-tree audit design that lets third parties independently verify ledger records were not retroactively modified, plus its signed provenance event log through AI transformation stages (chunking, embedding, retrieval, citation). Full synthesis: .hermes/paper-analysis/PERSEUS-BATTERY-2026-08-03-SYNTHESIS.md.

[tcconnally]

Full-sweep update (169 papers) — Ledger's evidence model should adopt these concrete patterns:

1. Typed attestations with replayable verify() (arXiv:2605.20312 Pramana): claim types (measurement/inference/analogy/citation) each with deterministic or replayable verify(); audit-complete emission/suppression/disclosure semantics.
2. Three-layer ledger interface (arXiv:2601.20727): normalized emitters / hash-chained storage with access control / auditor queries; approvals, waivers, attestations, incidents, policy snapshots as first-class records.
3. CT-style Merkle audit (arXiv:2509.18415): domain-separated event leaves, signed tree heads/checkpoints, inclusion + consistency proofs, proof-server API; third-party independent verification (also Aegon 2604.06693).
4. Portable action certificates (arXiv:2606.04104): canonical action, authority, externality, approval enforceability, runtime receipts, integrity references, final authority — the receipt envelope shape.
5. Delegation contracts (arXiv:2603.18043): objective/budget/deadline/authority/failure policy; attested quality before routing high-impact work (strategic inflation of self-reported quality breaks routing).
6. Mechanical vs reasoning provenance as separate primitives (arXiv:2603.21692, previously noted).

Full 169-paper sweep synthesis: .hermes/paper-analysis/PERSEUS-FULL-SWEEP-2026-08-03-SYNTHESIS.md (digests: .hermes/paper-ingest/2026-08-03/battery/digests/merged-all-rounds.json).

[tcconnally]

/update-201

Round-2 research follow-up

The continuous-attestation documentation from PR #204 is landed. The next receipt/schema refinement should incorporate:

• Sovereign Assurance Boundary: bind receipts to evidence hash, policy version, authority epoch, actor, scope, and expiry.
• EG-VAR: distinguish independently verified claims from replayable abstention.
• Verifiable MCP manifests: sign capability manifests and enforce transparency/revocation.
• Notarized Agents / Sello and enclawed: move observability and egress trust to the receiving/runtime boundary.
• IA-CCF and formalizing agentic-AI properties: preserve signer accountability and lifecycle-state properties.

Recommended residual work: keep mechanical provenance, reasoning provenance, authorization, attestation, semantic truth, and runtime completeness as separate fields/claims. This is an update to the completed issue, not a reopening.

[tcconnally]

Round-2 research update (2026-08-04)

The ledger/receipt design space adds several concrete requirements:

• Sovereign Assurance Boundary (2606.11632): bind receipts to evidence hash, policy version, authority epoch, actor, scope, and expiry.
• EG-VAR (2607.12650): separate verifier-minted Verified from replayable Abstain.
• Verifiable MCP Manifests (2601.23132): sign capability manifests and enforce transparency.
• Notarized Agents/Sello (2606.04193): receiver-attested receipts, JWS authorization-key binding, digest-only payload references, and revocation ordering.
• enclawed (2604.16838): deny-by-default egress, signed modules, peer attestation, immutable trust roots, and tamper-evident audit.
• IA-CCF (2105.13116): accountability and authority/key-rotation sub-ledger patterns.
• Formalizing agentic AI properties (2510.14133): host-agent lifecycle and temporal properties for allow/deny/defer/interrupt/recover.

Proposed follow-up

Update the continuous-attestation documentation/contract to distinguish mechanical provenance from reasoning provenance, and to carry authority epoch, policy version, scope, expiry, manifest digest, verifier status, and replay envelope as explicit receipt fields. Preserve the boundary: proposals and formal designs are not deployment validation.

Research basis: 2026-08-04 Round 2 synthesis
https://arxiv.org/abs/2605.12981
https://arxiv.org/abs/2607.25853
https://arxiv.org/abs/2606.11632
https://arxiv.org/abs/2607.12650
https://arxiv.org/abs/2606.28690
https://arxiv.org/abs/2607.01919
https://arxiv.org/abs/2601.23132
https://arxiv.org/abs/2604.05969
https://arxiv.org/abs/2604.09378
https://arxiv.org/abs/2603.19974
https://arxiv.org/abs/2605.05274
https://arxiv.org/abs/2602.02219
https://arxiv.org/abs/2603.11027
https://arxiv.org/abs/2406.07791
https://arxiv.org/abs/2506.22316
https://arxiv.org/abs/2508.21164
https://arxiv.org/abs/2605.11733
https://arxiv.org/abs/2608.00783
https://arxiv.org/abs/2608.00009
https://arxiv.org/abs/2605.24117
https://arxiv.org/abs/2608.01619
https://arxiv.org/abs/2608.00426
https://arxiv.org/abs/2604.16838
https://arxiv.org/abs/2606.04193
https://arxiv.org/abs/2105.13116
https://arxiv.org/abs/2510.14133