Most software is comfortable with yes and no. Legal and administrative decisions are not always that simple. A rule may be satisfied, it may be contradicted, or the available facts may be insufficient to decide. Treating the third condition as “false” creates a system that looks decisive while concealing uncertainty.
This is why a legal or public-decision engine should be able to return three results: TRUE, FALSE, and UNKNOWN. The third value is not indecision. It is an explicit statement about evidence.
False and unknown answer different questions
FALSE means the system has enough information to determine that a requirement is not satisfied. UNKNOWN means the system cannot yet determine whether the requirement is satisfied. The fact may be missing, disputed, inaccessible, or supported by evidence that still needs review.
Consider a permit rule requiring proof that a property meets a particular condition. If the submitted document shows the condition is not met, the result may be false. If the relevant document was never submitted, the result should be unknown. Converting both situations into the same rejection hides what the applicant—and the reviewer—needs to do next.
The design principle: uncertainty should appear in the result, not disappear inside the software.
Three-valued logic creates a useful workflow
An unknown result can connect a decision directly to the evidence required to resolve it. Instead of returning a vague error or an unjustified denial, the system can identify the unresolved rule, the missing fact, and the acceptable source of proof.
- TRUE: the structured facts satisfy the rule, and the supporting evidence can be traced.
- FALSE: the available facts contradict or fail the rule, with the failed condition visible.
- UNKNOWN: a determination is not yet possible, and the system exposes the missing or unresolved evidence.
This makes the result operational. An applicant knows what to provide. A reviewer knows what remains open. An auditor can see why the system stopped rather than guessing what happened inside a model.
Rules, facts, and evidence should remain separate
A trustworthy decision engine should not blur the rule itself, the facts of a case, and the evidence offered to support those facts. The rule describes what must be evaluated. Facts describe the case in a structured form. Evidence provides the basis for accepting, rejecting, or questioning those facts.
Keeping those layers separate makes change manageable. Rules can be versioned without rewriting case records. New evidence can resolve an unknown result without changing the rule. A reviewer can disagree with an evidence assessment without altering the underlying decision logic.
Where AI belongs—and where it does not
AI can help extract possible facts from documents, classify material, find relevant provisions, or explain a result in accessible language. Those are assistance tasks. They should not silently replace deterministic evaluation or decide whether uncertain evidence is true.
When a language model is allowed to generate the legal result directly, fluent output can hide missing facts and inconsistent reasoning. A better architecture keeps AI around the decision process: proposing, organizing, and explaining while explicit rules evaluate structured facts and humans review consequential evidence.
UNKNOWN is an accountability feature
Public systems often face pressure to automate more cases and produce faster outcomes. A visible unknown state may seem inefficient because it creates a queue for evidence or review. In reality, it prevents the system from claiming certainty it does not possess.
That restraint is valuable wherever decisions must be explained, challenged, or corrected. It turns uncertainty into a traceable work item and gives the organization a measurable view of where information, process, or policy is incomplete.
This architecture is central to the Digital Democracy / Digi-LAW product brief: versioned rulegraphs, structured facts, deterministic evaluation, visible reasoning traces, and human review around consequential evidence.
Explore the Digital Democracy brief
See how deterministic rules, evidence, and accountable review fit into an inspectable public-decision system.
Read the technical brief →