Context
BSFG is a durable boundary history, not a mutable application table. The system must preserve auditable fact lineage while still bounding storage growth and allowing different retention horizons for different classes of facts.
The design therefore needs to answer two linked questions:
- whether facts may be rewritten or deleted in place
- how long facts remain in retained streams before aging out
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Mutable fact records | Allow updates and replacements of previously written facts. | smaller visible history familiar CRUD model |
weak auditability history becomes ambiguous poor fit for replay and compliance reasoning |
| Infinite append-only retention | Facts are immutable and never expire. | maximal historical completeness simplest conceptual audit story |
unbounded storage growth retention cannot be aligned to data class operational cost increases indefinitely |
| Consumer-driven deletion | Facts disappear once all consumers have acknowledged them. | efficient work-queue behavior bounded storage by processing progress |
history is lost after processing not suitable as an audit substrate consumer topology changes retention semantics |
| Append-only facts with time-based retention (Selected) | Facts are immutable; retention is governed by stream class and time horizon. | clear audit lineage while data exists bounded storage growth retention can differ by fact class fits log-centric transport model |
expired history is no longer replayable from the stream corrections must be modeled as new facts retention policy must be governed explicitly |
Decision
BSFG facts are append-only. Existing facts are never modified in place. Corrections, reversals, and superseding statements are represented as new facts.
recorded fact -> immutable
correction -> new fact
superseding state -> new fact
Retention is time-based and configured per stream class.
facts.operational -> shorter horizon
facts.audit -> longer horizon
facts.documents -> governed separately from fact streams
Example default posture:
facts.operational: approximately 90 daysfacts.audit: approximately 7 yearsfacts.documents: fact references retained by policy, artifacts governed by object-store lifecycle
Consequences
Benefits:
- fact history remains unambiguous while retained
- replay semantics stay compatible with append-only logs
- different data classes can have different storage horizons
- transport behavior stays independent of consumer acknowledgement topology
Tradeoffs:
- retention policy becomes a governance concern, not an implementation afterthought
- expired historical facts require archival strategy if longer evidence preservation is needed
- operators must reason about corrections as additional facts rather than edits