Ω Omega Protocol Bring us a question
§ 10

How checks fail

A check can fail to establish its intended property because of what it observes, what it can express, where it sits in the execution path, what it assumes, and what its oracle actually distinguishes. 9 recurring mechanisms, across proof, testing, evaluation and audit. None of them is new. What is useful is having them named, so a check can be held against the list.

Seven are grounded in public repositories, one is self-documented, and one is stated without an instance and labelled as such rather than illustrated with a borrowed example. Where a finding on this site is an instance of a mechanism, it is linked from the mechanism.

Three of the mechanisms, drawn

A monitor beside the action and a control on the path action effect monitor beside the path: records "prevented"; the effect already happened action gate effect on the path: a refusal is an effect that did not happen

Position: a monitor beside the action records intentions that read as outcomes.

Authorised operation and executed operation are two objects policy: allow 4 KB authorised op ledger: VERIFIED executed op 100,000 bytes written mediation held; the binding between the two operations did not

Observation boundary: mediation held on the authorised operation; the executed one was a different object.

Properties derived from a specification cover part of the intended requirement the requirement the design was meant to satisfy properties from the spec all pass never stated nothing checks it two injected defects passed every property

Faithfulness and expressibility: the properties written from the specification pass; the requirement they were meant to stand for was never stated.

§ 10.A

What the instrument observes, expresses and assumes

§ 10.1

Expressibility failure

The formalism cannot state the property; the verdict is indistinguishable from an honest negative.

Detected by. Enumerate the expressible properties before selecting a formalism; record the rest as not-applicable.

In full

In capctl-iris the per-key formalism proves each key stays within its own cap. It cannot state the tight bound across keys; `per_key_misses_tight_global_bound` is an explicit counterexample where every per-key check passes and the aggregate exceeds the intended global limit. The formalism returns no error because it cannot pose the question. A missing capability reads the same as a satisfied one.

Instance. capctl-iris, SCOPE.md, Floor E (per_key_misses_tight_global_bound)

Seen in
§ 10.2

Faithfulness failure

The formalism states a property, and it is not the one intended; the check is valid and the theorem is wrong.

Detected by. Validate the instrument against known-answer cases before reading its output as evidence, including a positive control the check is known to pass.

In full

An early evidence grader graded a record ASSERTED, read as "a bare claim, nothing to recompute", whenever the record carried no integrity hash. The code branched to ASSERTED the moment the hash field was absent and returned, before any re-derivation ran. The trigger condition was "no integrity hash present"; the reported verdict was about re-derivability. Those are different propositions. The instrument's implemented test never matched the property it reported, and a null result was read as a fact about the world when it was a fact about the method.

What would have caught it was a positive control: a single known-answer case where re-derivation was known to succeed. That case would have returned ASSERTED and exposed the mismatch on contact. There was none.

This instance is self-documented and first-person, recorded in the grader's own migration note before publication. Its repository is not yet public, so a reader cannot reproduce it from a public clone until the grader is published; it is shown here as a documented account, not a publicly reproducible one.

Instance. evidence_witness.py:262 (v0.3), self-documented first-person in the grader's migration note ('Defect 1'). SELF-DOCUMENTED, its repository is not yet public, so it is not reproducible from a public clone until the grader is published.

Seen in
§ 10.3

Wrong observation boundary

The instrument observes a surface where the behaviour does not occur.

Detected by. Compare the declared surface against the reachable surface directly.

In full

An authorisation check that reads a server's advertised tool list sees the tools the server chooses to declare. The behaviour that matters, what can actually be called, happens on a different surface. mcp-boundary-audit demonstrates the gap on a mock server built to exhibit it: a tool filtered out of the listing is still reachable through the call path. The check on the declared surface passes; the reachable surface is where the action is. The measurement is a demonstration of the mechanism, not a survey of real servers.

Instance. mcp-boundary-audit (demonstrated against an authored mock server, not a field measurement)

Seen in
§ 10.4

Hidden trusted base

Something unexamined is load-bearing and unnamed.

Detected by. Enumerate axioms and dependencies mechanically, and publish them beside the claim.

In full

A machine-checked proof reports what it depends on only if you ask it. The OMEGA tamper-evidence theorems hold relative to an opaque `compute_hash`, the proof does not establish that this function is SHA-256, and the vsf-cjson round-trip theorem is true of a hand-written specification whose faithfulness to the C parser is argued, not proven. Neither is a defect; both are load-bearing assumptions. The failure is leaving them unnamed. `#print axioms` and an explicit trusted-base line make the dependency visible next to the result.

Instance. omega-lean-proof (opaque compute_hash); vsf-cjson (SPEC.md as trusted input)

Seen in
§ 10.5

Self-certification

The artifact vouches for itself; agreement with a function of its own inputs carries no independent information.

Detected by. Identify what would have to be corrupted for the check to pass falsely; if it is inside the artifact, there is no independent anchor.

In full

In evaltrust two of the three judge models also produced answers in the graded set. When such a judge agrees with the answer, part of what is measured is the model agreeing with itself. The agreement is real; it is just not independent of the thing being checked. An anchor outside the artifact. An objective key, an independent grader, is what breaks the symmetry. Re-deriving a value from the producer's own inputs and finding it matches is the same shape: self-consistency, not corroboration.

Instance. evaltrust, README.md:107-108

Seen in
§ 10.6

Missing provenance

The result is real and cannot be tied to what produced it.

Detected by. Re-derive the claimed output from recorded inputs, not just recheck integrity.

In full

A record can be intact and still not be tied to what produced it: an integrity check confirms the bytes are unchanged, not that they follow from the recorded inputs. The detection method is to re-derive the claimed output from the recorded inputs rather than recheck a stored hash, and where that re-derivation cannot be reproduced. A different numeric environment, an input no longer available, the honest verdict is UNKNOWN, not verified. Detection power ends exactly where re-derivation from inputs ends.

**This mechanism is stated without a worked instance, UNGROUNDED IN PUBLIC.** Unlike the other eight, it has no publicly reproducible failure case here. The clean example would be an intact record that cannot be tied to its inputs, and the artifact that would exhibit it is not published, so it cannot be reproduced from a public clone. It is given as mechanism and detection only, rather than borrow an instance from a different artifact.

Instance. UNGROUNDED IN PUBLIC, no publicly reproducible failure instance; stated as mechanism and detection only, no instance borrowed

§ 10.B

What is concluded from a result

§ 10.7

Coverage illusion

A passing suite is read as the absence of failure.

Detected by. Negative controls that must actually fire.

In full

A green suite shows the cases you wrote passed, not that the cases you did not write would. compositional-temporal-safety, escrow-budget and nanogpt-provenance each ship negative controls: remove a budget guard and a theorem must now fail; forge a loss under a foreign environment and the verdict must drop. A control that cannot fail proves nothing about the check; a suite of only-passing tests measures its own coverage, not the property.

Instance. compositional-temporal-safety, Negative.lean (4 controls); escrow-budget (4 controls); nanogpt-provenance (12 controls)

Seen in

Worked example

A system passed all 24 of its recorded tests and still had a serious flaw. Passing everything you checked is not the same as checking everything that matters.

§ 10.8

Convergence mistaken for correctness

Independent methods agree, and agreement is read as truth.

Detected by. Score each method against known-answer cases separately before comparing them to each other.

In full

compositional-temporal-safety computes a reachable state count in Python and checks it equals the recorded model-checker count. The two agree, at one bounded configuration, against a stored constant, without re-running the model checker. The repository labels it bounded agreement, not a refinement, and does not read the match as proof that the models coincide. Two methods that agree can be wrong in the same way; agreement is evidence only once each has been scored against a known answer on its own.

Instance. compositional-temporal-safety, impl/test_model.py:6

Seen in
§ 10.9

Complementary read as confirmatory

Two methods establish different properties and the reader infers corroboration.

Detected by. A properties by methods table with an explicit NOT APPLICABLE cell; the empty cells are the finding.

In full

escrow-budget was verified two ways. A Lean proof establishes the budget bound, total spend stays within the cap. A separate method, multiparty session types with crash-stop in Rust, establishes the communication skeleton: deadlock-freedom, communication safety, progress. Laid out as a properties-by-methods table, the informative cells are the ones marked NOT APPLICABLE. The session types cannot express the budget bound at all. They range over the order and typing of messages, not arithmetic over aggregate state, and the action that consumes budget sends no message, so it is invisible to the type. The Lean model cannot express communication safety. It has no typed-channel layer where a reception mismatch is even statable. Reading "verified under both Lean and session types" as a second confirmation of the cap theorem would be false: the session-type method never touches the cap theorem. Two green methods, different properties; the empty cells are the finding, not the corroboration a reader supplies to fill them.

Instance. escrow-budget-mpst @ 59bbc08, COMPARISON.md (the NOT APPLICABLE cells); escrow-budget, CLAIMS-AUDIT.md:21

§ 10.10

The same list, held against this site

The generator that builds these pages derives every count and halts on a bad denominator; a publication audit runs in series and is exercised by 25 injected leak classes; the build gates are exercised by mutations that must make the build fail. That is coverage illusion (§10.7) and self-certification (§10.5) applied to the site's own claims, and it is described on the method page.