SPEC

OMEGA Protocol Specification v1.4.3

Status: Published. v1.4.3 current; the v1.4 structural-integrity spec was published 21 April 2026. Per-version dates are in the version history below.

The published schema set at /schemas/ currently defines the aggregate trust-ledger envelope; a normative single-decision record schema is in development.

Protocol specification: MIT licensed. Freely cite with attribution.

Canonical reference: omegaprotocol.org/omega/spec/v1

Implementation status: /omega/implementation/

Required fields in the record schema. Verified properties of this specification are listed at /omega/formal-proof/.

What this specification establishes

OMEGA defines a record structure for governed decisions. The specification describes what a committed record should contain: who authorised it, the reasoning chain, the predicted outcome, confirmation encoding, and cryptographic provenance. Integrators compose and seal records in their own stacks; this document defines the schema and field names - not a public runtime that enforces gates.

Schema vs enforcement. Fields such as P5 Confirmation are record fields and outcome encodings (HELD / COMMITTED / ESCALATED). They document whether a gate was recorded - they do not, by themselves, block execution. Enforcement, if any, is integrator responsibility outside this specification.

Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, and MAY in this specification are to be interpreted as described in RFC 2119.

Conformance

This specification defines two conformance levels for the single-decision record. Its normative machine-readable schema is in development; until it ships, conformance is defined by the field requirements in this document, not by validation against a published single-decision schema. The published schema set defines the aggregate trust-ledger envelope, a separate artifact.

Core. The five schema-v1.0 structured fields: P1 Governance, P2 Reasoning, P3 Traceability, P4 Expectation, and P5 Confirmation. A conforming record MUST contain all five Core fields.

Extended. All remaining fields: P4M, P4T, P5E, P6, P6A, P6L, PCF, P10, P11, P12, and P14. A record MAY carry Extended fields; where an Extended field is present, it MUST satisfy that field's requirements as defined below. Structured schema encodings for the Extended fields are not yet published.

The fields

A conforming record MUST contain the five Core fields defined in Conformance; the remaining fields are Extended, MAY be carried, and where present MUST satisfy their requirements. Removing a Core field makes a distinct governance failure possible that the others cannot compensate. v1.4.1 adds predicate-bound durability as P14 at the record-schema layer.

Start with the homepage reconstruction (the refund record cs-agent-refund-1187442) - then use this page as a guided tour. Each field below is anchored to that example record.

Draft status. The field reference below describes the single-decision record schema currently in development. The field names and requirements are stable enough to build against, but they are not yet normative, and no machine-readable schema for this single-decision shape has shipped yet.

P1: Governance

P1 Governance records the authorising identity, its constraints, and its scope at the moment of decision.

In the refund record, this is the Authority line - Sarah Okafor (Senior Customer Operations Manager, badge #ops-2218) approving under refund authority schedule v2026-02-17, above the agent's £2,500 Tier C limit.

P2: Reasoning

P2 Reasoning records the fact, inference, assumption, and unknown chain connecting inputs to the decision, expressed as a causal graph with magnitude and likelihood labels on every effect node; v1.4 requires that graph to be acyclic (P2_DAG), and unknown is a first-class element the system declares rather than hides.

In the refund record, this is the Evidence & Reasoning field - order £4,820, three customer photographs, a specification mismatch, with the agent's advisory reasoning and the supervisor's independent review recorded separately.

P3: Traceability

P3 Traceability hash-chains records with SHA-256 in append-only order, so modifying any record breaks every downstream hash and a record stays verifiable even after the entity that made it no longer exists.

In the refund record, this is the Traceability block - content_hash e747c3fd…996c09, seq 1187442, where recomputing the hash confirms the record still matches what was committed.

P4: Expectation

P4 Expectation records an explicit commitment to a predicted future state, locked before any action is taken.

In the refund record, this is the Expected outcome field - a full £4,820 refund to the original payment method, return collection booked, a £120 goodwill credit, and settlement within 3 to 5 business days.

P5: Confirmation

P5 Confirmation marks the boundary between deliberation and execution in the record.

In the refund record, this is the Confirmation block - identity verified through SSO plus hardware key, with a signed approval token issued and consumed once at commit.

P4M: Materiality Binding

P4M Materiality Binding: the P4 prediction MUST correspond to the highest magnitude × likelihood node in the P2 causal graph, and MUST NOT be a trivial prediction that masks a catastrophic assumption; the check is deterministic and structural, not NLP extraction.

Not exercised by this record: a single-step refund that commits one expectation with no materiality binding to a causal graph. P4M is defined in this field reference.

P4T: Trajectory Expectation

P4T Trajectory Expectation: for a multi-step sequence the agent MUST pre-commit to an aggregate predicted outcome before the first action, MUST reaffirm it at specified checkpoints, and MUST open a new P4T obligation on declared divergence.

The refund is a single-step decision; trajectory expectation applies to multi-step sequences such as fleet deployments or clinical protocol amendments.

P5E: Execution Attestation

P5E Execution Attestation MUST cryptographically bind the approved record hash to the actual execution payload, attesting the complete executed code closure including dynamically loaded code; unattested binaries MUST NOT run.

In the refund record, the human approval token is redeemed once and permits exactly one refund commit at Tier C, binding the approval to the action that executed.

P6: Delegation

P6 Delegation: any agent spawning or delegating to a sub-agent MUST either obtain a governed OMEGA record from that sub-agent or explicitly declare the delegation ungoverned and accept full liability transfer; transitive accountability is enforced.

In the refund record, the customer-service agent acts under a published refund authority schedule (Tier A and B autonomous, Tier C escalated) - the handoff from the agent to the human supervisor is the governed delegation.

P6A: Aggregate Materiality

P6A Aggregate Materiality: before delegating, the orchestrating agent MUST produce a consolidated causal graph and P4M-compliant prediction covering the aggregate outcome of the entire delegated workflow, since individual compliance does not imply aggregate compliance.

P6L: Liability Threshold

P6L Liability Threshold: ungoverned delegation MUST be blocked when estimated consequence is major or catastrophic; a cumulative risk counter SHOULD trigger human review at configurable thresholds.

PCF: Continuity-Formal

PCF Continuity-Formal: the anchor baseline and drift bounds MUST be expressed as measurable quantitative metrics, evaluated by a deterministic rules engine rather than an NLP system that adversarial framing can defeat.

P10: Competence Attestation

P10 Competence Attestation records a cryptographically-bound competence claim from a designated attestation authority, linked to the decision record at the moment of authorisation; it records that a claim was made, not that the agent is competent, since ground-truth competence is not cryptographically establishable.

A P10 record MUST include:

Not carried by this record: no competence attestation was issued for this decision. P10 is defined in this field reference.

P11: Expectation Update Integrity

P11 Expectation Update Integrity is the cryptographically-bound mechanism for updating a pre-committed expectation when new evidence materially invalidates it, preserving the accountability chain while preventing silent or trivial revision; it reduces but does not eliminate adversarial update laundering.

A P11 update MUST:

Not exercised by this record: a same-day decision with no expectation update. P11 is defined in this field reference.

P12: Semantic Integrity Validation

P12 Semantic Integrity Validation binds expectation fields to a semantic schema at commitment time and verifies the resolution against the same schema positions, routing any update to a bound field through P11 rather than silent revision; it is decidable within the schema and does not solve the general, undecidable natural-language equivalence problem.

A P12-bound expectation MUST have:

Not carried by this record: the expectation fields here are not schema-bound. P12 is defined in this field reference.

Why all of them together

The complete set defines the required structure for a governed decision record across single agents, multi-agent delegation chains, decision trajectories over time, and protocol versions.

A(α,π) = P14(π) ∧ G ∧ R ∧ T ∧ E ∧ P4M ∧ P4T ∧ C ∧ P5E ∧ P6 ∧ P6A ∧ P6L ∧ PCF ∧ P10 ∧ P11 ∧ P12

Each field closes the failure mode listed against it.

RemoveFailure mode
P14 Predicate CommitmentVersion drift: record interpreted against the wrong predicate
P1 GovernanceUngoverned action: rogue decisions indistinguishable from valid
P2 ReasoningHollow reasoning, FM_R active, opaque decision logic
P3 TraceabilityMutable history: retroactive rewriting possible
P4 ExpectationNo falsifiable prior: post-hoc prediction
P4M Materiality BindingDecoy prediction: trivial P4 masks catastrophic assumption
P4T Trajectory ExpectationTemporal arbitrage: locally compliant sequence, catastrophic aggregate
P5 ConfirmationGate bypassed: intent collapses directly to action
P5E Execution AttestationRace condition: payload substitution after approval
P6 DelegationUngoverned delegation: liability escapes through sub-agents
P6A Aggregate MaterialityChain fragmentation: compliant hops, catastrophic combination
P6L Liability ThresholdLiability dumping: high-risk routed ungoverned
PCF Continuity-FormalContinuity spoofing: evaluator defeated by adversarial framing
P10 Competence AttestationAuthority without competence basis: governed records with no certified capability (“perfectly recorded incompetence”)
P11 Expectation Update IntegrityObsolete or silently-updated expectations: brittle priors or unaccountable revision
P12 Semantic Integrity ValidationVacuous expectations: no schema binding, any outcome satisfies the record

Honest limits

Six failure modes are structurally unclosable by this protocol; they are named with their closure requirements in the formal doctrine.

P14: Predicate Commitment

Evaluated first in the authorisation formula above; introduced last here because it commits the record to all elements above. P14 is a schema field for record metadata.

P14 Predicate Commitment cryptographically commits every governed record to the predicate version it satisfies, the predicate definition hash, the attestation method, and the attestation hash; P1 through P12, P4M, P4T, P5E, P6A, P6L, and PCF are claims of satisfaction against the resolved predicate definition it names.

P14 requires:

Not carried by this record: it is a Schema omega/1.0 record, which predates P14. P14 is defined in this field reference.

v1.4 Structural Integrity Constraints

v1.4.1 adds structural integrity constraints that tighten how existing fields MUST behave under adversarial conditions. These are not new schema fields. v1.4.1 also adds P14 as a schema field. The constraints are P2_DAG, P6_AtomicAgency, P1_Freshness, P4T_EnvInvariant, and P_ChainIntegrity.

P1 Freshness

Pattern addressed: Stale authorisation.

Plain language: Authority MUST be valid at the moment of action.

Technical mechanism: Authorisation MUST use multi-factor validation within a 60-second freshness window and a maximum 300-second replay tolerance.

P2 DAG Enforcement

Pattern addressed: Circular reasoning.

Plain language: Decisions MUST NOT justify themselves using their own outputs.

Technical mechanism: The reasoning chain MUST form a directed acyclic graph where every node resolves to independent evidence.

P6 Atomic Agency

Pattern addressed: Shadow delegation.

Plain language: An action MUST NOT hide a chain of delegated decisions.

Technical mechanism: Every internal cognitive step and every inter-agent handoff MUST be recorded as a first-class delegation event.

P4T Environment Invariant

Pattern addressed: Environmental drift.

Plain language: Predictions only hold while their assumptions remain true.

Technical mechanism: Predictions MUST bind to explicit environment assumptions and MUST be revoked if those assumptions change.

P_ChainIntegrity

Pattern addressed: Silent chain rewrite.

Plain language: The hash chain MUST remain intact from genesis to tip; tampering past any record is detectable by external recomputation.

Technical mechanism: SHA-256 content_hash linked by previous_hash; any modification invalidates the chain past that point.

Version history

VersionDateChange
v1.0Mar 2026Base fields
v1.1Apr 2026+P4M, P5E, P6
v1.2Apr 2026+P4T, P6A, P6L, PCF
v1.320 Apr 2026+P10, P11, P12
v1.421 Apr 2026Structural integrity (prose)
v1.4.125 Apr 2026Lean bundle
v1.4.2Jun 2026Payload tamper-evidence (Lean)
v1.4.3Jun 2026JSON tamper-evidence, no user axioms

The current Lean bundle (v1.4.3) is kernel-checked for the internal consistency of the governance conjunction and for tamper-evidence, with zero sorry and zero user axioms. It does not prove that the formal definitions match this prose specification, nor that the field set is sufficient or independent; field failure-mode necessity is machine-checked separately in SymPy for nine fields. See the formal doctrine for the full proven-versus-assumed split.

What OMEGA does not claim

A valid record means those fields are present and the hash chain is consistent. The integrator still has to write honest fields at runtime. Whether the decision was right is a separate question.

OMEGA does not prove a decision was correct. OMEGA does not prevent bad decisions. OMEGA does not replace human judgment. OMEGA does not guarantee reasoning is causally connected to the decision unless P2 is bound to actual execution traces. OMEGA does not access model weights or activations: it cannot distinguish genuine reasoning from perfect post-hoc rationalisation (FOU honest limit).

What the record looks like

Every OMEGA governed record is self-contained. It remains verifiable even after the system that produced it no longer exists. It cannot be generated after the fact without breaking the hash chain. It cannot be altered without detection by anyone holding the chain tip or an external anchor.

The non-action record is as important as the action record. A system that evaluated and held has no trace of that evaluation in any current observability tool. In OMEGA, the HELD decision is a first-class record.