Product
The OMEGA record
One structured record per consequential action. Built to be read by a regulator, an auditor, or a counterparty after the fact.
What OMEGA produces
OMEGA produces a single artifact: a structured, cryptographically hash-chained record per consequential action taken by a system or person under the firm's governance. The record is the same shape across autonomous agents, model-influenced human decisions, and human-only decisions inside regulated workflows. One schema. One audit target. One thing the regulator, auditor, or counterparty has to learn how to read.
The record is produced at the moment of the action, not assembled afterwards. It is hash-linked to the record that came before it, so the chain detects any later attempt to rewrite history. It is stored in your environment, retrievable by record ID, and indexed for both exact lookup and semantic search.
What the record contains
Each OMEGA record binds the action to the answers a reviewer will ask for. In plain language:
| Field | What it answers |
|---|---|
| Authority | The named individual or role responsible for the action, and the scope they are authorised to act within. |
| Freshness attestation | Proof that the authorised individual was authenticated within a declared window before the action. Stale sessions cannot produce records the authoriser never approved. |
| Reasoning | The evidence considered, structured so each step can be traced back to a fact, a declared unknown, or a named assumption. |
| Rejected alternatives | The options that were considered and the basis for rejecting them. Records are not allowed to claim a decision was made without alternatives. |
| Expected outcome | What the action was expected to produce, and the conditions under which that expectation holds. If the environment shifts outside those conditions, the expectation is automatically invalidated. |
| Delegation chain | If the action was delegated, who delegated to whom, with the scope and threshold attached to each step. |
| Materiality | The financial, clinical, or operational consequence of the action, bound to the authority's scope. Aggregate materiality across linked sub-actions is preserved, so a stream of small decisions cannot bypass a material threshold. |
| Competence attestation | For decisions influenced by a model, the model version in use and the named individual who attested to its fitness for the decision class. |
| Update integrity | If the model or expectation has been updated since attestation, a controlled record of that update. Silent drift between the attested model and the live model is detectable. |
| Chain integrity | A cryptographic hash linking this record to its predecessor. Any subsequent modification to the chain is detected by anyone who recomputes the hashes. |
How it works
OMEGA sits next to your existing systems. It does not replace your decision logic, your model, your policy engine, or your observability. It produces the second artifact, the one designed for a regulator to read, alongside whatever else you already produce.
Step 1
The record is composed at decision time
At the moment of a consequential action, OMEGA receives the inputs that answer the fields above: who, what was considered, what was rejected, what was expected, under what conditions. Inputs can come from the agent, the operator, an existing case management system, or a combination.
Step 2
The record is validated and hash-chained
The record is validated against a fixed JSON schema. A cryptographic hash of the contents is computed and linked to the prior record in the chain. The endpoint returns a record identifier and chain position. Validation is strict: a record missing any required field is rejected, not accepted with gaps.
Step 3
The record is stored and indexed
Records are persisted with their chain metadata. Each accepted record emits an observability trace, so the reasoning behind every record stays inspectable in your tracing stack. Records are also embedded into a vector index, so a reviewer can find related decisions by meaning, not only by ID.
Step 4
The record is retrieved and verified
Any party with read access can retrieve a record by ID or by query, and independently recompute the chain hashes to confirm the chain has not been tampered with since. Verification does not require trust in the firm that produced the chain.
What you can do with the record
- Answer the regulator's question. When a market surveillance authority, FCA examiner, notified body, or FDA reviewer asks for the evidence behind a specific decision, you hand over the record. The format is fixed and reviewer-readable, not a folder of emails, policies, and screenshots.
- Reconstruct what was known and expected. For an after-the-fact review, the record shows what evidence was available, what was rejected, what was expected, and under what conditions. The team does not have to reconstruct intent from logs.
- Detect tampering without trusting the producer. A counterparty can recompute the chain and confirm it has not been silently rewritten. The integrity claim does not rest on the firm's own attestation.
- Bridge automated and human decisions. The same record shape covers an autonomous agent action and a Senior Manager sign-off. Both connect to the same accountability framework.
- Support incident review and root cause analysis. Linked records produce a chain through a sequence of related decisions. The investigator follows the chain rather than reconstructing it.
- Demonstrate consistent governance across systems. One schema applies across business lines and across regulated frames. The same record is acceptable evidence under EU AI Act human oversight, FCA Senior Manager accountability, and FDA design control review. See Solutions for sector-specific framings.
What this does not do
OMEGA does not validate the substantive correctness of the decision it records. It does not approve the model, replace red-teaming, or substitute for the firm's first- and second-line controls. A record produced from poor inputs is a record of poor inputs.
The record schema has been formally verified for internal coherence: each required field is necessary, and the full set together is sufficient to call a record governed. That verification is about the schema, not the truthfulness of any particular record. See Proof and Verification for what is and is not formally established.
Why a log is not a governed record · Read the specification · View example records · Solutions by sector