Case 111/0: the rule that could not see

🕵️ Show the full case file → 📋 Session protocol →

Case file · Code Homicide Dept.

The new rule was meant to refuse when a level could not be retrieved. It judged retrieval by the exit code — and describe <unknown> prints «unknown subcommand» and exits 0, deliberately, with a test asserting it. So a level pointing at a source that does not exist came back marked as successfully materialized: 111 bytes of usage text, served as knowledge. The rule against silent provisioning provisioned silently, on its first run, written by somebody who had spent the whole day fixing exactly that.

The double ledger — what it cost, and what it left

The suspects — the false leads

The weapon — The weapon · a zero that means two different things

# the rule written to stop silent provisioning:
  materialized: ($res.exit_code == 0)

$ ontoref describe no-such-subcommand-xyz ; echo $?
  describe: unknown subcommand 'no-such-subcommand-xyz'.
  0                      # it exits ZERO — deliberate, and a test pins it

# result: the level pointing at nothing, taken as good
  constraints  Describe  materialized=True  bytes=111

The whole rule fitted on one line, and the line was reasonable:

materialized: ($res.exit_code == 0)

The problem is what that zero means in this verb. ontoref describe no-such-subcommand-xyz prints «unknown subcommand» and exits 0 — and not by oversight: reflection/tests/test_protocol_version.nu:87 asserts it as expected behaviour. The signal was mute by contract, and the verdict was bound to it.

The result, measured by breaking the constraints level on purpose: materialized=True, bytes=111. One hundred and eleven bytes of usage text handed to an agent as if they were the project’s constraints. Nothing failed. Nothing warned. The mount reported success.

The uncomfortable part is the authorship. That rule was written in the same session that closed a gate which did not look and a gate that nobody ran, by somebody who had just written that a gate which runs and cannot see is the most dangerous of the three. Knowing the pattern does not immunise against committing it.

The turn — The fix · bind to what the producer promises, and watch it refuse

let unknown = ($combined | str contains "unknown subcommand")
let empty   = (($out | str trim) | is-empty)
materialized: (($res.exit_code == 0) and (not $unknown) and (not $empty))

$ ontoref view mount coding --materialize
  view 'coding': 1 level(s) could not be retrieved — constraints.
  Mount refused (budget.on_retrieval_error = 'FailClosed).
$ echo $?
  1

Two pieces, and the second is what turns code into a rule.

Bind to the contractual signal. The verdict stops reading the exit code alone and additionally requires that the output not carry the «unknown subcommand» marker — the same string a protocol test asserts — and that it not be empty. The CLI’s exit code was not touched: exiting 0 there is deliberate and pinned by a test, so the place to correct was the reader, not the emitter.

Watch it refuse. With the constraints level pointed at a non-existent subcommand, the mount now answers 1 level(s) could not be retrieved — constraints, refuses, and returns 1. That observation is the fix as much as the code is: a rule that has not been watched failing is an intention with syntax.

And along the way a defect nobody was looking for surfaced: --materialize had been dead since ADR-048, because it invoked $project_root/ontoref while the CLI lives in code/. Nothing exercised it, so nothing reported it — the same disease, one floor down.

The verdict

The rule was well conceived and badly bound: it watched for silent provisioning while judging by a signal that cannot express the failure it watches.

What is instructive is not the oversight — five lines correct it. It is that it was committed by whoever had spent the whole day closing this same family: a check that is missing, a check nobody runs, a check that runs and cannot see. Knowing the pattern does not immunise; only falsification does.

That is why the numeric half of the bound is deliberately still absent. A ceiling nobody has measured, imported from another project, would be exactly the class of comfortable claim this case documents.

The reconstruction — the session, replayed with protocol

What was asked — reconstructed from refs:sessions/2026-08-05-ontology-illusion-barrido-y-gate — a bounded excerpt held in custody: the prompt verbatim and the oracle `ontoref describe no-such-subcommand-xyz; echo $?`, with the reason the exit code could not be the signal — it returns 0 by design, with a test pinning it.

do both: the path sweep and the gate

What should have been asked

Before trusting a rule that refuses, make it refuse.

1. Break the input on purpose and run it. A rule you have not watched fail is not a rule:
   it is an intention with syntax.
2. Do not judge by the exit code without checking that the exit code can express the failure.
   Here it could not: `describe <unknown>` exits 0 by design, and a test pins that.
3. Bind to what the producer declares by contract — the marker, the empty answer — not to
   whichever signal is most convenient to read.

The gate before delegating: A rule that refuses is not declared finished when it compiles: it is declared finished when it has been watched refusing on a real case. Without that observation, the only thing demonstrated is that the code runs.

The ADR trigger: None new — it is the application of ADR-066 (the check decides, never the reporter) to the provisioning surface. What did get recorded is migration 0056, because it changes a consumer-visible surface by default.

Case law — what enforces the lesson today

• ✓
  The materialization verdict, bound to the contractual marker and the empty answer.ontoref/reflection/modules/view.nu#materialize-level
• ✓
  The per-view bound: optional ceiling, typed abstention, fail-closed by default.ontoref/reflection/schemas/substrate-view.ncl#budget
• ✓
  The bound applied at both entry points.ontoref/reflection/modules/view.nu#enforce-budget
• ✓
  The surface change declared for consumers.ontoref/reflection/migrations/0056-provision-declares-how-much.ncl