Decision Logic

After this lesson, the reader should understand:

• 01Construct a complete decision structure for a rule set.
• 02Test for unreachable paths and undefined outcomes.
• 03Produce a reasoning trace alongside an outcome.

The eligibility path with no 'no'

An eligibility policy defines who qualifies but never defines refusal. What does the machine do?

Nothing defensible. An incomplete decision structure produces silent defaults, and silent defaults are unlogged policy. Completeness testing surfaces the omission before deployment and forces the institution to state the refusal path explicitly — which is a policy decision the drafters never made in prose. Take a scholarship rule: 'Applicants with a grade average of 3.5 or above and household income below $60,000 are eligible.' Draw the inputs as a grid and four cells appear. High grades and low income: eligible, as written. The other three — high grades with higher income, low grades with low income, low grades with higher income — are not mentioned. Then add the cell every real system meets on day one: an applicant whose income document has not arrived. An implementation will do something in all five cells. In most codebases it does whatever the variable's default happens to be — false, so a refusal; or an unhandled null, so a crash; or, worst, a missing value that compares as zero and passes the income test. Each of those is a policy, and none was decided by anyone with authority. The strongest objection is that refusal is the obvious default, and logic has a name for it: the closed-world assumption, under which whatever cannot be shown true is treated as false^[1]. For the three mentioned-by-omission cells it is often right — the institution almost certainly meant 'otherwise, not eligible', and saying so costs one line. For the fifth cell it is wrong, and the difference matters. 'Not shown to qualify' and 'shown not to qualify' are different facts. Treating a missing document as a failed income test refuses an applicant on evidence the institution does not have. The reference runtime keeps them apart: when none of the facts provided is one the artifact actually reads, it does not deny — it escalates with a stated reason of insufficient data. The limit is combinatorial. Completeness can be checked mechanically when inputs fall into finite, declared ranges, which is why decision-table standards build it in^[2]. Over unbounded inputs, or rules that interact across many fields, exhaustive checking becomes expensive, and an artifact can be complete over the partitions it declares while still meeting a case nobody partitioned for. Completeness is a property relative to a declared input model; the input model is itself a policy choice worth reviewing.

• Is a default outcome ever acceptable?
• Should evaluation order be part of the authority or an implementation detail?
• How much of the trace should be disclosed to the subject?
• When is 'otherwise, refuse' a legitimate default, and when does it refuse someone on evidence the institution does not have?

No responses yet. Be the first to answer one of the questions above.

Draw and test a decision structure.

1. 01Map every branch from inputs to outcome.
2. 02Identify paths with no defined terminal.
3. 03Identify branches that can never be reached.
4. 04Write the trace a single case would produce.
5. 05Add a column for each input being missing, and state the outcome for every such row.