Rule Forensics Immutability

slug: rule_forensics_immutability element_type: RULE mutability: LOCKED inline: true current_version: 0 status: seed-draft contentURI: null implements_principles: [typed_findings] uses_terms: [incident, evidence]

Forensic records — incident records, evidence chains, response action audit trails, post-mortem records — are append-only at the storage layer. A record once committed cannot be modified or deleted; corrections create new versions referencing the prior version, never overwrites. The storage substrate MUST enforce this structurally (not merely as a policy convention). Acceptable substrates: cryptographic hash-chained records, append-only logs with external integrity verification, or on-chain anchoring. Editable databases (standard relational tables, key-value stores with UPDATE/DELETE permissions enabled, document stores) MAY be used as access layers if and only if every write also produces an immutable record in a substrate meeting the structural requirement. Soft-delete flags do not satisfy this rule; a record marked deleted remains in the immutable substrate, visible to forensic queries.

Status

Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16). LOCKED because forensic immutability is a property that, once compromised at the substrate level, cannot be reconstructed retroactively. This rule must precede any incident infrastructure.

What this rule operationalizes

principle:typed-findings defines findings as typed records. This rule defines how those records are stored such that the witness function (inherited from meta's principle:witness-principle) is structurally guaranteed.

Why structural enforcement, not policy

A policy ("operators agree not to modify forensic records") is broken the first time an operator under pressure violates it — usually because a record looks embarrassing in a public review. Structural enforcement removes the option. The substrate refuses the modification regardless of who attempts it.

This is the same logic the meta repo applies to the constitutional registry on-chain: the substrate is the guarantor, not human discipline.

Acceptable substrate patterns

1. Hash-chained records

Each record carries a hash of itself and the previous record. Modification breaks the chain, detectable on verification. Examples: Merkle log, certificate transparency log, git-style content-addressable storage.

2. Append-only log with external integrity

Records appended sequentially; periodic integrity proofs published to external observers. Examples: AWS QLDB with cryptographic verification, append-only S3 with object lock, transparent log services.

3. On-chain anchoring

Record hash committed to a blockchain (Leviathan L1 per ADR-008, or external chain). Modification of underlying record produces hash mismatch, detectable. Most expensive option; reserved for highest-classification records.

Access layer vs storage layer

The constitution permits operationally convenient access layers (queryable databases, search indexes, dashboards) provided every write also produces an immutable record in the storage substrate. This separation lets operators have fast queries without sacrificing forensic integrity.

The check: if every access layer were destroyed tomorrow, could the immutable substrate alone reconstruct the full forensic history? If yes, the design conforms. If the immutable substrate alone would have gaps, the design fails this rule.

Correction pattern

When a record requires correction (typo, mis-attribution, new evidence), the correction creates a new version pointing to the prior version. The prior version remains visible.

Example:

incident_v1: "Suspected breach by IP 1.2.3.4, evidence X"
incident_v2: "Correction: IP 1.2.3.4 was a load balancer for ISP A; actual breach origin TBD"
  supersedes: incident_v1
  reason: "ISP attribution clarification"

A reader queries the latest version and gets v2; the audit trail still shows v1 was the original claim. Compare: this matches the version pattern used throughout federation constitutional elements.

Soft-delete is not deletion

A common database pattern: mark a record deleted: true, hide it from default queries. This does not satisfy this rule. A forensic record marked deleted remains in the immutable substrate, visible to forensic queries. The constitution does not permit "deletion" of forensic records; only supersession via new version.

What is NOT forensic

Operational telemetry that is intentionally short-lived (e.g., real-time metric streams, debug logs not feeding into typed findings) is not forensic. It rotates per normal retention policy. The boundary: if a record can be cited as evidence in an incident or in a constitutional discussion, it is forensic and falls under this rule. If it is purely transient performance telemetry, it does not.

Sub-Leviathan inheritance

LOCKED. Instances cannot weaken (cannot adopt a substrate that permits silent modification). Instances may strengthen (require multiple-witness attestation, on-chain anchoring for higher-classification records, dual-substrate redundancy).

Related elements

• principle:typed-findings — the principle this rule operationalizes
• term:incident, term:evidence — the records this rule protects
• principle:defensive-only — forensic discipline supports the witness function
• Inherited from meta: principle:witness-principle (witness is structurally guaranteed, not policy-promised), term:proposal (constitutional records use the same immutability pattern)

Awaiting domain author

Specific substrate selection (hash-chained log vs append-only DB vs on-chain), access layer choice, retention boundaries between forensic and operational telemetry — all instance-level decisions. The constitution sets the property; instances choose the technology.