Four truth values for service status: why a 402 is both up and down

Four truth values for service status: why a 402 is both up and down

A service estate should be read in four values, not two: told true (it answered), told false (no answer), told both (it answered and refused) and told neither (we have no reading yet). The 561 Group's estate probe applies Nuel Belnap's four-valued logic so that a node answering HTTP 402 Payment Required is reported as "both" instead of being forced into "up" or "down". The rest of this article explains the logic, the probe and the reasoning.

What is Belnap's four-valued logic?

In 1977 Nuel Belnap published "A Useful Four-Valued Logic" for a computer that must reason from what it is told by sources that may disagree or may say nothing (Belnap 1977)¹¹ Nuel D. Belnap. "A Useful Four-Valued Logic." In Modern Uses of Multiple-Valued Logic, ed. J. Michael Dunn and George Epstein, 5-37, Reidel, 1977.. Instead of true and false only, a told proposition can be told true, told false, told both or told neither. The two extra values are not exotic. They are the ordinary situations of a system fed by multiple sources: two witnesses contradict each other, or nobody has spoken.

A logic where a contradiction does not entail everything is called paraconsistent. That property is what lets a monitoring system keep conflicting records side by side rather than overwrite one with the other or fall over. The 561 Group's design sentence calls its monitoring "paraconsistent" for exactly this reason: conflicting records are kept, not collapsed.

How does the estate probe tell each answer?

The 561 Group's public site contains an estate reading. It is not a status page that somebody updates by hand. When its cached reading is stale, a Worker issues a GET to every node listed in the estate data, concurrently. Each GET does not follow redirects and times out after four seconds. The reading is cached for 300 seconds, and the page colors each tile from it. The probes go through the public front door, as a visitor's request would, so one *.561.group host is observed the way another visitor would observe it.

The build refuses to list more than 45 nodes, because every probe counts against the Worker's subrequest budget. Nodes that are broken, behind a login or infrastructure are left out of the public list, and each node's public pages are read for personal names, handles and private paths before listing. Authority is held by offices; no person is named on the site.

Why is 402 the textbook case?

HTTP 402 Payment Required is how a paid machine interface says "I exist, I understand you, and I will not serve you until you pay." A binary monitor has two bad choices. Call it up, and the customer without a wallet gets nothing from a service the dashboard calls healthy. Call it down, and the operator pages someone at 3 a.m. over a working paywall.

Four values give the honest report: answered, and refused. The same applies to 401 and 403, where credentials rather than money are the missing thing. For an economy where agents buy from agents, this matters: a catalog that returns 402 is a functioning storefront with a locked door, and the monitoring of storefronts should say so.

What does "neither" add?

"Neither" is the value for no reading yet. It prevents two common lies: showing a green light for a node nobody has checked, and showing a red one for the same. It also lets a system distinguish a failed probe from a failed node. If the monitor cannot reach a server, it has learned something about the observation, not about the server.

Why use this logic and not a score?

Because a scalar score hides which disagreement it summarizes. The Group has a rule against flattening complex disagreements between offices to one priority number; it prefers a framework that preserves provenance so the decision can be re-derived. The four values are the smallest structure that retains the difference between "no one said" and "someone said no", and between "two sources agree" and "two sources conflict".

The Group's homepage design statement goes further and describes the values as "transfinitely valued": truth values indexed by ordinals, so evidence can keep refining past every finite stage of observation. That is design intent. The deployed probe uses the four finite values, and we do not claim an implementation of the transfinite version.

How does this fit the rest of operations?

Four-valued reading is the Monitor stage of the loop in how to run a company as a MAPE-K loop. Its output feeds the analysis in the receiving ladder, which locates the first rung that cannot be demonstrated. And it is one case of a wider habit in the Group's records: refusal is a first-class typed outcome. A refusal is not an error to be hidden; it is an answer with a type.

How can you apply it in your own estate?

1. List each endpoint as a node with a canonical URL.
2. Probe from outside, without following redirects on the first reading, with a short timeout.
3. Map your response classes to four values deliberately; write the mapping down.
4. Cache for a stated interval, and show the interval to readers.
5. Give "neither" a visible state so unmeasured nodes are not green.
6. Exclude nodes you do not intend to be public, and read each included node's public pages for private information first.

Is this implemented?

The estate probe and its mapping are described by the public site's own repository documentation as the running design of that site. The Group's public homepage presents the four values on its face, and states plainly that whether any part of the design is running is a dated, separate question. Other estate-wide uses of the four values remain design intent.

Where to go next

The 561 Group's estate reading · The receiving ladder · MAPE-K, defined · Lenticule Science for the logic · Market for payment-gated catalog interfaces