eyeling 1.12.5 → 1.12.6

package/HANDBOOK.md

@@ -26,8 +26,9 @@
 - [Chapter 16 — Extending Eyeling (without breaking it)](#ch16)
 - [Epilogue](#epilogue)
 - [Appendix A — Eyeling user notes](#app-a)
-- [Appendix B — Notation 3: when facts can carry their own logic](#app-b)
+- [Appendix B — Notation3: when facts can carry their own logic](#app-b)
 - [Appendix C — N3 beyond Prolog: logic that survives the open web](#app-c)
+- [Appendix D — LLM + Eyeling: A Repeatable Logic Toolchain](#app-d)
 
 ---
 
@@ -113,7 +114,7 @@ If you want to follow the code in the same order Eyeling “thinks”, read:
 1. `lib/prelude.js` — the AST (terms, triples, rules), namespaces, prefix handling.
 2. `lib/lexer.js` — N3/Turtle-ish tokenization.
 3. `lib/parser.js` — parsing tokens into triples, formulas, and rules.
-4. `lib/rules.js` — small rule “compiler passes” (blank lifting, constraint delaying).
+4. `lib/rules.js` — small rule helpers (rule-local blank lifting and rule utilities).
 5. `lib/engine.js` — the core inference engine:
    - equality + alpha equivalence for formulas
    - unification + substitutions
@@ -281,7 +282,7 @@ Internally:
 
 ## Chapter 5 — Rule normalization: “compile-time” semantics (`lib/rules.js`)
 
-Before rules hit the engine, Eyeling performs two lightweight transformations.
+Before rules hit the engine, Eyeling performs one lightweight transformation. A second “make it work” trick—deferring built-ins that can’t run yet—happens later inside the goal prover.
 
 ### 5.1 Lifting blank nodes in rule bodies into variables
 
@@ -303,19 +304,28 @@ This avoids the “existential in the body” trap and matches how most rule aut
 
 Blanks in the **conclusion** are _not_ lifted — they remain blanks and later become existentials (Chapter 9).
 
-### 5.2 Delaying constraints
+### 5.2 Builtin deferral in forward-rule bodies
 
-Some built-ins don’t generate bindings; they only test conditions:
+In a depth-first proof, the order of goals matters. Many built-ins only become informative once parts of the triple are **already instantiated** (for example comparisons, pattern tests, and other built-ins that don’t normally create bindings).
 
-- `math:greaterThan`, `math:lessThan`, `math:equalTo`, …
-- `string:matches`, `string:contains`, …
-- `log:notIncludes`, `log:forAllIn`, `log:outputString`, …
+If such a builtin runs while its subject/object still contain variables or blanks, it may return **no solutions** (because it can’t decide yet) or only the **empty delta** (`{}`), even though it would succeed (or fail) once other goals have bound the needed values.
 
-Eyeling treats these as “constraints” and moves them to the _end_ of a forward rule premise. This is a Prolog-style heuristic:
+Eyeling supports a runtime deferral mechanism inside `proveGoals(...)`, enabled only when proving the bodies of forward rules.
 
-> Bind variables first; only then run pure checks.
+What happens when `proveGoals(..., { deferBuiltins: true })` sees a builtin goal:
 
-It’s not logically necessary, but it improves the chance that constraints run with variables already grounded, reducing wasted search.
+- Eyeling evaluates the builtin once.
+- If the builtin yields **no deltas**, or only **empty deltas** (`[{}]`), and:
+  - there are still other goals remaining, and
+  - the builtin goal still contains variables/blanks, and
+  - the goal list hasn’t already been rotated too many times,
+- then Eyeling **rotates that builtin goal to the end** of the current goal list and continues with the next goal first.
+
+A small counter (`deferCount`) caps how many rotations can happen (at most the length of the current goal list), so the prover can’t loop forever by endlessly “trying later”.
+
+There is one extra guard for a small whitelist of built-ins that are considered satisfiable even when both subject and object are completely unbound (see `__builtinIsSatisfiableWhenFullyUnbound`). For these, if evaluation yields no deltas and there is nothing left to bind (either it is the last goal, or deferral has already been exhausted), Eyeling treats the builtin as a vacuous success (`[{}]`) so it doesn’t block the proof.
+
+This is intentionally enabled for **forward-chaining rule bodies only**. Backward rules keep their normal left-to-right goal order, which can be important for termination on some programs.
 
 ### 5.3 Materializing anonymous RDF collections into N3 list terms
 
@@ -640,7 +650,7 @@ A rule whose conclusion is `false` is treated as a hard failure. During forward
 - Eyeling proves the premise (it only needs one solution)
 - if the premise is provable, it prints a message and exits with status code 2
 
-This is Eyeling’s way to express constraints and detect inconsistencies.
+This is Eyeling’s way to express hard consistency checks and detect inconsistencies.
 
 ### 9.5 Rule-producing rules (meta-rules)
 
@@ -776,7 +786,6 @@ That one sentence explains a lot of “why does it behave like _that_?”:
 - Builtins are evaluated **during backward proof** (goal solving), just like facts and backward rules.
 - A builtin may produce **zero solutions** (fail), **one solution** (deterministic succeed), or **many solutions** (a generator).
 - Most builtins behave like relations, not like functions: they can sometimes run “backwards” (bind the subject from the object) if the implementation supports it.
-- Some builtins are **pure tests** (constraints): they never introduce new bindings; they only succeed or fail. Eyeling recognizes a subset of these and tends to schedule them _late_ in forward-rule premises so they run after other goals have had a chance to bind variables.
 
 ### 11.3.0 Reading builtin “signatures” in this handbook
 
@@ -825,13 +834,13 @@ These builtins hash a string and return a lowercase hex digest as a plain string
 
 Eyeling’s `math:` builtins fall into three broad categories:
 
-1. **Comparisons**: constraint-style predicates (`>`, `<`, `=`, …).
+1. **Comparisons**: test-style predicates (`>`, `<`, `=`, …).
 2. **Arithmetic on numbers**: sums, products, division, rounding, etc.
 3. **Unary analytic functions**: trig/hyperbolic functions and a few helpers.
 
 A key design choice: Eyeling parses numeric terms fairly strictly, but comparisons accept a wider “numeric-like” domain including durations and date/time values in some cases.
 
-### 11.3.2.1 Numeric comparisons (constraints)
+### 11.3.2.1 Numeric comparisons
 
 These builtins succeed or fail; they do not introduce new bindings.
 
@@ -1158,9 +1167,9 @@ It does not enumerate arbitrary reversals; it’s a deterministic transform once
 
 Removes all occurrences of an item from a list.
 
-Important constraint: the item to remove must be **ground** (fully known) before the builtin will run.
+Important requirement: the item to remove must be **ground** (fully known) before the builtin will run.
 
-#### `list:notMember` (constraint)
+#### `list:notMember` (test)
 
 **Shape:** `(a b c) list:notMember x`
 
@@ -1225,7 +1234,7 @@ The `log:` family is where N3 stops being “RDF with rules” and becomes a _me
 
 This is simply **term unification**: it succeeds if the two terms can be unified and returns any bindings that result.
 
-#### `log:notEqualTo` (constraint)
+#### `log:notEqualTo` (test)
 
 Succeeds iff the terms **cannot** be unified. No new bindings.
 
@@ -1362,7 +1371,7 @@ Also supported:
 
 - The object may be the literal `true`, meaning the empty formula, which is always included (subject to the priority gating above).
 
-#### `log:notIncludes` (constraint)
+#### `log:notIncludes` (test)
 
 Negation-as-failure version: it succeeds iff `log:includes` would yield no solutions (under the same scoping rules).
 
@@ -1377,7 +1386,7 @@ Negation-as-failure version: it succeeds iff `log:includes` would yield no solut
 
 This is essentially a list-producing “findall”.
 
-#### `log:forAllIn` (constraint)
+#### `log:forAllIn` (test)
 
 **Shape:** `( WhereFormula ThenFormula ) log:forAllIn Scope`
 
@@ -1455,7 +1464,7 @@ A tiny `sprintf` subset:
 - Any other specifier (`%d`, `%f`, …) causes the builtin to fail.
 - Missing arguments are treated as empty strings.
 
-### Containment and prefix/suffix tests (constraints)
+### Containment and prefix/suffix tests
 
 - `string:contains`
 - `string:containsIgnoringCase`
@@ -1464,12 +1473,12 @@ A tiny `sprintf` subset:
 
 All are pure tests: they succeed or fail.
 
-### Case-insensitive equality tests (constraints)
+### Case-insensitive equality tests
 
 - `string:equalIgnoringCase`
 - `string:notEqualIgnoringCase`
 
-### Lexicographic comparisons (constraints)
+### Lexicographic comparisons
 
 - `string:greaterThan`
 - `string:lessThan`
@@ -1485,7 +1494,7 @@ Eyeling compiles patterns using JavaScript `RegExp`, with a small compatibility
 - If the pattern uses Unicode property escapes (like `\p{L}`) or code point escapes (`\u{...}`), Eyeling enables the `/u` flag.
 - In Unicode mode, some “identity escapes” that would be SyntaxErrors in JS are sanitized in a conservative way.
 
-#### `string:matches` / `string:notMatches` (constraints)
+#### `string:matches` / `string:notMatches` (tests)
 
 **Shape:** `data string:matches pattern`
 
@@ -1512,7 +1521,7 @@ From a logic-programming point of view, printing is awkward: if you print _durin
 The predicate `log:outputString` is the only officially supported “side-effect channel”, and even it is handled in two phases:
 
 1. **During reasoning (declarative phase):**  
-   `log:outputString` behaves like a constraint-style builtin (implemented in `lib/builtins.js`): it succeeds when its arguments are well-formed and sufficiently bound (notably, when the object is a string literal that can be emitted). Importantly, it does _not_ print anything at this time. If a rule derives a triple like:
+   `log:outputString` behaves like a pure test builtin (implemented in `lib/builtins.js`): it succeeds when its arguments are well-formed and sufficiently bound (notably, when the object is a string literal that can be emitted). Importantly, it does _not_ print anything at this time. If a rule derives a triple like:
 
    ```n3
    :k log:outputString "Hello\n".
@@ -1926,13 +1935,13 @@ Logic & reasoning background (Wikipedia):
 
 <a id="app-b"></a>
 
-## Appendix B — Notation 3: when facts can carry their own logic
+## Appendix B — Notation3: when facts can carry their own logic
 
-RDF succeeded by making a radical constraint feel natural: reduce meaning to small, uniform statements—triples—that can be published, merged, and queried across boundaries. A triple does not presume a database schema, a programming language, or a particular application. It presumes only that names (IRIs) can be shared, and that graphs can be combined.
+RDF succeeded by making a radical design choice feel natural: reduce meaning to small, uniform statements—triples—that can be published, merged, and queried across boundaries. A triple does not presume a database schema, a programming language, or a particular application. It presumes only that names (IRIs) can be shared, and that graphs can be combined.
 
 That strength also marks RDF’s limit. The moment a graph is expected to _do_ something—normalize values, reconcile vocabularies, derive implied relationships, enforce a policy, compute a small transformation—logic tends to migrate into code. The graph becomes an inert substrate while the decisive semantics hide in scripts, services, ETL pipelines, or bespoke rule engines. What remains portable is the data; what often becomes non-portable is the meaning.
 
-Notation 3 (N3) sits precisely at that seam. It remains a readable way to write RDF, but it also treats _graphs themselves_ as objects that can be described, matched, and related. The N3 Community Group’s specification presents N3 as an assertion and logic language that extends RDF rather than replacing it: [https://w3c.github.io/N3/spec/](https://w3c.github.io/N3/spec/).
+Notation3 (N3) sits precisely at that seam. It remains a readable way to write RDF, but it also treats _graphs themselves_ as objects that can be described, matched, and related. The N3 Community Group’s specification presents N3 as an assertion and logic language that extends RDF rather than replacing it: [https://w3c.github.io/N3/spec/](https://w3c.github.io/N3/spec/).
 
 The essential move is quotation: writing a graph inside braces as a thing that can be discussed. Once graphs can be quoted, rules become graph-to-graph transformations. The familiar implication form, `{ … } => { … } .`, reads as a piece of prose: whenever the antecedent pattern holds, the consequent pattern follows. Tim Berners-Lee’s design note frames this as a web-friendly logic with variables and nested graphs: [https://www.w3.org/DesignIssues/Notation3.html](https://www.w3.org/DesignIssues/Notation3.html).
 
@@ -1946,25 +1955,115 @@ In that context, public conformance suites become more than scoreboards: they ar
 
 The comparison with older tools is historically instructive. Cwm (Closed World Machine) was an early, influential RDF data processor and forward-chaining reasoner—part of the lineage that treated RDF (often written in N3) as something executable: [https://www.w3.org/2000/10/swap/doc/cwm](https://www.w3.org/2000/10/swap/doc/cwm).
 
-What motivates Notation 3, in the end, is architectural restraint. It refuses to let “logic” become merely a private feature of an application stack. It keeps meaning close to the graph: rules are expressed as graph patterns; results are expressed as triples; computation is pulled in through well-defined built-ins rather than arbitrary code. This produces a style of working where integration and inference are not sidecar scripts, but publishable artifacts—documents that can be inspected, shared, tested, and reused.
+What motivates Notation3, in the end, is architectural restraint. It refuses to let “logic” become merely a private feature of an application stack. It keeps meaning close to the graph: rules are expressed as graph patterns; results are expressed as triples; computation is pulled in through well-defined built-ins rather than arbitrary code. This produces a style of working where integration and inference are not sidecar scripts, but publishable artifacts—documents that can be inspected, shared, tested, and reused.
 
 In that sense, N3 is less a bid to make the web “smarter” than a bid to make meaning _portable_: not only facts that travel, but also the explicit steps by which facts can be connected, extended, and made actionable—without abandoning the simplicity that made triples travel in the first place.
 
----  
+---
+
+<a id="app-c"></a>
 
 ## Appendix C — N3 beyond Prolog: logic that survives the open web
 
 At first glance, an N3 rule set can feel familiar if you’ve used Prolog: variables, unification, and rules that read like “if this pattern holds, then that pattern follows.” But N3 is not just “logic programming with a different syntax.” It is logic shaped for a different environment: not a single program with a single database, but a world of distributed graphs that can be published, merged, and cited across boundaries.
 
-That change of environment forces a change in what “beyond Prolog” even means. It is less about being more powerful in the abstract, and more about being *more portable as meaning* — logic that stays connected when it moves between documents, vocabularies, and authors.
+That change of environment forces a change in what “beyond Prolog” even means. It is less about being more powerful in the abstract, and more about being _more portable as meaning_ — logic that stays connected when it moves between documents, vocabularies, and authors.
 
 Several design moves push N3 into that web-native space:
 
 - **Global identity is the default.** Names are IRIs. A rule does not merely compute with local symbols; it operates over identifiers meant to be shared across datasets.
 - **Graphs are the unit of exchange.** The input is a graph; the output is a graph. Inference produces new triples rather than hidden internal state, so results can travel the same way the facts do.
-- **Statements can be treated as data.** Quoted graphs let you talk *about* assertions: claims, policies, provenance, “this source says …,” “this formula implies …,” and other meta-level structure that is awkward in a plain predicate database.
+- **Statements can be treated as data.** Quoted graphs let you talk _about_ assertions: claims, policies, provenance, “this source says …,” “this formula implies …,” and other meta-level structure that is awkward in a plain predicate database.
 - **Rules can be publishable artifacts.** Rules can live alongside data as text, be versioned, reviewed, and reused — the “meaning” is not forced back into an external codebase.
 - **Web-like computation can be pulled into rule bodies.** Built-ins make room for the small computations that real integration needs (strings, lists, comparisons), and some N3 workflows even treat IRIs as pointers to more knowledge.
 
-In that sense, Prolog is a superb engine for proving things *inside* a chosen world. N3 is a way to write rules so they keep working *across* worlds: across documents, across graph boundaries, and across the open-ended growth of linked data. When an engine like Eyeling solves rule bodies with a Prolog-like prover but still saturates forward consequences, it’s exactly this bridge: Prolog-style execution serving a web-scale, graph-first notion of meaning.
+In that sense, Prolog is a superb engine for proving things _inside_ a chosen world. N3 is a way to write rules so they keep working _across_ worlds: across documents, across graph boundaries, and across the open-ended growth of linked data. When an engine like Eyeling solves rule bodies with a Prolog-like prover but still saturates forward consequences, it’s exactly this bridge: Prolog-style execution serving a web-scale, graph-first notion of meaning.
+
+---
+
+<a id="app-d"></a>
+
+## Appendix D — LLM + Eyeling: A Repeatable Logic Toolchain
+
+Eyeling is a deterministic N3 engine: given facts and rules, it derives consequences to a fixpoint using forward rules proved by a backward engine. That makes it a good “meaning boundary” for LLM-assisted workflows: the LLM can draft and refactor N3, but **Eyeling is what decides what follows**.
+
+A practical pattern is to treat the LLM as a **syntax-and-structure generator** and Eyeling as the **semantic validator**.
+
+### 1) Constrain the LLM to output compilable N3
+
+If the LLM is allowed to emit prose or “almost N3”, you’ll spend your time cleaning up. Instead, require:
+
+- **Only N3** (no explanations in the artifact).
+- A fixed prefix set (or a required `@base`).
+- One artifact per file (facts + rules), optionally with a separate test file.
+- “No invention” rules for IRIs: new symbols must be declared or use a designated namespace.
+
+This is less about prompt craft and more about creating a stable interface between a text generator and a compiler-like consumer.
+
+### 2) Use Eyeling as the compile check and the semantic check
+
+Run Eyeling immediately after generation:
+
+- **Parse failures** → feed the error back to the LLM and request a corrected N3 file (same vocabulary, minimal diff).
+- **Runtime failures / fuses** → treat as a spec violation, not “the model being creative”.
+
+Eyeling explicitly supports **inference fuses**: a forward rule with head `false` is a hard failure. This is extremely useful as a guardrail when you want “never allow X” constraints to stop the run.
+
+Example fuse:
+
+```n3
+@prefix : <http://example/> .
+
+{ ?u :role :Admin.
+  ?u :disabled true.
+} => false.
+```
+
+If you don’t want “stop the world”, derive a `:Violation` fact instead, and keep going.
+
+### 3) Make the workflow test-driven (golden closures)
+
+The most robust way to keep LLM-generated logic plausible is to make it live under tests:
+
+- Keep tiny **fixtures** (facts) alongside the rules.
+- Run Eyeling to produce the **derived closure** (Eyeling can emit only newly derived forward facts, and can optionally include compact proof comments).
+- Compare against an expected output (“golden file”) in CI.
+
+This turns rule edits into a normal change-management loop: diffs are explicit, reviewable, and reproducible.
+
+### 4) Use proofs/traces as the input to the LLM, not the other way around
+
+If you want a natural-language explanation, don’t ask the model to “explain the rules from memory”. Instead:
+
+1. Run Eyeling with proof/trace enabled (Eyeling has explicit tracing hooks and proof-comment support in its output pipeline).
+2. Give the LLM the **derived triples + proof comments** and ask it to summarize:
+   - what was derived,
+   - which rule(s) fired,
+   - which premises mattered.
+
+This keeps explanations anchored to what Eyeling actually derived.
+
+### 5) The refinement loop: edits are N3 diffs, not “better prompting”
+
+When output looks wrong, the fix should be a change in the artifact:
+
+- tighten a premise,
+- split one rule into two,
+- add an exception rule,
+- introduce a new predicate to separate concepts,
+- add a fuse or a `:Violation` derivation,
+- add a test case that locks in the intended behavior.
+
+Then regenerate/rewrite **only the N3**, rerun Eyeling, and review the diff.
+
+### A prompt shape that tends to behave well
+
+A simple structure that keeps the LLM honest:
+
+- “Output **only** N3.”
+- “Use exactly these prefixes.”
+- “Do not introduce new IRIs outside `<base>#*`.”
+- “Include at least N minimal tests as facts in a separate block/file.”
+- “If something is unknown, emit a placeholder fact (`:needsFact`) rather than guessing.”
 
+The point isn’t that the LLM is “right”; it’s that **Eyeling makes the result checkable**, and the artifact becomes a maintainable program rather than a one-off generation.

package/examples/bayes-diagnosis.n3

@@ -0,0 +1,143 @@
+# =================================================================================
+# Bayes Diagnosis
+#
+# This N3 program encodes a small Bayesian diagnostic model and computes posteriors
+# using Eyeling’s deterministic inference + builtins (lists + arithmetic).
+#
+# NOTE: Probability values here are illustrative only and not medical advice.
+# =================================================================================
+
+@prefix :     <https://example.org/diag#> .
+@prefix math: <http://www.w3.org/2000/10/swap/math#> .
+@prefix list: <http://www.w3.org/2000/10/swap/list#> .
+
+# -------------------------------------------
+# 1) MODEL (a simple BN: Disease -> Symptoms)
+# -------------------------------------------
+
+:COVID19            a :Disease; :prior 0.05 .
+:Influenza          a :Disease; :prior 0.03 .
+:AllergicRhinitis   a :Disease; :prior 0.10 .
+:BacterialPneumonia a :Disease; :prior 0.01 .
+
+# Conditional probabilities P(symptom | disease)
+# Stored as:  :Disease :pGiven [ :symptom :S ; :p 0.xx ] .
+
+:COVID19 :pGiven [ :symptom :Fever;        :p 0.70 ] .
+:COVID19 :pGiven [ :symptom :DryCough;     :p 0.65 ] .
+:COVID19 :pGiven [ :symptom :LossOfSmell;  :p 0.40 ] .
+:COVID19 :pGiven [ :symptom :Sneezing;     :p 0.15 ] .
+:COVID19 :pGiven [ :symptom :ShortBreath;  :p 0.20 ] .
+
+:Influenza :pGiven [ :symptom :Fever;        :p 0.80 ] .
+:Influenza :pGiven [ :symptom :DryCough;     :p 0.50 ] .
+:Influenza :pGiven [ :symptom :LossOfSmell;  :p 0.05 ] .
+:Influenza :pGiven [ :symptom :Sneezing;     :p 0.20 ] .
+:Influenza :pGiven [ :symptom :ShortBreath;  :p 0.10 ] .
+
+:AllergicRhinitis :pGiven [ :symptom :Fever;        :p 0.05 ] .
+:AllergicRhinitis :pGiven [ :symptom :DryCough;     :p 0.15 ] .
+:AllergicRhinitis :pGiven [ :symptom :LossOfSmell;  :p 0.10 ] .
+:AllergicRhinitis :pGiven [ :symptom :Sneezing;     :p 0.80 ] .
+:AllergicRhinitis :pGiven [ :symptom :ShortBreath;  :p 0.05 ] .
+
+:BacterialPneumonia :pGiven [ :symptom :Fever;        :p 0.70 ] .
+:BacterialPneumonia :pGiven [ :symptom :DryCough;     :p 0.60 ] .
+:BacterialPneumonia :pGiven [ :symptom :LossOfSmell;  :p 0.02 ] .
+:BacterialPneumonia :pGiven [ :symptom :Sneezing;     :p 0.05 ] .
+:BacterialPneumonia :pGiven [ :symptom :ShortBreath;  :p 0.60 ] .
+
+# ----------------------------------------------
+# 2) CASE (symptom evidence: present true/false)
+# ----------------------------------------------
+
+:Case a :PatientCase;
+  :diseases ( :COVID19 :Influenza :AllergicRhinitis :BacterialPneumonia );
+  :evidence (
+    [ :symptom :Fever;       :present true  ]
+    [ :symptom :DryCough;    :present true  ]
+    [ :symptom :LossOfSmell; :present true  ]
+    [ :symptom :Sneezing;    :present false ]
+    [ :symptom :ShortBreath; :present true  ]
+  ).
+
+# -------------------------------------------------------------
+# 3) GUARDS (inference fuses) — fail hard if probs out of [0,1]
+# -------------------------------------------------------------
+
+{ ?d :prior ?p. ?p math:lessThan 0. }     => false.
+{ ?d :prior ?p. ?p math:greaterThan 1. }  => false.
+
+{ ?d :pGiven [ :p ?p ]. ?p math:lessThan 0. }     => false.
+{ ?d :pGiven [ :p ?p ]. ?p math:greaterThan 1. }  => false.
+
+# ----------
+# 4) HELPERS
+# ----------
+
+# pairList(d, (x1 x2 ...)) -> ((d x1) (d x2) ...)
+{ ( ?d () ) :pairList () } <= true.
+
+{ ( ?d ?xs ) :pairList ?pairs } <= {
+  ?xs list:firstRest ( ?x ?rest ).
+  ( ?d ?rest ) :pairList ?tailPairs.
+  ?pairs list:firstRest ( ( ?d ?x ) ?tailPairs ).
+}.
+
+# factor for one evidence item:
+#   if present  -> P(symptom | disease)
+#   if absent   -> 1 - P(symptom | disease)
+{ ( ?d ?ev ) :factor ?p } <= {
+  ?ev :symptom ?s.
+  ?ev :present true.
+  ?d :pGiven [ :symptom ?s; :p ?p ].
+}.
+
+{ ( ?d ?ev ) :factor ?q } <= {
+  ?ev :symptom ?s.
+  ?ev :present false.
+  ?d :pGiven [ :symptom ?s; :p ?p ].
+  ( 1 ?p ) math:difference ?q.
+}.
+
+# unnormalized score(d) = prior(d) * Π_e factor(d,e)
+{ ?d :scoreFor ?score } <= {
+  ?d :prior ?prior.
+  :Case :evidence ?evs.
+  ( ?d ?evs ) :pairList ?pairs.
+  ( ?pairs :factor ) list:map ?factors.
+  ?factors math:product ?likelihood.
+  ( ?prior ?likelihood ) math:product ?score.
+}.
+
+# --------------------------------------------------------
+# 5) POSTERIOR: normalize across diseases in the case list
+# --------------------------------------------------------
+
+# Compute the score list and total once.
+{
+  :Case :diseases ?ds.
+  ( ?ds :scoreFor ) list:map ?scores.
+  ?scores math:sum ?total.
+} => {
+  :Case :scores ?scores;
+        :evidenceTotal ?total.
+}.
+
+# Emit one result node per disease: posterior = score / total
+{
+  :Case :diseases ?ds.
+  :Case :scores ?scores.
+  :Case :evidenceTotal ?total.
+
+  ?ds list:iterate ( ?i ?d ).
+  ( ?scores ?i ) list:memberAt ?score.
+  ( ?score ?total ) math:quotient ?post.
+} => {
+  :Case :result [
+    :disease ?d;
+    :unnormalized ?score;
+    :posterior ?post
+  ].
+}.
+

package/examples/fuse.n3

@@ -2,6 +2,8 @@
 # Inference fuse
 # ==============
 
+# expect-exit: 2
+
 @prefix : <https://eyereasoner.github.io/ns#>.
 
 :stone :color :black.

package/examples/liar.n3

@@ -3,6 +3,8 @@
 # Example from Patrick Hochstenbach
 # =================================
 
+# expect-exit: 2
+
 @prefix : <https://eyereasoner.github.io/ns#>.
 @prefix log: <http://www.w3.org/2000/10/swap/log#>.
 

package/examples/output/bayes-diagnosis.n3

@@ -0,0 +1,21 @@
+@prefix : <https://example.org/diag#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+:Case :scores ("0.0015470000000000002"^^xsd:decimal "0.000048000000000000015"^^xsd:decimal "7.499999999999999e-7"^^xsd:decimal "0.000047879999999999996"^^xsd:decimal) .
+:Case :evidenceTotal "0.0016436300000000003"^^xsd:decimal .
+:Case :result _:sk_0 .
+_:sk_0 :disease :COVID19 .
+_:sk_0 :unnormalized "0.0015470000000000002"^^xsd:decimal .
+_:sk_0 :posterior "0.9412093962753174"^^xsd:decimal .
+:Case :result _:sk_1 .
+_:sk_1 :disease :Influenza .
+_:sk_1 :unnormalized "0.000048000000000000015"^^xsd:decimal .
+_:sk_1 :posterior "0.029203652890249024"^^xsd:decimal .
+:Case :result _:sk_2 .
+_:sk_2 :disease :AllergicRhinitis .
+_:sk_2 :unnormalized "7.499999999999999e-7"^^xsd:decimal .
+_:sk_2 :posterior "0.00045630707641014084"^^xsd:decimal .
+:Case :result _:sk_3 .
+_:sk_3 :disease :BacterialPneumonia .
+_:sk_3 :unnormalized "0.000047879999999999996"^^xsd:decimal .
+_:sk_3 :posterior "0.029130643758023392"^^xsd:decimal .

package/examples/output/cobalt-kepler-kitchen.n3

@@ -6,37 +6,37 @@ _:b1 :apoapsis "7006.999999999999"^^xsd:decimal .
 _:b1 :period "5828.516637686015"^^xsd:decimal .
 _:b1 :specificEnergy "-28.471460128571426"^^xsd:decimal .
 _:b1 :angularMomentum "52822.34661955968"^^xsd:decimal .
+_:b1 :stateAtM _:sk_0 .
 _:sk_0 :M 1.0 .
 _:sk_0 :E "1.0008419256335213"^^xsd:decimal .
 _:sk_0 :nu "-2.2873045281884816"^^xsd:decimal .
 _:sk_0 :r "6996.222844390736"^^xsd:decimal .
 _:sk_0 :x "-4594.807855276618"^^xsd:decimal .
 _:sk_0 :y "-5275.87669126782"^^xsd:decimal .
-_:b1 :stateAtM _:sk_0 .
 _:b2 :periapsis "26294.4"^^xsd:decimal .
 _:b2 :apoapsis "26825.6"^^xsd:decimal .
 _:b2 :period "43077.75744086394"^^xsd:decimal .
 _:b2 :specificEnergy "-7.503773377259035"^^xsd:decimal .
 _:b2 :angularMomentum "102887.16660222781"^^xsd:decimal .
+_:b2 :stateAtM _:sk_1 .
 _:sk_1 :M 0.3 .
 _:sk_1 :E "0.3029834341902831"^^xsd:decimal .
 _:sk_1 :nu "0.6416326023742479"^^xsd:decimal .
 _:sk_1 :r "26306.497927630408"^^xsd:decimal .
 _:sk_1 :x "21074.653903376588"^^xsd:decimal .
 _:sk_1 :y "15744.54813798468"^^xsd:decimal .
-_:b2 :stateAtM _:sk_1 .
 _:b3 :periapsis "42159.7836"^^xsd:decimal .
 _:b3 :apoapsis "42168.2164"^^xsd:decimal .
 _:b3 :period "86163.57055057827"^^xsd:decimal .
 _:b3 :specificEnergy "-4.7267863793757705"^^xsd:decimal .
 _:b3 :angularMomentum "129640.22855575853"^^xsd:decimal .
+_:b3 :stateAtM _:sk_2 .
 _:sk_2 :M 2.0 .
 _:sk_2 :E "2.00009092595867"^^xsd:decimal .
 _:sk_2 :nu "2.0000000098093915"^^xsd:decimal .
 _:sk_2 :r "42165.754990121"^^xsd:decimal .
 _:sk_2 :x "-17547.1459258647"^^xsd:decimal .
 _:sk_2 :y "38341.21234055235"^^xsd:decimal .
-_:b3 :stateAtM _:sk_2 .
 :Transfer1 :transferSemiMajorAxis "24582"^^xsd:decimal .
 :Transfer1 :v1 "7.546053290107541"^^xsd:decimal .
 :Transfer1 :v2 "3.074666284127684"^^xsd:decimal .

package/examples/output/cranberry-calculus.n3

@@ -2,21 +2,21 @@
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
 
 :VecA :dotWithVecB "12"^^xsd:decimal .
+:VecA :angleToVecB _:sk_0 .
 _:sk_0 :radians "0.9272952180016123"^^xsd:decimal .
 _:sk_0 :degrees "53.13010235415598"^^xsd:decimal .
-:VecA :angleToVecB _:sk_0 .
 :Shot1 :vx "21.213203435596427"^^xsd:decimal .
 :Shot1 :vy "21.213203435596423"^^xsd:decimal .
 :Shot1 :timeOfFlight "4.324812117348913"^^xsd:decimal .
 :Shot1 :range "91.74311926605502"^^xsd:decimal .
 :Shot1 :maxHeight "22.935779816513755"^^xsd:decimal .
+:Shot1 :positionAtSample _:sk_1 .
 _:sk_1 :t 2.5 .
 _:sk_1 :x "53.033008588991066"^^xsd:decimal .
 _:sk_1 :y "22.37675858899106"^^xsd:decimal .
-:Shot1 :positionAtSample _:sk_1 .
 :DataSet1 :mean "2.642857142857143"^^xsd:decimal .
 :DataSet1 :variance "9.083163265306123"^^xsd:decimal .
 :DataSet1 :stddev "3.0138286721886036"^^xsd:decimal .
+:DataSet1 :outlier _:sk_2 .
 _:sk_2 :value 10.0 .
 _:sk_2 :zScore "2.44112843076783"^^xsd:decimal .
-:DataSet1 :outlier _:sk_2 .

package/examples/output/jade-eigen-loom.n3

@@ -16,45 +16,45 @@
 :PCA1 :_b "-10.193877551020407"^^xsd:decimal .
 :PCA1 :thetaRad "-0.5758598575998168"^^xsd:decimal .
 :PCA1 :thetaDeg "-32.99433943147409"^^xsd:decimal .
+:PCA1 :score _:sk_0 .
 _:sk_0 :point _:b1 .
 _:sk_0 :u "-2.226965310551135"^^xsd:decimal .
 _:sk_0 :v "-5.227147834641157"^^xsd:decimal .
 _:sk_0 :md2 "1.813452314350555"^^xsd:decimal .
-:PCA1 :score _:sk_0 .
+:PCA1 :score _:sk_1 .
 _:sk_1 :point _:b2 .
 _:sk_1 :u "-1.9327971142113742"^^xsd:decimal .
 _:sk_1 :v "-3.843867287441055"^^xsd:decimal .
 _:sk_1 :md2 "1.007995131390371"^^xsd:decimal .
-:PCA1 :score _:sk_1 .
+:PCA1 :score _:sk_2 .
 _:sk_2 :point _:b3 .
 _:sk_2 :u "-1.7475401529576473"^^xsd:decimal .
 _:sk_2 :v "-2.292841865886967"^^xsd:decimal .
 _:sk_2 :md2 "0.4034041082672275"^^xsd:decimal .
-:PCA1 :score _:sk_2 .
+:PCA1 :score _:sk_3 .
 _:sk_3 :point _:b4 .
 _:sk_3 :u "-1.9434725145050398"^^xsd:decimal .
 _:sk_3 :v "-0.15470938409392798"^^xsd:decimal .
 _:sk_3 :md2 "0.09948798150629935"^^xsd:decimal .
-:PCA1 :score _:sk_3 .
+:PCA1 :score _:sk_4 .
 _:sk_4 :point _:b5 .
 _:sk_4 :u "-2.6295054339395856"^^xsd:decimal .
 _:sk_4 :v "2.73827503229205"^^xsd:decimal .
 _:sk_4 :md2 "0.6417615664115196"^^xsd:decimal .
-:PCA1 :score _:sk_4 .
+:PCA1 :score _:sk_5 .
 _:sk_5 :point _:b6 .
 _:sk_5 :u "-4.5680175568635235"^^xsd:decimal .
 _:sk_5 :v "7.56032550374887"^^xsd:decimal .
 _:sk_5 :md2 "4.065911517796796"^^xsd:decimal .
-:PCA1 :score _:sk_5 .
+:PCA1 :score _:sk_6 .
 _:sk_6 :point _:b7 .
 _:sk_6 :u "15.048298083028305"^^xsd:decimal .
 _:sk_6 :v "1.219965836022185"^^xsd:decimal .
 _:sk_6 :md2 "5.967987380277233"^^xsd:decimal .
-:PCA1 :score _:sk_6 .
 :PCA1 :sigma1 "6.207810973771468"^^xsd:decimal .
 :PCA1 :sigma2 "4.0271300936862655"^^xsd:decimal .
+:PCA1 :ellipse95 _:sk_7 .
 _:sk_7 :k "2.4476519360399265"^^xsd:decimal .
 _:sk_7 :a "15.194560548521636"^^xsd:decimal .
 _:sk_7 :b "9.857012770495839"^^xsd:decimal .
 _:sk_7 :area "470.52568540824956"^^xsd:decimal .
-:PCA1 :ellipse95 _:sk_7 .

package/examples/output/ruby-runge-workshop.n3

@@ -9,8 +9,8 @@
 :Interp1 :derivativeAtX0 "2.3999999999999853"^^xsd:decimal .
 :Interp1 :yAtBracketA "-1"^^xsd:decimal .
 :Interp1 :yAtBracketB "1"^^xsd:decimal .
+:Interp1 :rootBracket _:sk_0 .
 _:sk_0 :a 0.0 .
 _:sk_0 :b 1.0 .
 _:sk_0 :ya "-1"^^xsd:decimal .
 _:sk_0 :yb "1"^^xsd:decimal .
-:Interp1 :rootBracket _:sk_0 .

package/examples/output/saffron-slopeworks.n3

@@ -13,12 +13,12 @@
 :Reg1 :rSquared "0.7193278283366806"^^xsd:decimal .
 :Reg1 :sse "32.33904761904761"^^xsd:decimal .
 :Reg1 :rmse "2.010567321026817"^^xsd:decimal .
+:Reg1 :highResidual _:sk_0 .
 _:sk_0 :point _:b8 .
 _:sk_0 :x 8.0 .
 _:sk_0 :y 15.0 .
 _:sk_0 :yhat "10.666666666666666"^^xsd:decimal .
 _:sk_0 :residual "4.333333333333334"^^xsd:decimal .
-:Reg1 :highResidual _:sk_0 .
+:Reg1 :prediction _:sk_1 .
 _:sk_1 :x 8.5 .
 _:sk_1 :y "11.369047619047619"^^xsd:decimal .
-:Reg1 :prediction _:sk_1 .