Loading...
Loading...
OmegaEngine · Evidence · Proof Classes
'Cryptographically signed' and 'tamper-evident' have become checkbox words on audit-trail datasheets. They are not one claim — they are at least four different claims, with very different failure modes. This page is a vendor-neutral taxonomy you can apply to any receipt or audit product, including ours. We place our own artifacts in it honestly, weakest class first.
Every audit artifact on the market falls into one of these classes. The question that separates them is not the algorithm — it is who can check the claim, and what stays invisible even when the check passes.
The issuer keeps the verification secret. Checking the artifact means asking the issuer whether it is valid. The answer is the issuer's word — useful for detecting accidental corruption, but not independent proof of anything.
A public-key signature over the artifact. Anyone with the artifact and the published public key verifies integrity and issuer, offline. But each receipt stands alone: a receipt that was silently deleted simply never surfaces. Absence leaves no evidence.
Records chained by hash, held by the operator being audited. Proves the order and integrity of the chain you are shown. But the operator holds the only copy — a forked or truncated chain verifies just as cleanly as the original.
Records committed to an append-only log the audited party does not control, with RFC 6962 inclusion and consistency proofs verifiable offline. Deletion or rewriting breaks the consistency proof — absence finally becomes evidence.
| Class | What it proves | Verifiable by whom | What it CANNOT prove |
|---|---|---|---|
| 1 · HMAC manifest | The issuer will vouch for these exact bytes when asked | Only the issuer (and anyone willing to trust the issuer's answer) | Anything independently — there is no offline check, no issuer-independent integrity, and no deletion evidence |
| 2 · Signature-only receipt | This artifact is unaltered and was signed by the holder of this key | Anyone, offline, against the published or pinned public key | That the artifact belongs to a complete set — a deleted receipt is indistinguishable from one that never existed |
| 3 · Operator-held hash chain | The records in this chain are intact and in this order | Anyone holding a copy of the chain | That the operator did not fork or truncate it — a shortened chain verifies perfectly |
| 4 · Third-party append-only log | This record existed by the log head's timestamp (inclusion), and the log's history was never rewritten (consistency) | Anyone, offline, with standard RFC 6962 Merkle math; monitors can mirror the log independently | Completeness of what was never written, or truth of the recorded contents — see the honest boundary on our audit page |
Classes 1–3 all share one structural blind spot: none of them can show that a record was deleted. A signature proves what you are holding; it says nothing about what you are not holding. Only class 4 turns absence into a checkable claim. Even class 4 has limits — it cannot prove completeness of events that were never logged, or that recorded events happened as described. We spell out that boundary on the audit trails page rather than repeat it here.
If you are evaluating any receipt or audit-trail vendor — ours included — one question sorts the classes faster than any datasheet:
“Can you prove that a receipt was notdeleted?”
A class-1 vendor answers with their word. A class-2 vendor can re-verify every receipt you still have — which is exactly the problem, because the question is about the ones you don't have. A class-3 vendor shows you a chain they control. Only a class-4 vendor can hand you an inclusion proof against a published log head, plus a consistency proof that the log's history was never rewritten — both checkable offline, without trusting the vendor. Whoever you buy from, ask for the consistency proof.
A taxonomy is only useful if the vendor publishing it applies it to themselves, starting with the weakest entry. Here is our own artifact map, no rounding up:
| OmegaEngine artifact | Class | The honest claim |
|---|---|---|
| Evidence Pack manifest | 1 | The pack's own attestation wrapper is HMAC-SHA256, verified by POSTing it back to /api/v2/evidence-pack/verify. That is server-verified — the pack as a whole is not offline-verifiable, and we won't pretend otherwise. The offline-verifiable evidence is what ships inside it: the signed attestations below. |
| Agent Security Attestations | 2 + 4 | Ed25519-signed (class 2: integrity + issuer, offline, against our published JWKS) and published to our RFC 6962 transparency log (class 4: inclusion and consistency proofs, offline). |
| OmegaReceipt v1 decision receipts | 2 | Ed25519-signed with strict domain separation, offline-verifiable. Decision receipts are not individually published to the public log — they reach class 4 only via the customer-initiated ledger anchoring below. |
| Local omega-audit ledger (un-anchored) | 3 | A hash-chained ledger file held by whoever runs the agent. Tamper-evident to anyone holding the file — but until anchored, the holder could truncate it. That is precisely why the anchor verb exists. |
| Anchored customer ledgers (Pro+) | 4 | The ledger's Merkle root is anchored into our append-only transparency log via POST /api/v2/anchor, with inclusion and consistency proofs. Append-only is enforced at the database: a trigger rejects any UPDATE or DELETE of log leaves. |
Two boundaries stated plainly. First: the transparency log holds attestations, customer ledger anchors, and identity revocations — not every decision record; decisions anchor via the ledger mechanism, customer-initiated. Second: the log's signed tree head timestamp is operator-attested until external witnessing ships. Both caveats live permanently on the audit trails page; hold us to them.
The claim above is checkable in one command. This fetches a sample attestation from the live API and verifies its Ed25519 signature and content hash locally, on your machine — the verifier is open source (Apache-2.0, zero runtime dependencies):
# Verify a live sample attestation on YOUR machine — no account, no API key.
# The signature and hash math run locally; the API serves the artifact and key set.
npx -y @omegaengine/verify@latest sample --api=https://omegaengine.ai
# Exit codes: 0 verified · 1 not verified · 2 usage error
# Note: flags take the equals form (--api=..., --jwks=...).The full walkthrough — pinning the key set, fetching inclusion and consistency proofs, and monitoring the log so you don't have to take its word either — is on Verify Without Trusting Us.