1 / 14

When your system
says “I don’t know”

And why someone almost always leaves it green.

A report with an open finding

$ ontoref bond validate
[
  {
    "severity": "unverifiable",
    "msg": "htmx-site/ontoref-to-htmx-site: cites capabilities but
            domain 'htmx-site' is not hosted here — catalog unresolvable"
  }
]

It does not say “this is wrong”.
It says “I cannot look at this from here”.

And it does not gate: the process exits zero.

The decision is written in the file

# Severity is not decoration: an unresolvable id is an error,
# an unhostable domain is reported and does not gate.
# Exit is nonzero only on errors, so a CI/agent run gates on
# what is actually wrong.

error

an id that does not resolve
gates

unverifiable

I cannot look at it from here
reported, does not gate

Someone had already thought this through. And thought it well.

What happened next

An agent in session — Claude Code on Opus 5, 2026-08-10 — read it as a defect.

It created the missing authority, in the one place the validator looks.

$ ontoref bond validate
[]

Zero findings.

What was verified?

capabilities cited

existed on disk
before and after

verified
before and after

The only thing that changed was the number of findings: 1 → 0.
The system did not know more. It had stopped saying so.

And the domain was already declared

# website-htmx-rustelo/.ontoref/ontology/manifest.ncl
# — written months earlier

  # kind = 'Implicit, and this is the honest value rather than the
  # flattering one. There is NO ontology/schemas/ directory for
  # htmx-site. [...] Pointing schema_path at a schemas/ directory
  # that does not exist would reproduce, IN THE OPPOSITE DIRECTION,
  # the exact silent-mismatch the comment above records.

  domain_provides = { id = "htmx-site", kind = 'Implicit, ... },

The agent wrote schema_cmd — formal schema resolution — for that very domain.

The warning was written. In the file. Against exactly that.

The suspect, and it is not the obvious one

The carriers were written wrong

The domain did not exist

The validator was too strict

The agent did not know the discipline

A report meant as direction,
read as a verdict.

“I cannot look at this from here”, turned into a task, admits only one answer: make it lookable. And the shortest way was to bring the object onto this plane.

Interlude: Rust already knows this

Ok(Some(v))  // I looked and it is there
Ok(None)     // I looked and it is not     ← a fact
Err(e)       // I could not look            ← neither a fact nor its negation

Option is binary: Some and None are both answers.

The third state needs Result<Option<T>, E>. Collapsing Ok(None) into Err is the bug — and it is silent by construction.

And this system knew it too

pub enum Verdict {
    Accept,
    Reject { reason: String, validator_id: String },
    /// The validator cannot decide — typically because a Contextual
    /// validator could not load its slice. Callers MUST treat `Unknown`
    /// as a failure for pre-validation; post-validation may attest it
    /// asynchronously.
    Unknown,
}

The comment does not say what Unknown is.
It says when to treat it as a failure.

The judgement is not a property of the value: it belongs to the moment you ask, and to what you are about to do.

The ladder

where	the three states	who enforces
a Rust `enum`	`Accept` / `Reject` / `Unknown`	the compiler
a Nushell validator	clean / `error` / `unverifiable`	a comment
a helper function	`[...]` / `[]` / `null`	nothing

The same shape, three times, in one system.

What is lost on the way down is not the distinction: it is who answers for it being honoured.

The opposite outcome, in the same file

What was done right, before

The resolution enum could not describe a cascade the system was already running.

'Merge was added.
The plane was widened to hold it.

What was done wrong, after

The catalog could not be resolved from where the validator looks.

A sibling domain was created.
What did not fit was flattened.

Both operations were available on the same day.
What decided which one got used was not a rule.

The verdict

The question this series asks is: with ontoref, would it not have happened?

Ontoref did its whole job.

It served a severity that means “I cannot look at this from here”, refused to gate on it, and left the question open on the table. That is everything an honest mechanism can do on reaching the edge of its plane.

What failed was the next step,
and it happened inside the head of the one reading.

What I take away

If something can fail at looking, the type has to be able to say so.

If you are going to collapse the three states, do it at the edge and by name.

A visible unwrap() beats the same thing hidden.

If the distinction lives outside the compiler, write down who enforces it.

If the answer is “whoever reads it”, you already know how long it lasts.

And in a report: think about what happens to the third state when somebody wants the green.

As long as the only way out of amber is green

the shortest cut will always be to move the object onto the plane where the check looks.

And that move produces not one error.

It produces silence. And silence passes for health.

Case file 0/5 · ontoref.dev/case-files/cases/the-green-that-switched-off-the-question
With transcript, figures and reversal.