ADR-0003: Immutable histories

Context

Users need prior file content, classification history, and trustworthy activity records. Treating every metadata correction as a content version would duplicate bytes, while editing history in place would weaken recovery and accountability.

Decision

Every byte change creates a new immutable file version and storage object. Every file classification or lifecycle change creates a separate immutable metadata revision. Every database-owned security decision or file-changing transaction creates an append-only audit event. A security request that ends at a service boundary before an attributable database decision produces bounded structured operational evidence instead of an anonymous database audit row. Archive and restore replace permanent deletion in MVP.

Consequences

• Historical bytes remain retrievable by logical file ID and version number.
• Metadata corrections do not duplicate content.
• Audit history requires an append-only database privilege or equivalent control.
• Storage grows monotonically until a separately designed retention and purge policy exists.
• Permanent purge, retention automation, and legal hold remain outside MVP.

Validation required

Accept this decision after tests prove prior versions remain unchanged, revisions contain before/after state, archived files preserve all histories, and neither application code nor database permissions can mutate audit rows through supported operations.