RFC-0010: State Dump Protocol Formalization

RFC: RFC-0010
Status: Placeholder
Version: 0.0.1
Created: 2026-03-15
Updated: 2026-03-15
Author: Ken Tannenbaum, AEGIS Initiative
Repository: aegis-governance
Target milestone: TBD
Supersedes: State Dump Protocol sub-spec (partial — see Motivation)
Superseded by: None

Summary

The existing State Dump Protocol sub-spec establishes that AEGIS requires tamper-evident audit trails and forensically defensible records. It does not define what makes a replay defensible, what must be attested as captured vs missing at commit time, how cross-run differential forensics are performed, or what replay completeness threshold is required before a deployment is considered production-certified. This RFC formalizes the State Dump Protocol by specifying those missing normative definitions.

Status Note

This is a placeholder RFC. Content is pending the normative source audit (target: before 2026-03-22 IEEE outline). The RFC number is reserved to maintain index continuity with the README and roadmap.

Motivation

Four gap findings from the normative source audit (2026-03-15) are assigned to this RFC:

gap-001 — Audit-grade defensibility definition. The State Dump Protocol sub-spec has no definition of what makes a governance replay defensible. A replay should be considered defensible when: (a) the outcome is machine-reproducible from stored evidence, (b) policy context is explicit, (c) authority context is explicit, and (d) incomplete traces are clearly labeled as such. AEGIS has no normative equivalent of these criteria.

gap-002 — Completeness attestation schema. No model exists in AEGIS for attesting what was captured vs missing at commit time. A commit record should carry a structured attestation of capture status across trace, policy snapshot, authority snapshot, and chain integrity fields. AEGIS has no equivalent completeness model.

gap-003 — Cross-run differential forensics (Run Diff). The ability to compare two pipeline runs — trace length, first mismatch position, structural divergence — is not specified in the Detached Execution or State Dump Protocol sub-specs. This is a prerequisite for meaningful forensic analysis in production.

gap-004 — Replay completeness SLO. AEGIS has no production certification criterion tied to replay completeness. What percentage of non-legacy jobs must have reproducible commit decisions before a deployment is considered production-certified? This must be stated normatively or explicitly deferred in the IEEE paper Limitations section.

Additionally, the normative language in the existing sub-spec and whitepaper must be corrected to use tamper-evident rather than immutable when describing the current replay chain behavior. Tamper-evidence is achieved through hash-chaining with DB-level no-update enforcement on persisted replay events (reference pattern: Elora Taurus, Discussion #73). Immutability in the cryptographic sense is a future maturity step, not a current capability claim.

Guide-Level Explanation

Pending. To be drafted after normative source audit.

Reference-Level Explanation

Pending. To be drafted after normative source audit.

Anticipated sections:

§1 Audit-Grade Defensibility — normative definition and four criteria
§2 Completeness Attestation Schema — required fields and status values
§3 Append-Only Provenance Model — hash-chain specification; reference to Discussion #73 and Elora pattern
§4 Cross-Run Differential Forensics — Run Diff specification
§5 Replay Completeness SLO — production certification criterion

Drawbacks

Pending.

Alternatives Considered

Pending.

Compatibility

This RFC partially supersedes the existing State Dump Protocol sub-spec. Sections of the sub-spec that are not addressed here remain in force until explicitly superseded. Breaking changes, if any, will be enumerated in the Reference-Level Explanation once drafted.

Implementation Notes

Pending.

Reference implementations to consult during drafting:

Elora Taurus append-only provenance pattern (Discussion #73; prev_hash → event_hash chain with DB-level no-update enforcement)
Elora Taurus completeness attestation model (eight-field chip schema from admin demo decision summary)
Elora Taurus Run Diff panel (stage-3-deep-dive.html)

Open Questions

Should the completeness attestation schema define a minimum required field set, or enumerate all possible fields with presence requirements?
Should the replay completeness SLO be a normative MUST or a SHOULD with operator-configurable threshold?
Is cross-run differential forensics (Run Diff) in scope for this RFC or should it be deferred to a separate RFC?
Should commit_input_v1 and commit_decision_v1 be adopted as named versioned artifact schemas, or should AEGIS define its own equivalents?
Does “tamper-evident” language correction require a whitepaper revision pass before or after this RFC is accepted?

Success Criteria

Every governance replay in a compliant AEGIS deployment can be evaluated against the four defensibility criteria
Every commit record carries a completeness attestation schema that explicitly labels missing captures
The distinction between tamper-evident (current) and immutable (future) is stated normatively and consistently across all AEGIS documents
Replay completeness SLO is defined and referenced in the IEEE paper evaluation or limitations section

References

AEGIS State Dump Protocol sub-spec — aegis-core/constitution/ (current authoritative source, partially superseded by this RFC)
AEGIS Detached Execution sub-spec — aegis-core/constitution/
RFC-0004 v0.4 — Runtime Trust Model (two-mechanism separation model, 2026-03-15)
RFC-0009 — Prior Art and External Validation Record (stub, 2026-03-15)
Discussion #73 — Append-Only Pipeline Provenance, Reference Pattern from Elora Taurus
Elora Taurus: 04_REPLAY_FORENSICS_AND_ACCOUNTABILITY.md
Elora Taurus: 09_SECURITY_CLAIMS_MATRIX.md
RFC 6962 — Certificate Transparency (standards anchor for append-only provenance pattern)
AEGIS Constitution — aegis-core/constitution/

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative — AEGIS Operations LLC