Why a log is not a governed record

Observability stacks were built to debug systems, not to govern them.

Observability stacks answer "what did the system do?" - usually well enough. They were never built to answer "who was authorised to do it, what did they expect, and what alternative did they reject?" Those are the questions a regulator, an auditor, or a counterparty asks after something has gone wrong. A log cannot answer them.

Side-by-side comparison

Question	Logs / Traces	OMEGA Record
What happened?	Event payload, timestamp, latency	Same, plus action hash
Who took the action?	Service / user ID	Authorised principal under declared authority (P1)
Were they authorised at the moment of action?	Implicit in auth middleware, not in the record	Freshness attestation within declared window (P1_Freshness)
What evidence was considered?	Not recorded	Reasoning DAG grounded in fact / unknown / declared-assumption (P2, P2_DAG)
What alternatives were rejected?	Not recorded	Required (P2)
What was the expected outcome?	Not recorded	Required (P4); environmental invariants required for trajectory commitments (P4T_EnvInvariant)
Can the chain be silently rewritten?	Often yes - log retention is mutable	Hash chain detects tampering at any point (P_ChainIntegrity)
Can a sub-process bypass governance by claiming "internal function"?	Frequent failure mode	Atomic Decision Boundary blocks this (P6_AtomicAgency)
Is the record schema formally verified?	No	Yes - kernel-checked Lean 4

Logs are necessary. They are not sufficient.

OMEGA does not replace your observability stack. It sits next to it and produces the second artifact - the one a regulator can read.

Inspect the Lean 4 proof   ·   Read the specification   ·   View example records