RFD-0021 — Unified axiom event log; bitemporal; CBOR axiom-ADT bodies

Question

How does the kernel persist the assertions and retractions that drive its derivations? As state snapshots? As event logs? With what temporal semantics?

Decision

Unified axiom event log. ont.axiom_events is the single source of truth for assertion / retraction / declaration events. All TBox and ABox changes — concept declarations, role declarations, fact assertions, rule registrations, retractions — append to this one table.

Axiom-ADT body encoding. Each event carries a typed payload encoded as CBOR with a variant tag (AxiomBody::ConceptDecl, AxiomBody::RoleDecl, AxiomBody::Assertion, etc.). Reading an event reconstructs the typed Rust value via serde deserialization. SHA-256 of the CBOR bytes acts as the body’s canonical hash for deduplication and integrity checks.

Bitemporal semantics: valid time × transaction time. Each event records both axes:

• Valid time — when the asserted fact was true in the modeled domain.
• Transaction time — when the assertion was recorded in the system.

Retraction is implemented as a new event whose op field is Retract and whose body matches the original event’s body. Skipping retracted events during reassembly removes the original assertion from the active set.

Standpoint, module, and fork as discriminator axes — not partitions. An event carries (tenant_id, standpoint_id, module_id, fork_id) as discriminators. Queries that scope to a standpoint or module filter on these axes; events not in scope are simply not selected.

Fork axis via fork_id + structural sharing. A fork is a copy-on-write branch of the event log. Forks share the lineage above the branch point and diverge below. Forks support hypothetical reasoning, what-if analysis, and rollback.

Rationale

One log beats many. Separate event logs for TBox vs. ABox vs. retractions vs. forks would have produced cross-log consistency questions (a TBox change retract in the ABox log? do they agree on temporal ordering?). One log with typed bodies and discriminators answers all the questions in one place.

CBOR with axiom-ADT. CBOR is a compact binary format with deterministic encoding (important for SHA-256 hashing and reproducible builds). The axiom ADT preserves type information through the encoding/decoding round-trip; readers get strongly-typed values, not generic JSON.

Bitemporal because audit requires it. Financial-contract reasoning needs to answer “what did the system know when this calculation was performed” (transaction time) AND “what was true in the world when the contract clause applied” (valid time). The two axes are independent and both required.

Discriminators not partitions. A standpoint isn’t a hard wall around events — it’s a perspective filter. Events outside the scope are still in the log, just not selected by the current query. This preserves the option to compose multiple standpoints (RFD-0010 standpoint lattice).

Consequences

• ont.axiom_events is the storage primitive. All other projections (ont.axioms_current, materialized views) derive from this table.
• Schema reassembly reads events filtered by kind; retraction events skip during reassembly to remove original assertions.
• The kernel’s CBOR codec evolves with the AxiomBody enum; codec versioning tied to kernel-storage release cadence.
• Forks compose with per-tenant overlays (RFD-0020); fork_id is orthogonal to tenant_id.
• Bitemporal queries support “as of valid time T, transaction time T’” reads — required for audit trails on regulatory examinations.