Unknown Is Not False

Imagine a processor's system going offline in the middle of a formation. This is an illustrative test case from the RSM reference implementation specification. The easiest thing for software to do is record what it can no longer see as nothing: processor capacity, zero. The specification calls that incorrect and makes the alternative mandatory. Authoritative capacity: unavailable. A cached value, with the time it was cached. Consequential use: not authorized.

The difference looks pedantic until you notice how often it arises. In a federated network where participants keep their own records, incomplete information is not an exception. The RSM protocol states it as an invariant: unknown is not false. If a farm has not disclosed the evidence needed to evaluate a requirement, the honest result is unauthorized or indeterminate, not unsatisfied. The federation architecture adds two siblings. Offline is not invalid, and unavailable is not false, so a network failure must never be read as negative evidence. Wellzai's exploration design applies the same discipline to search. An empty result means Wellzai does not currently know of a candidate, not that none exists, and the design keeps "no known candidate", "unknown", "not queryable" and "actually unsatisfied" as four different answers.

The implication is that absence has to be carried as a state, with its reason attached, all the way through reasoning. Exploration can continue on clearly marked cached information. A commitment cannot rest on it.

What remains open is the surface. These distinctions are easy to keep in a data model and hard to keep in front of a person. A screen that shows four kinds of "nothing" risks confusing everyone; a screen that shows one risks misleading them. How should an interface show the difference between "no", "not yet known" and "not ours to see"?