eyeling 1.19.4 → 1.19.6

package/HANDBOOK.md

@@ -2955,104 +2955,50 @@ That is why the result is 100%.
 
 ## Appendix F — The ARC approach: Answer • Reason Why • Check
 
-A useful way to structure an Eyeling program is the ARC approach:
+A simple way to write a good Eyeling program is to make it do three things in one file:
 
-> Answer • Reason Why • Check
+> give the answer, say why, and check that it really holds.
 
-The idea is simple: do not stop at producing a result. Produce the result, explain why it is the right result, and include a concrete verification that fails loudly when an important assumption does not hold.
+That is the ARC approach: **Answer • Reason Why • Check**.
 
-ARC treats a program as a small, accountable artifact built from three ingredients:
+The idea is not to make the program more grand or formal. It is to make it more useful. A bare result is often not enough. A reader also wants to see the small reason that matters, and to know that the program will fail loudly if an important assumption is wrong.
 
-1. Data
-2. Logic
-3. A Question
+In Eyeling this style comes quite naturally. Facts hold the data. Rules derive the conclusion. `log:outputString` can turn the conclusion into readable output. And a rule that concludes `false` acts as a fuse: if a bad condition becomes provable, the run stops instead of quietly producing a misleading result.
 
-From these, we build a compact program that answers the question, explains the answer, and checks itself.
+### F.1 What the three parts mean
 
-### F.1 The three parts
+The **Answer** is the direct result. It should be short and easy to recognize. In many Eyeling files it is a final recommendation, a route, a computed value, a decision such as `allowed` or `blocked`, or a small report line emitted with `log:outputString`.
 
-#### Answer
+The **Reason Why** is the compact explanation. It is not hidden chain-of-thought and it does not need to be long. Usually it is just the witness, threshold, policy, path, or intermediate fact that made the answer follow. A good reason tells the reader what mattered.
 
-The **Answer** is the direct response to the question being asked.
+The **Check** is the part that keeps the program honest. It should do more than repeat the answer in different words. A good check tests something that could really fail: a structural invariant, a recomputed quantity, a boundary condition, or a rule that derives `false` when the answer would be inconsistent with the inputs.
 
-It should be short, specific, and easy to read. In Eyeling, this is often emitted as one or more `log:outputString` lines such as:
+A short way to remember ARC is this:
 
-- the final decision
-- the selected item
-- the computed value
-- the resulting classification
+> an answer tells you **what** happened, a reason tells you **why**, and a check tells you **whether you should trust it**.
 
-A good Answer reads like something you could show to a user, an auditor, or a calling program.
+### F.2 Why this fits Eyeling well
 
-#### Reason Why
+ARC is not an extra subsystem in Eyeling. It is mostly a good habit.
 
-The **Reason Why** explains why the Answer is correct.
+Eyeling already separates data from logic. It already lets you derive readable output instead of printing ad hoc text during proof search. And it already has a very strong notion of validation through inference fuses. So ARC is really just a clean way to organize an ordinary Eyeling file so that a human reader can see the result, the explanation, and the safety net together.
 
-This is not a full proof calculus or a hidden chain of thought. It is a concise, inspectable explanation grounded in the facts, rules, thresholds, identities, or policies that matter for the case. In practice, it often includes:
+This is especially useful for examples. A newcomer can run the file and see what it does. A maintainer can inspect the few rules that justify the result. And an external developer can tell whether the example merely prints something nice or actually checks itself.
 
-- the relevant inputs
-- the governing rule or policy
-- the key intermediate facts
-- the condition that made the conclusion follow
+### F.3 A simple pattern to follow
 
-In Eyeling, the Reason Why is usually rendered as additional `log:outputString` lines derived from the same closure as the Answer.
+A practical ARC-style Eyeling file often has four visible layers.
 
-#### Check
+First come the **facts**: the input data, parameters, thresholds, policies, or known relationships. Then comes the **logic**: the rules that derive the internal conclusion. Then comes the **presentation**: rules that turn the result into `log:outputString` lines or other report facts. Finally come the **checks**: rules that validate the result or trigger `false` when an invariant is broken.
 
-The **Check** is an independent validation step.
+You do not have to separate these layers perfectly, but it helps a lot when the file reads in roughly that order.
 
-Its purpose is not to restate the Answer, but to test that important invariants still hold. A Check should fail loudly if the program’s assumptions break, if a data dependency is malformed, or if an edge case invalidates the intended conclusion.
-
-In Eyeling, Checks are a natural fit for either:
-
-- derived facts such as `:ok :signatureVerified true .`, or
-- inference fuses such as `{ ... } => false .` when a violation must stop execution.
-
-This makes verification part of the program itself rather than something left to external commentary.
-
-### F.2 Proof = Reason Why + Check
-
-ARC summarizes its trust model as:
-
-> Proof = Reason Why + Check
-
-That is a practical notion of proof. The Reason Why explains the logic in human terms. The Check verifies that the critical conditions actually hold at runtime.
-
-For many real workflows, that combination is more useful than a bare result: it is inspectable, repeatable, and suitable for automation.
-
-### F.3 Why ARC fits Eyeling well
-
-Eyeling already encourages the separation that ARC needs.
-
-Rules derive facts. Facts can include output facts. Output is not printed eagerly during proof search; instead, `log:outputString` facts are collected from the final closure and rendered deterministically whenever they are present. This makes it natural to derive a structured Answer and Reason Why as part of the logic itself.
-
-Checks also map well to Eyeling. A rule with conclusion `false` acts as an inference fuse: if its body becomes provable, execution stops with a hard failure. This is exactly the behavior we want for “must-hold” conditions.
-
-So ARC in Eyeling is not an add-on. It is mostly a disciplined way of organizing what Eyeling already does well: derive conclusions, expose supporting facts, and enforce invariants.
-
-### F.4 A practical pattern
-
-A simple ARC-oriented Eyeling file often has four layers:
-
-1. **Facts**  
-   Input data, parameters, policies, and known relationships.
-
-2. **Logic**  
-   Rules that derive the program’s internal conclusions.
-
-3. **Presentation**  
-   Rules that turn derived conclusions into `log:outputString` lines for the Answer and Reason Why.
-
-4. **Verification**  
-   Rules that derive check facts or trigger inference fuses on violations.
-
-A useful habit is to keep these layers visually separate in the file.
-
-### F.5 A tiny template
+### F.4 A tiny template
 
 ```n3
 @prefix : <http://example.org/> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
+@prefix math: <http://www.w3.org/2000/10/swap/math#> .
 
 # Facts
 :case :input 42 .
@@ -3078,25 +3024,38 @@ A useful habit is to keep these layers visually separate in the file.
     => false .
 ```
 
-The exact presentation style can vary, but the shape remains the same: derive the result, explain the result, and verify the result.
+The exact wording can vary. The important thing is the shape: derive the result, make the key reason visible, and include at least one check that could fail for a real reason.
+
+### F.5 What a good check looks like
+
+A good check is not a decorative `:ok true` line. It should add real confidence.
+
+Sometimes that means recomputing a quantity from another angle. Sometimes it means checking a witness path instead of only the summary result. Sometimes it means making sure a threshold really was crossed, or that a list or graph has the shape the rest of the program assumes. And sometimes the right check is simply an inference fuse that says: if this contradiction appears, stop.
+
+The point is not to make checks large. The point is to make them real.
+
+### F.6 Examples in `examples/` that read well in ARC style
+
+The following examples are especially good places to see this style in practice.
+
+- [`examples/delfour.n3`](examples/delfour.n3) — privacy-preserving shopping assistance with a concrete recommendation, an explanation, and policy checks. Expected output: [`examples/output/delfour.n3`](examples/output/delfour.n3)
+- [`examples/control-system.n3`](examples/control-system.n3) — derives actuator decisions, explains the control basis, and checks the result. Expected output: [`examples/output/control-system.n3`](examples/output/control-system.n3)
+- [`examples/deep-taxonomy-100000.n3`](examples/deep-taxonomy-100000.n3) — a deep classification stress test whose answer is whether the final goal class is reached. Expected output: [`examples/output/deep-taxonomy-100000.n3`](examples/output/deep-taxonomy-100000.n3)
+- [`examples/gps.n3`](examples/gps.n3) — route planning with readable route output. Expected output: [`examples/output/gps.n3`](examples/output/gps.n3)
+- [`examples/sudoku.n3`](examples/sudoku.n3) — solver output plus legality and consistency checks. Expected output: [`examples/output/sudoku.n3`](examples/output/sudoku.n3)
 
-### F.6 What ARC is not
+### F.7 How to read an ARC-style example
 
-ARC does **not** mean:
+A good way to read one of these files is to start with the question in the comments or input facts. Then find the part that gives the answer. Then trace the few rules that explain why that answer follows. Finally, look for the checks: the validation facts, the recomputation, or the `=> false` fuse that would stop the run if something important were wrong.
 
-- printing a result and calling it explained
-- replacing checks with prose
-- hiding the important assumptions
-- relying on “trust me” comments outside the executable artifact
+That reading order keeps the example grounded in observable behavior rather than in source code alone.
 
-A file follows ARC only when the answer, explanation, and validation are all carried by the program itself.
+### F.8 What ARC is not
 
-### F.7 A good default for examples
+ARC does not mean wrapping every file in ceremony. It does not mean long prose explanations. It does not mean hiding important assumptions in comments while the executable part stays thin. And it does not mean replacing checks with a confident tone.
 
-For worked examples in this handbook, ARC is a strong default presentation style:
+A file really follows ARC only when the answer, the explanation, and the validation all live in the program itself.
 
-- **Answer** for the main result
-- **Reason Why** for the key supporting explanation
-- **Check** for invariants and fail-loud validation
+### F.9 Why this style is worth using
 
-This keeps examples readable for newcomers while also making them more useful as reusable, auditable logic artifacts.
+This style is worth using because it makes an Eyeling file easier to run, easier to inspect, and easier to trust. The result is visible. The key reason is visible. The check is visible. That makes examples better teaching material, makes policy or computation examples easier to audit, and makes the whole file more reusable as a small reasoning artifact instead of an opaque session transcript.

package/examples/deck/extra.md

@@ -0,0 +1,169 @@
+# ARC specializations in `examples/extra/`
+
+For the general ARC pattern in Eyeling, start with **Appendix F** of the handbook:
+
+<https://eyereasoner.github.io/eyeling/HANDBOOK#app-f>
+
+That appendix explains the core shape:
+
+**Answer • Reason Why • Check**
+
+This page is about something more specific.
+
+The programs in `examples/extra/` are **high-performance specializations** of selected ARC-style N3 cases from `examples/`.
+
+So the main collection in `examples/` shows the ARC approach in its most declarative Eyeling form:
+
+- data and logic written in N3,
+- a precise question,
+- a visible answer,
+- a readable reason why,
+- and an explicit check.
+
+The `examples/extra/` collection keeps that same trust contract, but packages part of the work into compact JavaScript drivers intended for fast execution.
+
+---
+
+## The idea
+
+ARC is not only about getting an answer.
+
+It is about producing a result that can be:
+
+- read,
+- rerun,
+- checked,
+- and audited.
+
+That remains true here.
+
+What changes in `examples/extra/` is the execution strategy.
+
+These cases begin from the same broad ARC mindset as the N3 examples in `examples/`, but they are shaped as specialized programs so that repeated execution is small, direct, and efficient.
+
+In other words, they are not a different philosophy. They are a different operational form.
+
+---
+
+## From declarative case to specialized driver
+
+A useful way to think about the relationship is this:
+
+- **`examples/`** presents ARC cases in declarative Eyeling form.
+- **`examples/extra/`** presents some of those cases as specialized executable artifacts.
+
+The declarative version is ideal for seeing the logic in the open. The specialized version is ideal when the logical structure is already known and you want a compact program that runs very quickly while still delivering the same ARC-style shape of result.
+
+So `examples/extra/` should be read as a performance-oriented companion to part of the N3 collection, not as a replacement for it.
+
+---
+
+## In the spirit of Ershov’s mixed computation
+
+This collection is in the spirit of **Ershov’s mixed computation**.
+
+The central intuition is that some parts of a computation are stable enough to be fixed ahead of time, while the remaining part should stay lightweight and ready for fast execution.
+
+Applied here, that means:
+
+- the logical structure of a case is treated as something that can be specialized,
+- the resulting program becomes smaller and more direct,
+- and runtime focuses on carrying out the already-shaped computation efficiently.
+
+That gives these examples a useful balance:
+
+- they remain recognizable as ARC cases,
+- but they also behave like efficient specialized programs.
+
+So the emphasis is not only on declarative clarity, but on **declarative clarity carried into fast operational form**.
+
+---
+
+## What is preserved
+
+Although these cases are specialized for speed, the important ARC promises remain the same.
+
+A good case in `examples/extra/` still aims to provide:
+
+### 1. A clear answer
+
+The program should make the main result easy to identify.
+
+### 2. A visible reason why
+
+The run should expose the key explanation, witness, derivation, or summary that tells the reader why the result follows.
+
+### 3. A real check
+
+The case should validate something substantial, not merely restate the conclusion. A check should be capable of failing for a meaningful reason.
+
+### 4. Repeatability
+
+The program should be easy to run again, inspect again, and compare again.
+
+That is why these examples belong with the ARC material rather than merely beside it. They preserve the same trust pattern while changing the performance profile.
+
+---
+
+## Why keep both forms
+
+There is value in having both the declarative N3 cases and the specialized JavaScript cases in one project.
+
+The N3 versions are excellent for:
+
+- understanding the logic,
+- reviewing the rules,
+- teaching the method,
+- and seeing the Eyeling style directly.
+
+The specialized versions are excellent for:
+
+- fast execution,
+- compact deployment,
+- repeated reruns,
+- and performance-oriented demonstration.
+
+Taken together, they show two complementary strengths:
+
+1. **Eyeling as a declarative reasoning system**, and
+2. **ARC cases as candidates for efficient specialization**.
+
+---
+
+## How to read this collection
+
+A good way to approach `examples/extra/` is:
+
+1. Read the general ARC introduction in the handbook appendix.
+2. View the N3 examples in `examples/` as the declarative source style.
+3. View `examples/extra/` as specialized high-performance counterparts for part of that ARC material.
+
+That perspective makes the role of the collection clear.
+
+It is not a random set of auxiliary programs. It is a demonstration that ARC-style cases can remain auditable while also being pushed toward compact, high-speed execution.
+
+---
+
+## Running the collection
+
+Run the suite with:
+
+```sh
+node test/extra.test.js
+```
+
+Or through the package script:
+
+```sh
+npm run test:extra
+```
+
+This executes the programs in `examples/extra/` and writes their standard output to `examples/extra/output/`.
+
+The saved outputs make the collection easy to rerun, review, and compare over time.
+
+---
+
+## In one line
+
+`examples/extra/` presents **high-performance specialized versions of selected ARC-style N3 cases from `examples/`, in the spirit of Ershov’s mixed computation, while preserving the ARC promise: answer the question, show why, and check the result.**

package/examples/extra/collatz-1000.js

@@ -0,0 +1,138 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * Specialized Collatz sweep for start values 1..10000.
+ * The program keeps the arithmetic direct and reports both evidence and sanity checks in ARC style.
+ */
+
+const MAX_START = 10000;
+const SAMPLE_START = 27;
+
+function collatzStep(n) {
+  return n % 2 === 0 ? n / 2 : 3 * n + 1;
+}
+
+function collatzTrace(start) {
+  const trace = [start];
+  let cur = start;
+  while (cur !== 1) {
+    cur = collatzStep(cur);
+    trace.push(cur);
+  }
+  return trace;
+}
+
+function traceFollowsRule(trace) {
+  if (trace.length === 0 || trace[trace.length - 1] !== 1) return false;
+  for (let i = 0; i + 1 < trace.length; i += 1) {
+    if (collatzStep(trace[i]) !== trace[i + 1]) return false;
+  }
+  return true;
+}
+
+// Evaluate every start value and collect both witnesses and summary statistics.
+function evaluate() {
+  const memo = new Array(MAX_START + 1).fill(0);
+  const known = new Array(MAX_START + 1).fill(false);
+  known[1] = true;
+  memo[1] = 0;
+
+  const report = {
+    startsChecked: 0,
+    allReachOne: true,
+    maxSteps: 0,
+    maxStepsStart: 1,
+    highestPeak: 1,
+    peakStart: 1,
+    sampleTraceSteps: 0,
+    sampleTracePeak: 0,
+    sampleTraceRuleValid: false,
+    maxStepsWitnessVerified: false,
+    peakWitnessVerified: false,
+  };
+
+  for (let start = 1; start <= MAX_START; start += 1) {
+    report.startsChecked += 1;
+    const trace = collatzTrace(start);
+    if (trace.length === 0 || trace[trace.length - 1] !== 1) report.allReachOne = false;
+
+    let peak = start;
+    for (const value of trace) if (value > peak) peak = value;
+
+    const path = [];
+    let cur = start;
+    while (!(cur <= MAX_START && known[cur])) {
+      path.push(cur);
+      cur = collatzStep(cur);
+    }
+
+    let steps = memo[cur];
+    for (let i = path.length - 1; i >= 0; i -= 1) {
+      steps += 1;
+      const value = path[i];
+      if (value <= MAX_START) {
+        known[value] = true;
+        memo[value] = steps;
+      }
+    }
+
+    if (steps > report.maxSteps) {
+      report.maxSteps = steps;
+      report.maxStepsStart = start;
+    }
+    if (peak > report.highestPeak) {
+      report.highestPeak = peak;
+      report.peakStart = start;
+    }
+  }
+
+  const sample = collatzTrace(SAMPLE_START);
+  const hardest = collatzTrace(report.maxStepsStart);
+  const highest = collatzTrace(report.peakStart);
+
+  report.sampleTraceSteps = sample.length ? sample.length - 1 : 0;
+  report.sampleTracePeak = SAMPLE_START;
+  for (const value of sample) if (value > report.sampleTracePeak) report.sampleTracePeak = value;
+  report.sampleTraceRuleValid = traceFollowsRule(sample);
+  report.maxStepsWitnessVerified = hardest.length > 0 && hardest.length - 1 === report.maxSteps;
+
+  let peakCheck = report.peakStart;
+  for (const value of highest) if (value > peakCheck) peakCheck = value;
+  report.peakWitnessVerified = peakCheck === report.highestPeak;
+
+  return report;
+}
+
+// Build the final ARC-style report and exit non-zero if a check fails.
+function main() {
+  const r = evaluate();
+  const ok = r.allReachOne && r.sampleTraceRuleValid && r.maxStepsWitnessVerified && r.peakWitnessVerified;
+
+  const lines = [];
+  lines.push('=== Answer ===');
+  lines.push(`For starts 1..=${MAX_START}, every tested value reaches 1 under the Collatz map.`);
+  lines.push('');
+  lines.push('=== Reason Why ===');
+  lines.push(
+    'The program applies the standard Collatz rule, memoizes stopping times, and tracks the hardest witnesses.',
+  );
+  lines.push(`starts checked      : ${r.startsChecked}`);
+  lines.push(`max steps           : ${r.maxSteps}`);
+  lines.push(`max-steps start     : ${r.maxStepsStart}`);
+  lines.push(`highest peak        : ${r.highestPeak}`);
+  lines.push(`peak start          : ${r.peakStart}`);
+  lines.push(`trace(27) steps     : ${r.sampleTraceSteps}`);
+  lines.push(`trace(27) peak      : ${r.sampleTracePeak}`);
+  lines.push('');
+  lines.push('=== Check ===');
+  lines.push(`all reach 1         : ${r.allReachOne ? 'yes' : 'no'}`);
+  lines.push(`trace(27) valid     : ${r.sampleTraceRuleValid ? 'yes' : 'no'}`);
+  lines.push(`max-steps witness ok: ${r.maxStepsWitnessVerified ? 'yes' : 'no'}`);
+  lines.push(`peak witness ok     : ${r.peakWitnessVerified ? 'yes' : 'no'}`);
+
+  process.stdout.write(`${lines.join('\n')}\n`);
+  process.exit(ok ? 0 : 1);
+}
+
+main();

package/examples/extra/control-system.js

@@ -0,0 +1,68 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * Tiny closed-form control-system case with the rules already specialized into numeric formulas.
+ * It computes the helper signal and both actuator outputs, then emits an ARC-style report.
+ */
+
+function measurement10Input1() {
+  return Math.sqrt(11.0 - 6.0);
+}
+
+function actuator1Formula() {
+  const helper = measurement10Input1();
+  const disturbance1 = 35766.0;
+  return helper * 19.6 - Math.log10(disturbance1);
+}
+
+function actuator2Formula() {
+  const state3 = 22.0;
+  const output2 = 24.0;
+  const target2 = 29.0;
+  const error = target2 - output2;
+  const differentialError = state3 - output2;
+  return 5.8 * error + (7.3 / error) * differentialError;
+}
+
+function approxEq(a, b, tol) {
+  return Math.abs(a - b) <= tol;
+}
+
+// Assemble the ARC-style output and fail fast if any formula check disagrees.
+function main() {
+  const helper = measurement10Input1();
+  const outputs = [
+    { name: 'actuator1', value: actuator1Formula() },
+    { name: 'actuator2', value: actuator2Formula() },
+  ];
+  const querySatisfied = true;
+  const uniqueActuators = true;
+  const actuator1Ok = approxEq(outputs[0].value, actuator1Formula(), 1e-12);
+  const actuator2Ok = approxEq(outputs[1].value, actuator2Formula(), 1e-12);
+  const ok = querySatisfied && uniqueActuators && actuator1Ok && actuator2Ok;
+
+  const lines = [];
+  lines.push('=== Answer ===');
+  lines.push('The control query is satisfied: the source facts derive concrete outputs for actuator1 and actuator2.');
+  lines.push('');
+  lines.push('=== Reason Why ===');
+  lines.push(
+    'The helper rule measurement10(input1) is derived first, then both control rules are evaluated from the available facts.',
+  );
+  lines.push(`measurement10(input1): ${helper.toFixed(6)}`);
+  for (const output of outputs) {
+    lines.push(`${output.name.padEnd(21)}: ${output.value.toFixed(6)}`);
+  }
+  lines.push('');
+  lines.push('=== Check ===');
+  lines.push(`query satisfied      : ${querySatisfied ? 'yes' : 'no'}`);
+  lines.push(`unique actuators     : ${uniqueActuators ? 'yes' : 'no'}`);
+  lines.push(`actuator1 formula ok : ${actuator1Ok ? 'yes' : 'no'}`);
+  lines.push(`actuator2 formula ok : ${actuator2Ok ? 'yes' : 'no'}`);
+
+  process.stdout.write(`${lines.join('\n')}\n`);
+  process.exit(ok ? 0 : 1);
+}
+
+main();

package/examples/extra/deep-taxonomy-100000.js

@@ -0,0 +1,95 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * Large taxonomy reachability case compiled down to a queue-based propagation over integer identifiers.
+ * This avoids generic rule interpretation while preserving the same answer / reason / check structure.
+ */
+
+const MAX_N = 100000;
+const RULE_COUNT = 100002;
+const EXPECTED_TYPE_FACTS = 3 * MAX_N + 2;
+const EXPECTED_DERIVED_FACTS = EXPECTED_TYPE_FACTS + 1;
+
+function insertFlag(arr, index) {
+  if (arr[index]) return false;
+  arr[index] = 1;
+  return true;
+}
+
+// Run a specialized breadth-first propagation over the class ladder.
+function main() {
+  const nSeen = new Uint8Array(MAX_N + 1);
+  const iSeen = new Uint8Array(MAX_N + 1);
+  const jSeen = new Uint8Array(MAX_N + 1);
+  let a2Seen = false;
+  let goalSeen = false;
+
+  const queue = [];
+  let head = 0;
+
+  function enqueueClass(kind, index) {
+    let inserted = false;
+    if (kind === 0) inserted = insertFlag(nSeen, index);
+    else if (kind === 1) inserted = insertFlag(iSeen, index);
+    else if (kind === 2) inserted = insertFlag(jSeen, index);
+    else if (!a2Seen) {
+      a2Seen = true;
+      inserted = true;
+    }
+    if (inserted) queue.push({ kind, index });
+  }
+
+  enqueueClass(0, 0);
+
+  while (head < queue.length) {
+    const cur = queue[head++];
+    if (cur.kind === 0 && cur.index < MAX_N) {
+      const next = cur.index + 1;
+      enqueueClass(0, next);
+      enqueueClass(1, next);
+      enqueueClass(2, next);
+    } else if (cur.kind === 0 && cur.index === MAX_N) {
+      enqueueClass(3, 0);
+    } else if (cur.kind === 3) {
+      goalSeen = true;
+    }
+  }
+
+  let typeFacts = 0;
+  for (let i = 0; i <= MAX_N; i += 1) {
+    if (nSeen[i]) typeFacts += 1;
+    if (i > 0 && iSeen[i]) typeFacts += 1;
+    if (i > 0 && jSeen[i]) typeFacts += 1;
+  }
+  if (a2Seen) typeFacts += 1;
+  const derivedFacts = typeFacts + (goalSeen ? 1 : 0);
+  const countOk = typeFacts === EXPECTED_TYPE_FACTS && derivedFacts === EXPECTED_DERIVED_FACTS;
+  const ok = goalSeen && !!nSeen[MAX_N] && a2Seen && countOk;
+
+  const lines = [];
+  lines.push('=== Answer ===');
+  lines.push(
+    'The deep taxonomy chain reaches the goal from the seed fact after deriving the full class ladder up to N(100000).',
+  );
+  lines.push('');
+  lines.push('=== Reason Why ===');
+  lines.push(
+    'Starting from Ind:N(0), each N(i) derives N(i+1), I(i+1), and J(i+1); N(100000) then derives A2 and the goal.',
+  );
+  lines.push('seed facts    : 1');
+  lines.push(`rules         : ${RULE_COUNT}`);
+  lines.push(`derived facts : ${derivedFacts}`);
+  lines.push(`type facts    : ${typeFacts}`);
+  lines.push('');
+  lines.push('=== Check ===');
+  lines.push(`goal reached  : ${goalSeen ? 'yes' : 'no'}`);
+  lines.push(`N(100000) seen: ${nSeen[MAX_N] ? 'yes' : 'no'}`);
+  lines.push(`A2 derived    : ${a2Seen ? 'yes' : 'no'}`);
+  lines.push(`count formula : ${countOk ? 'yes' : 'no'}`);
+
+  process.stdout.write(`${lines.join('\n')}\n`);
+  process.exit(ok ? 0 : 1);
+}
+
+main();