Why there are four answers, not two

A programmer is used to a condition having two outcomes. A lawyer is used to three: yes, no, and “it depends.” Law DSL answers the question “is this claim established” with one of four statuses, and that is the first thing both stumble over. This article explains what the author’s work would lose if there were two statuses, and why the third and fourth are not a luxury but a condition of an honest answer.

One predicate, four inputs

Two people keep a researcher’s archive accreditation. A registrar enters a record. An ethics commission may revoke it. Ask the machine whether Ivanova is accredited, under four different states of the case.

What is known about the case	Answer	What it means
there is a registrar’s record	TRUE_ONLY	support is present, no objection
there is only the commission’s revocation	FALSE_ONLY	the claim is refuted: the commission said “no”
there are both records	BOTH	two supports contradict, and nobody resolved them
there are no records	NEITHER	nothing is established; this is a report of incompleteness, not “no”

Each row is a scene from the tutorial on the four statuses, which the engine executes on every repository check: see tutorial 02.

The two lower rows are the reason for four statuses. A system with two outcomes would have been obliged to collapse the third row to one side: by record time, by the organ’s rank, by the order of lines in the file. And it would not have said that it collapsed. The fourth row it would have been obliged to read as “no,” and Ivanova, about whom the archive simply knows nothing, would have received the same answer as Ivanova whom the commission stripped of accreditation.

For a lawyer the distinction is obvious: FALSE_ONLY means “go after the revocation,” NEITHER means “bring the documents.” For a programmer it is familiar too: null is not false, and anyone who mixed them remembers the cost. Here that difference is not an agreement inside one program but part of the language contract, and it cannot be switched off.

What of the four reaches a conclusion

Now ask not about accreditation but about admission itself to the rare-holdings room. The rule is simple: on the register and accredited, hence admitted. Every rule has two parts — conditions and a conclusion. In the tutorials and in compiler messages they are called, as in logic programming, the body and the head of the rule; here we will say “conditions” and “conclusion.” We keep the register established and vary only accreditation.

Accreditation	Admission
TRUE_ONLY	TRUE_ONLY
FALSE_ONLY	NEITHER
BOTH	NEITHER
NEITHER	NEITHER

Three rows out of four yield silence, each for its own reason. The second row is the least familiar to a programmer, and it deserves its own paragraph.

A false premise does not imply a false conclusion. Accreditation is refuted, and admission is not refuted: it is not established. A rule can do exactly one thing — draw its conclusion when its conditions are established. About the case where the conditions are false, it says nothing. In a program an else branch would have supplied “not admitted” on its own. In law a refusal is a separate norm that prohibits, and if it is not in the act, there is no refusal, only the absence of permission. To get FALSE_ONLY on admission, the author writes a refusal norm explicitly, and then it is visible where it came from.

This is the same property that is called the absence of contraposition: from “accredited, hence admitted” the language does not derive “not admitted, hence not accredited” and does not derive “not accredited, hence not admitted.” Both reverse steps are sometimes true in law, sometimes not, and neither follows from the text of the norm by itself. An author who needs the reverse step writes it as a separate rule, and it becomes visible, disputable, and checkable.

A contradictory premise does not count as established. Third row: accreditation is in status BOTH, and the rule does not fire. A norm does not build a conclusion on a contradictory input and does not pick a side for the lawyer. One side of a conflict can be taken, but deliberately and by a separate record, not by the rule “somehow firing.”

What this gives the author

Four statuses are not about the machine but about what remains with the author after the answer. Each of them says what to do next, and says something different.

• TRUE_ONLY: there is a ground, one may act.
• FALSE_ONLY: there is a norm or a fact that refuses; they can be produced and contested.
• BOTH: there is a conflict in the case or in the act, and it is not resolved; it must be resolved explicitly, by a priority with a named ground or by clarifying the facts.
• NEITHER: a premise is missing, and the answer names which. Sometimes that means “bring a document,” sometimes “the norm is not formalized,” sometimes “the package did not resolve the dispute.” One status does not by itself prescribe a legal action: a reason is attached, and that is what must be read.

A program with two outcomes can express all of this too. It will need its own statuses, its own discipline of not mixing them, and its own checks that the discipline is kept in every place. Here all of that is already part of the language: four statuses wherever a claim receives support, and the same reading of those statuses in two independent implementations.

What the four statuses do not do

They describe the support of a claim, and only that. A duty is not a claim: it has its own statuses, “active,” “satisfied,” “violated,” and there is a separate article about them. A deadline is not a claim: it has a date. The four statuses do not replace every kind of answer, and confusing FALSE_ONLY on a fact with “violated” on a duty is a mistake the language will not let through, but will not correct for the author.

Next

The next article is about why an exception to a rule does not reduce to else, and how defeat of a ground differs from an established opposite. How everything shown here is written — the tutorial on the four statuses and the tutorial on negation.