eyeling 1.11.21 → 1.11.22

package/HANDBOOK.md

@@ -2,10 +2,9 @@
 
 ## A compact Notation3 reasoner in JavaScript — a handbook
 
-> This handbook is written for a computer science student who wants to understand Eyeling as *code* and as a *reasoning machine*.  
+> This handbook is written for a computer science student who wants to understand Eyeling as _code_ and as a _reasoning machine_.  
 > It’s meant to be read linearly, but each chapter stands on its own.
 
-
 ## Contents
 
 - [Preface](#preface)
@@ -31,6 +30,7 @@
 ---
 
 <a id="preface"></a>
+
 ## Preface: what Eyeling is (and what it is not)
 
 Eyeling is a small Notation3 (N3) reasoner implemented in JavaScript. Its job is to take:
@@ -43,11 +43,12 @@ and compute consequences until nothing new follows.
 If you’ve seen Datalog or Prolog, the shape will feel familiar. Eyeling blends both:
 
 - **Forward chaining** (like Datalog saturation) for `=>` rules.
-- **Backward chaining** (like Prolog goal solving) for `<=` rules *and* for built-in predicates.
+- **Backward chaining** (like Prolog goal solving) for `<=` rules _and_ for built-in predicates.
 
-That last point is the heart of Eyeling’s design: *forward rules are executed by proving their bodies using a backward engine*. This lets forward rules depend on computations and “virtual predicates” without explicitly materializing everything as facts.
+That last point is the heart of Eyeling’s design: _forward rules are executed by proving their bodies using a backward engine_. This lets forward rules depend on computations and “virtual predicates” without explicitly materializing everything as facts.
 
 Eyeling deliberately keeps the implementation small and dependency-free:
+
 - the published package includes a single bundled file (`eyeling.js`)
 - the source is organized into `lib/*` modules that read like a miniature compiler + logic engine.
 
@@ -56,6 +57,7 @@ This handbook is a tour of that miniature system.
 ---
 
 <a id="ch01"></a>
+
 ## Chapter 1 — The execution model in one picture
 
 Let’s name the pieces:
@@ -101,6 +103,7 @@ Because `PROVE` can call built-ins (math, string, list, crypto, dereferencing…
 ---
 
 <a id="ch02"></a>
+
 ## Chapter 2 — The repository, as a guided reading path
 
 If you want to follow the code in the same order Eyeling “thinks”, read:
@@ -121,7 +124,7 @@ If you want to follow the code in the same order Eyeling “thinks”, read:
 6. `lib/builtins.js` — builtin predicate evaluation plus shared literal/number/string/list helpers:
    - `makeBuiltins(deps)` dependency-injects engine hooks (unification, proving, deref, …)
    - exports `evalBuiltin(...)` and `isBuiltinPred(...)` back to the engine
-   - includes `materializeRdfLists(...)`, a small pre-pass that rewrites *anonymous* `rdf:first`/`rdf:rest` linked lists into concrete N3 list terms so `list:*` builtins can work uniformly
+   - includes `materializeRdfLists(...)`, a small pre-pass that rewrites _anonymous_ `rdf:first`/`rdf:rest` linked lists into concrete N3 list terms so `list:*` builtins can work uniformly
 7. `lib/explain.js` — proof comments + `log:outputString` aggregation (fact ordering and pretty output).
 8. `lib/deref.js` — synchronous dereferencing for `log:content` / `log:semantics` (used by builtins and engine).
 9. `lib/printing.js` — conversion back to N3 text.
@@ -139,6 +142,7 @@ text → tokens → AST (facts + rules) → engine → derived facts → printer
 ---
 
 <a id="ch03"></a>
+
 ## Chapter 3 — The data model: terms, triples, formulas, rules (`lib/prelude.js`)
 
 Eyeling uses a small AST. You can think of it as the “instruction set” for the rest of the reasoner.
@@ -170,7 +174,7 @@ A rule is:
 Two details matter later:
 
 1. **Inference fuse**: a forward rule whose conclusion is the literal `false` acts as a hard failure. (More in Chapter 10.)
-2. **`headBlankLabels`** records which blank node labels occur *explicitly in the head* of a rule. Those blanks are treated as existentials and get skolemized per firing. (Chapter 9.)
+2. **`headBlankLabels`** records which blank node labels occur _explicitly in the head_ of a rule. Those blanks are treated as existentials and get skolemized per firing. (Chapter 9.)
 
 ### 3.3 Interning
 
@@ -182,7 +186,7 @@ Eyeling interns IRIs and Literals by string value. Interning is a quiet performa
 
 In addition, interned **Iri**/**Literal** terms (and generated **Blank** terms) get a small, non-enumerable integer id `.__tid` that is stable for the lifetime of the process. This `__tid` is used as the engine’s “fast key”:
 
-- fact indexes (`__byPred` / `__byPS` / `__byPO`) key by `__tid` values **and store fact *indices*** (predicate buckets are keyed by `predicate.__tid`, and PS/PO buckets are keyed by the subject/object `.__tid`; buckets contain integer indices into the `facts` array)
+- fact indexes (`__byPred` / `__byPS` / `__byPO`) key by `__tid` values **and store fact _indices_** (predicate buckets are keyed by `predicate.__tid`, and PS/PO buckets are keyed by the subject/object `.__tid`; buckets contain integer indices into the `facts` array)
 - duplicate detection uses `"sid	pid	oid"` where each component is a `__tid`
 - unification/equality has an early-out when two terms share the same `__tid`
 
@@ -201,6 +205,7 @@ Terms are treated as immutable: once interned/created, the code assumes you won
 ---
 
 <a id="ch04"></a>
+
 ## Chapter 4 — From characters to AST: lexing and parsing (`lib/lexer.js`, `lib/parser.js`)
 
 Eyeling’s parser is intentionally pragmatic: it aims to accept “the stuff people actually write” in N3/Turtle, including common shorthand.
@@ -265,19 +270,20 @@ true => { :Program :loaded true }.
 
 Internally:
 
-* `true` becomes “empty triple list”
-* `false` becomes “no head triples” *plus* the `isFuse` flag if forward.
+- `true` becomes “empty triple list”
+- `false` becomes “no head triples” _plus_ the `isFuse` flag if forward.
 
 ---
 
 <a id="ch05"></a>
+
 ## Chapter 5 — Rule normalization: “compile-time” semantics (`lib/rules.js`)
 
 Before rules hit the engine, Eyeling performs two lightweight transformations.
 
 ### 5.1 Lifting blank nodes in rule bodies into variables
 
-In N3 practice, blanks in *rule premises* behave like universally-quantified placeholders. Eyeling implements this by converting `Blank(label)` to `Var(_bN)` in the premise only.
+In N3 practice, blanks in _rule premises_ behave like universally-quantified placeholders. Eyeling implements this by converting `Blank(label)` to `Var(_bN)` in the premise only.
 
 So a premise like:
 
@@ -293,17 +299,17 @@ acts like:
 
 This avoids the “existential in the body” trap and matches how most rule authors expect N3 to behave.
 
-Blanks in the **conclusion** are *not* lifted — they remain blanks and later become existentials (Chapter 9).
+Blanks in the **conclusion** are _not_ lifted — they remain blanks and later become existentials (Chapter 9).
 
 ### 5.2 Delaying constraints
 
 Some built-ins don’t generate bindings; they only test conditions:
 
-* `math:greaterThan`, `math:lessThan`, `math:equalTo`, …
-* `string:matches`, `string:contains`, …
-* `log:notIncludes`, `log:forAllIn`, `log:outputString`, …
+- `math:greaterThan`, `math:lessThan`, `math:equalTo`, …
+- `string:matches`, `string:contains`, …
+- `log:notIncludes`, `log:forAllIn`, `log:outputString`, …
 
-Eyeling treats these as “constraints” and moves them to the *end* of a forward rule premise. This is a Prolog-style heuristic:
+Eyeling treats these as “constraints” and moves them to the _end_ of a forward rule premise. This is a Prolog-style heuristic:
 
 > Bind variables first; only then run pure checks.
 
@@ -320,29 +326,30 @@ _:d rdf:first :b.
 _:d rdf:rest rdf:nil.
 ```
 
-Eyeling supports *both* representations:
+Eyeling supports _both_ representations:
 
-* **Concrete N3 lists** like `(:a :b)` are parsed as `ListTerm([...])` directly.
-* **RDF collections** using `rdf:first`/`rdf:rest` can be traversed by list-aware builtins.
+- **Concrete N3 lists** like `(:a :b)` are parsed as `ListTerm([...])` directly.
+- **RDF collections** using `rdf:first`/`rdf:rest` can be traversed by list-aware builtins.
 
 To make list handling simpler and faster, Eyeling runs a small pre-pass called `materializeRdfLists(...)` (implemented in `lib/builtins.js` and invoked by the CLI/entry code). It:
 
-* scans the **input triples** for well‑formed `rdf:first`/`rdf:rest` chains,
-* **rewrites only anonymous (blank-node) list nodes** into concrete `ListTerm(...)`,
-* and applies that rewrite consistently across the input triple set and all rule premises/heads.
+- scans the **input triples** for well‑formed `rdf:first`/`rdf:rest` chains,
+- **rewrites only anonymous (blank-node) list nodes** into concrete `ListTerm(...)`,
+- and applies that rewrite consistently across the input triple set and all rule premises/heads.
 
 Why only blank nodes? Named list nodes (IRIs) must keep their identity, because some programs treat them as addressable resources; Eyeling leaves those as `rdf:first`/`rdf:rest` graphs so list builtins can still walk them when needed.
 
 ---
 
 <a id="ch06"></a>
+
 ## Chapter 6 — Equality, alpha-equivalence, and unification (`lib/engine.js`)
 
 Once you enter `engine.js`, you enter the “physics layer.” Everything else depends on the correctness of:
 
-* equality and normalization (especially for literals)
-* alpha-equivalence for formulas
-* unification and substitution application
+- equality and normalization (especially for literals)
+- alpha-equivalence for formulas
+- unification and substitution application
 
 ### 6.1 Two equalities: structural vs alpha-equivalent
 
@@ -352,18 +359,18 @@ But **quoted formulas** (`GraphTerm`) demand something stronger. Two formulas sh
 
 That’s alpha-equivalence:
 
-* `{ _:x :p ?y. }` should match `{ _:z :p ?w. }`
+- `{ _:x :p ?y. }` should match `{ _:z :p ?w. }`
 
 Eyeling implements alpha-equivalence by checking whether there exists a consistent renaming mapping between the two formulas’ variables/blanks that makes the triples match.
 
 ### 6.2 Groundness: “variables inside formulas don’t leak”
 
-Eyeling makes a deliberate choice about *groundness*:
+Eyeling makes a deliberate choice about _groundness_:
 
-* a triple is “ground” if it has no free variables in normal positions
-* **variables inside a `GraphTerm` do not make the surrounding triple non-ground**
+- a triple is “ground” if it has no free variables in normal positions
+- **variables inside a `GraphTerm` do not make the surrounding triple non-ground**
 
-This is encoded in functions like `isGroundTermInGraph`. It’s what makes it possible to assert and store triples that *mention formulas with variables* as data.
+This is encoded in functions like `isGroundTermInGraph`. It’s what makes it possible to assert and store triples that _mention formulas with variables_ as data.
 
 ### 6.3 Substitutions: chaining and application
 
@@ -375,29 +382,29 @@ A substitution is a plain JS object:
 
 When applying substitutions, Eyeling follows **chains**:
 
-* if `X → Var(Y)` and `Y → Iri(...)`, applying to `X` yields the IRI.
+- if `X → Var(Y)` and `Y → Iri(...)`, applying to `X` yields the IRI.
 
 Chains arise naturally during unification (e.g. when variables unify with other variables) and during rule firing.
 
-At the API boundary, a substitution is still just a plain object, and unification still produces *delta* objects (small `{ varName: Term }` maps).  
+At the API boundary, a substitution is still just a plain object, and unification still produces _delta_ objects (small `{ varName: Term }` maps).  
 But inside the hot backward-chaining loop (`proveGoals`), Eyeling uses a Prolog-style **trail** to avoid cloning substitutions at every step:
 
-* keep one **mutable** substitution object during DFS
-* when a candidate match yields a delta, **apply the bindings in place**
-* record newly-bound variable names on a **trail stack**
-* on backtracking, **undo** only the bindings pushed since a saved “mark”
+- keep one **mutable** substitution object during DFS
+- when a candidate match yields a delta, **apply the bindings in place**
+- record newly-bound variable names on a **trail stack**
+- on backtracking, **undo** only the bindings pushed since a saved “mark”
 
 This keeps the search semantics identical, but removes the “copy a growing object per step” cost that dominates deep/branchy proofs. Returned solutions are emitted as compact plain objects, so callers never observe mutation.
 
 Implementation details (and why they matter):
 
-* **`applySubstTerm` is the only “chain chaser”.** It follows `Var → Term` links until it reaches a stable term.
-  * Unification’s occurs-check prevents most cycles, but `applySubstTerm` still defends against accidental cyclic chains.
-  * The cycle guard is written to avoid allocating a `Set` in the common case (short chains).
-* **Structural sharing is deliberate.** Applying a substitution often changes nothing:
-  * `applySubstTerm` returns the original term when it is unaffected.
-  * list/open-list/graph terms are only rebuilt if at least one component changes (lazy copy-on-change).
-  * `applySubstTriple` returns the original `Triple` when `s/p/o` are unchanged.
+- **`applySubstTerm` is the only “chain chaser”.** It follows `Var → Term` links until it reaches a stable term.
+  - Unification’s occurs-check prevents most cycles, but `applySubstTerm` still defends against accidental cyclic chains.
+  - The cycle guard is written to avoid allocating a `Set` in the common case (short chains).
+- **Structural sharing is deliberate.** Applying a substitution often changes nothing:
+  - `applySubstTerm` returns the original term when it is unaffected.
+  - list/open-list/graph terms are only rebuilt if at least one component changes (lazy copy-on-change).
+  - `applySubstTriple` returns the original `Triple` when `s/p/o` are unchanged.
 
 These “no-op returns” are one of the biggest practical performance wins in the engine: backward chaining and forward rule instantiation apply substitutions constantly, so avoiding allocations reduces GC pressure without changing semantics.
 
@@ -405,32 +412,32 @@ These “no-op returns” are one of the biggest practical performance wins in t
 
 Unification is implemented in `unifyTerm` / `unifyTriple`, with support for:
 
-* variable binding with occurs check
-* list unification (elementwise)
-* open-list unification (prefix + tail variable)
-* formula unification via graph unification:
-
-  * fast path: identical triple list
-  * otherwise: backtracking order-insensitive matching while threading the substitution
+- variable binding with occurs check
+- list unification (elementwise)
+- open-list unification (prefix + tail variable)
+- formula unification via graph unification:
+  - fast path: identical triple list
+  - otherwise: backtracking order-insensitive matching while threading the substitution
 
 There are two key traits of Eyeling’s graph unification:
 
-1. It’s *set-like*: order doesn’t matter.
-2. It’s *substitution-threaded*: choices made while matching one triple restrict the remaining matches, just like Prolog.
+1. It’s _set-like_: order doesn’t matter.
+2. It’s _substitution-threaded_: choices made while matching one triple restrict the remaining matches, just like Prolog.
 
 ### 6.5 Literals: lexical vs semantic equality
 
 Eyeling keeps literal values as raw strings, but it parses and normalizes where needed:
 
-* `literalParts(lit)` splits lexical form and datatype IRI
-* it recognizes RDF JSON datatype (`rdf:JSON` / `<...rdf#JSON>`)
-* it includes caches for numeric parsing, integer parsing (`BigInt`), and numeric metadata.
+- `literalParts(lit)` splits lexical form and datatype IRI
+- it recognizes RDF JSON datatype (`rdf:JSON` / `<...rdf#JSON>`)
+- it includes caches for numeric parsing, integer parsing (`BigInt`), and numeric metadata.
 
 This lets built-ins and fast-key indexing treat some different lexical spellings as the same value (for example, normalizing `"abc"` and `"abc"^^xsd:string` in the fast-key path).
 
 ---
 
 <a id="ch07"></a>
+
 ## Chapter 7 — Facts as a database: indexing and fast duplicate checks
 
 Reasoning is mostly “join-like” operations: match a goal triple against known facts. Doing this naively is too slow, so Eyeling builds indexes on top of a plain array.
@@ -441,10 +448,10 @@ Facts live in an array `facts: Triple[]`.
 
 Eyeling attaches hidden (non-enumerable) index fields:
 
-* `facts.__byPred: Map<predicateId, number[]>` where each entry is an index into `facts` (and `predicateId` is `predicate.__tid`)
-* `facts.__byPS: Map<predicateId, Map<termId, number[]>>` where each entry is an index into `facts` (and `termId` is `term.__tid`)
-* `facts.__byPO: Map<predicateId, Map<termId, number[]>>` where each entry is an index into `facts` (and `termId` is `term.__tid`)
-* `facts.__keySet: Set<string>` for a fast-path `"sid	pid	oid"` key (all three are `__tid` values)
+- `facts.__byPred: Map<predicateId, number[]>` where each entry is an index into `facts` (and `predicateId` is `predicate.__tid`)
+- `facts.__byPS: Map<predicateId, Map<termId, number[]>>` where each entry is an index into `facts` (and `termId` is `term.__tid`)
+- `facts.__byPO: Map<predicateId, Map<termId, number[]>>` where each entry is an index into `facts` (and `termId` is `term.__tid`)
+- `facts.__keySet: Set<string>` for a fast-path `"sid	pid	oid"` key (all three are `__tid` values)
 
 `termFastKey(term)` returns a `termId` (`term.__tid`) for **Iri**, **Literal**, and **Blank** terms, and `null` for structured terms (lists, quoted graphs) and variables.
 
@@ -467,11 +474,12 @@ When adding derived facts, Eyeling uses a fast-path duplicate check when possibl
 - If all three terms have a fast key (Iri/Literal/Blank → `__tid`), it checks membership in `facts.__keySet` using the `"sid	pid	oid"` key.
 - Otherwise (lists, quoted graphs, variables), it falls back to structural triple equality.
 
-This still treats blanks correctly: blanks are *not* interchangeable; the blank **label** (and thus its `__tid`) is part of the key.
+This still treats blanks correctly: blanks are _not_ interchangeable; the blank **label** (and thus its `__tid`) is part of the key.
 
 ---
 
 <a id="ch08"></a>
+
 ## Chapter 8 — Backward chaining: the proof engine (`proveGoals`)
 
 Eyeling’s backward prover is an iterative depth-first search (DFS) that looks a lot like Prolog’s SLD resolution, but written explicitly with a stack to avoid JS recursion limits.
@@ -480,10 +488,10 @@ Eyeling’s backward prover is an iterative depth-first search (DFS) that looks
 
 A proof state contains:
 
-* `goals`: remaining goal triples
-* `subst`: current substitution
-* `depth`: current depth (used for compaction heuristics)
-* `visited`: previously-seen goals (loop prevention)
+- `goals`: remaining goal triples
+- `subst`: current substitution
+- `depth`: current depth (used for compaction heuristics)
+- `visited`: previously-seen goals (loop prevention)
 
 ### 8.2 The proving loop
 
@@ -491,18 +499,16 @@ At each step:
 
 1. If no goals remain: emit the current substitution as a solution.
 2. Otherwise:
-
-   * take the first goal
-   * apply the current substitution to it
-   * attempt to satisfy it in three ways:
-
+   - take the first goal
+   - apply the current substitution to it
+   - attempt to satisfy it in three ways:
      1. built-ins
      2. facts
      3. backward rules
 
 Eyeling’s order is intentional: built-ins often bind variables cheaply; rules expand search trees.
 
-### 8.3 Built-ins: return *deltas*, not full substitutions
+### 8.3 Built-ins: return _deltas_, not full substitutions
 
 A built-in is evaluated by the engine via the builtin library in `lib/builtins.js`:
 
@@ -519,17 +525,16 @@ for delta in deltas:
 
 **Implementation note (performance):** as of this version, Eyeling also avoids allocating short-lived substitution objects when matching goals against **facts** and when unifying a **backward-rule head** with the current goal. Instead of calling the pure `unifyTriple(..., subst)` (which clones the substitution on each variable bind), the prover performs an **in-place unification** directly into the mutable `substMut` store and records only the newly-bound variable names on the trail. This typically reduces GC pressure significantly on reachability / path-search workloads, where unification is executed extremely frequently.
 
-
 So built-ins behave like relations that can generate zero, one, or many possible bindings. A list generator might yield many deltas; a numeric test yields zero or one.
 
 #### 8.3.1 Builtin deferral and “vacuous” solutions
 
-Conjunction in N3 is order-insensitive, but many builtins are only useful once some variables are bound by *other* goals in the same body. When `proveGoals` is called from forward chaining, Eyeling enables **builtin deferral**: if a builtin goal can’t make progress yet, it is rotated to the end of the goal list and retried later (with a small cycle guard to avoid infinite rotation).
+Conjunction in N3 is order-insensitive, but many builtins are only useful once some variables are bound by _other_ goals in the same body. When `proveGoals` is called from forward chaining, Eyeling enables **builtin deferral**: if a builtin goal can’t make progress yet, it is rotated to the end of the goal list and retried later (with a small cycle guard to avoid infinite rotation).
 
 “Can’t make progress” includes both cases:
 
 - the builtin returns **no solutions** (`[]`), and
-- the builtin returns only **vacuous solutions** (`[{}]`, i.e., success with *no new bindings*) while the goal still contains unbound vars/blanks.
+- the builtin returns only **vacuous solutions** (`[{}]`, i.e., success with _no new bindings_) while the goal still contains unbound vars/blanks.
 
 That second case matters for “satisfiable but non-enumerating” builtins (e.g., some `log:` helpers) where early vacuous success would otherwise prevent later goals from ever binding the variables the builtin needs.
 
@@ -541,8 +546,8 @@ Eyeling prevents obvious infinite recursion by skipping a goal if it is already
 
 Backward rules are indexed in `backRules.__byHeadPred`. When proving a goal with IRI predicate `p`, Eyeling retrieves:
 
-* `rules whose head predicate is p`
-* plus `__wildHeadPred` for rules whose head predicate is not an IRI (rare, but supported)
+- `rules whose head predicate is p`
+- plus `__wildHeadPred` for rules whose head predicate is not an IRI (rare, but supported)
 
 For each candidate rule:
 
@@ -553,7 +558,7 @@ For each candidate rule:
 That “standardize apart” step is essential. Without it, reusing a rule multiple times would accidentally share variables across invocations, producing incorrect bindings.
 
 **Implementation note (performance):** `standardizeRule` is called for every backward-rule candidate during proof search.  
-To reduce allocation pressure, Eyeling reuses a single fresh `Var(...)` object per *original* variable name within one standardization pass (all occurrences of `?x` in the rule become the same fresh `?x__N` object). This is semantics-preserving — it still “separates” invocations — but it avoids creating many duplicate Var objects when a variable appears repeatedly in a rule body.
+To reduce allocation pressure, Eyeling reuses a single fresh `Var(...)` object per _original_ variable name within one standardization pass (all occurrences of `?x` in the rule become the same fresh `?x__N` object). This is semantics-preserving — it still “separates” invocations — but it avoids creating many duplicate Var objects when a variable appears repeatedly in a rule body.
 
 ### 8.6 Substitution size on deep proofs
 
@@ -565,6 +570,7 @@ Eyeling currently keeps the full trail as-is during search and when emitting ans
 ---
 
 <a id="ch09"></a>
+
 ## Chapter 9 — Forward chaining: saturation, skolemization, and meta-rules (`forwardChain`)
 
 Forward chaining is Eyeling’s outer control loop. It is where facts get added and the closure grows.
@@ -594,12 +600,12 @@ until not changed
 
 There is a nice micro-compiler optimization in `runFixpoint()`:
 
-If a rule’s head is *strictly ground* (no vars, no blanks, no open lists, even inside formulas), and it contains no head blanks, then the head does not depend on *which* body solution you choose.
+If a rule’s head is _strictly ground_ (no vars, no blanks, no open lists, even inside formulas), and it contains no head blanks, then the head does not depend on _which_ body solution you choose.
 
 In that case:
 
-* Eyeling only needs **one** proof of the body.
-* And if all head triples are already known, it can skip proving the body entirely.
+- Eyeling only needs **one** proof of the body.
+- And if all head triples are already known, it can skip proving the body entirely.
 
 This is a surprisingly effective optimization for “axiom-like” rules with constant heads.
 
@@ -609,9 +615,9 @@ Blank nodes in the **rule head** represent existentials: “there exists somethi
 
 Eyeling handles this by replacing head blank labels with fresh blank labels of the form:
 
-* `_:sk_0`, `_:sk_1`, …
+- `_:sk_0`, `_:sk_1`, …
 
-But it does something subtle and important: it caches skolemization per (rule firing, head blank label), so that the *same* firing instance doesn’t keep generating new blanks across outer iterations.
+But it does something subtle and important: it caches skolemization per (rule firing, head blank label), so that the _same_ firing instance doesn’t keep generating new blanks across outer iterations.
 
 The “firing instance” is keyed by a deterministic string derived from the instantiated body (“firingKey”). This stabilizes the closure and prevents “existential churn.”
 
@@ -623,17 +629,17 @@ Implementation: deterministic Skolem IDs live in `lib/skolem.js`; the per-firing
 
 A rule whose conclusion is `false` is treated as a hard failure. During forward chaining:
 
-* Eyeling proves the premise (it only needs one solution)
-* if the premise is provable, it prints a message and exits with status code 2
+- 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.
 
 ### 9.5 Rule-producing rules (meta-rules)
 
-Eyeling treats certain derived triples as *new rules*:
+Eyeling treats certain derived triples as _new rules_:
 
-* `log:implies` and `log:impliedBy` where subject/object are formulas
-* it also accepts the literal `true` as an empty formula `{}` on either side
+- `log:implies` and `log:impliedBy` where subject/object are formulas
+- it also accepts the literal `true` as an empty formula `{}` on either side
 
 So these are “rule triples”:
 
@@ -646,7 +652,7 @@ true log:implies { ... }.
 When such a triple is derived in a forward rule head:
 
 1. Eyeling adds it as a fact (so you can inspect it), and
-2. it *promotes* it into a live rule by constructing a new `Rule` object and inserting it into the forward or backward rule list.
+2. it _promotes_ it into a live rule by constructing a new `Rule` object and inserting it into the forward or backward rule list.
 
 This is meta-programming: your rules can generate new rules during reasoning.
 
@@ -656,30 +662,30 @@ To keep promotion cheap, Eyeling maintains a `Set` of canonical rule keys for bo
 ---
 
 <a id="ch10"></a>
+
 ## Chapter 10 — Scoped closure, priorities, and `log:conclusion`
 
-Some `log:` built-ins talk about “what is included in the closure” or “collect all solutions.” These are tricky in a forward-chaining engine because the closure is *evolving*.
+Some `log:` built-ins talk about “what is included in the closure” or “collect all solutions.” These are tricky in a forward-chaining engine because the closure is _evolving_.
 
 Eyeling addresses this with a disciplined two-phase strategy and an optional priority mechanism.
 
 ### 10.1 The two-phase outer loop (Phase A / Phase B)
 
-Forward chaining runs inside an *outer loop* that alternates:
+Forward chaining runs inside an _outer loop_ that alternates:
 
-* **Phase A**: scoped built-ins are disabled (they “delay” by failing)
+- **Phase A**: scoped built-ins are disabled (they “delay” by failing)
 
-* Eyeling saturates normally to a fixpoint
+- Eyeling saturates normally to a fixpoint
 
-* then Eyeling freezes a snapshot of the saturated facts
+- then Eyeling freezes a snapshot of the saturated facts
 
-* **Phase B**: scoped built-ins are enabled, but they query only the frozen snapshot
+- **Phase B**: scoped built-ins are enabled, but they query only the frozen snapshot
 
-* Eyeling runs saturation again (new facts can appear due to scoped queries)
+- Eyeling runs saturation again (new facts can appear due to scoped queries)
 
 This produces deterministic behavior for scoped operations: they observe a stable snapshot, not a moving target.
 
-**Implementation note (performance):** the two-phase scheme is only needed when the program actually uses scoped built-ins.
-If no rule contains `log:collectAllIn`, `log:forAllIn`, `log:includes`, or `log:notIncludes`, Eyeling now **skips Phase B entirely** and runs only a single saturation. This avoids re-running the forward fixpoint and can prevent a “query-like” forward rule (one whose body contains an expensive backward proof search) from being executed twice.
+**Implementation note (performance):** the two-phase scheme is only needed when the program actually uses scoped built-ins. If no rule contains `log:collectAllIn`, `log:forAllIn`, `log:includes`, or `log:notIncludes`, Eyeling now **skips Phase B entirely** and runs only a single saturation. This avoids re-running the forward fixpoint and can prevent a “query-like” forward rule (one whose body contains an expensive backward proof search) from being executed twice.
 
 **Implementation note (performance):** in Phase A there is no snapshot, so scoped built-ins (and priority-gated scoped queries) are guaranteed to “delay” by failing.  
 Instead of proving the entire forward-rule body only to fail at the end, Eyeling precomputes whether a forward rule depends on scoped built-ins and skips it until a snapshot exists and the requested closure level is reached. This can avoid very expensive proof searches in programs that combine recursion with `log:*In` built-ins.
@@ -688,13 +694,13 @@ Instead of proving the entire forward-rule body only to fail at the end, Eyeling
 
 Eyeling introduces a `scopedClosureLevel` counter:
 
-* level 0 means “no snapshot available” (Phase A)
-* level 1, 2, … correspond to snapshots produced after each Phase A saturation
+- level 0 means “no snapshot available” (Phase A)
+- level 1, 2, … correspond to snapshots produced after each Phase A saturation
 
 Some built-ins interpret a positive integer literal as a requested priority:
 
-* `log:collectAllIn` and `log:forAllIn` use the **object position** for priority
-* `log:includes` and `log:notIncludes` use the **subject position** for priority
+- `log:collectAllIn` and `log:forAllIn` use the **object position** for priority
+- `log:includes` and `log:notIncludes` use the **subject position** for priority
 
 If a rule requests priority `N`, Eyeling delays that builtin until `scopedClosureLevel >= N`.
 
@@ -704,12 +710,12 @@ In practice this allows rule authors to write “don’t run this scoped query u
 
 `log:conclusion` is handled in a particularly elegant way:
 
-* given a formula `{ ... }` (a `GraphTerm`),
-* Eyeling computes the deductive closure *inside that formula*:
+- given a formula `{ ... }` (a `GraphTerm`),
+- Eyeling computes the deductive closure _inside that formula_:
+  - extract rule triples inside it (`log:implies`, `log:impliedBy`)
+  - run `forwardChain` locally over those triples
 
-  * extract rule triples inside it (`log:implies`, `log:impliedBy`)
-  * run `forwardChain` locally over those triples
-* cache the result in a `WeakMap` so the same formula doesn’t get recomputed
+- cache the result in a `WeakMap` so the same formula doesn’t get recomputed
 
 Notably, `log:impliedBy` inside the formula is treated as forward implication too for closure computation (and also indexed as backward to help proving).
 
@@ -718,6 +724,7 @@ This makes formulas a little world you can reason about as data.
 ---
 
 <a id="ch11"></a>
+
 ## Chapter 11 — Built-ins as a standard library (`lib/builtins.js`)
 
 Built-ins are where Eyeling stops being “just a Datalog engine” and becomes a practical N3 tool.
@@ -728,49 +735,49 @@ Implementation note: builtin code lives in `lib/builtins.js` and is wired into t
 
 A predicate is treated as builtin if:
 
-* it is an IRI in one of the builtin namespaces:
+- it is an IRI in one of the builtin namespaces:
+  - `crypto:`, `math:`, `log:`, `string:`, `time:`, `list:`
 
-  * `crypto:`, `math:`, `log:`, `string:`, `time:`, `list:`
-* or it is `rdf:first` / `rdf:rest` (treated as list-like builtins)
-* unless **super restricted mode** is enabled, in which case only `log:implies` and `log:impliedBy` are treated as builtins.
+- or it is `rdf:first` / `rdf:rest` (treated as list-like builtins)
+- unless **super restricted mode** is enabled, in which case only `log:implies` and `log:impliedBy` are treated as builtins.
 
 Super restricted mode exists to let you treat all other predicates as ordinary facts/rules without any built-in evaluation.
 
 ### 11.2 Built-ins return multiple solutions
 
-Every builtin returns a list of substitution *deltas*.
+Every builtin returns a list of substitution _deltas_.
 
 That means built-ins can be:
 
-* **functional** (return one delta binding an output)
-* **tests** (return either `[{}]` for success or `[]` for failure)
-* **generators** (return many deltas)
+- **functional** (return one delta binding an output)
+- **tests** (return either `[{}]` for success or `[]` for failure)
+- **generators** (return many deltas)
 
 List operations are a common source of generators; numeric comparisons are tests.
 
-Below is a drop-in replacement for **§11.3 “A tour of builtin families”** that aims to be *fully self-contained* and to cover **every builtin currently implemented in `lib/builtins.js`** (including the `rdf:first` / `rdf:rest` aliases).
+Below is a drop-in replacement for **§11.3 “A tour of builtin families”** that aims to be _fully self-contained_ and to cover **every builtin currently implemented in `lib/builtins.js`** (including the `rdf:first` / `rdf:rest` aliases).
 
 ---
 
 ## 11.3 A tour of builtin families
 
-Eyeling’s builtins are best thought of as *foreign predicates*: they look like ordinary N3 predicates in your rules, but when the engine tries to satisfy a goal whose predicate is a builtin, it does not search the fact store. Instead, it calls a piece of JavaScript that implements the predicate’s semantics.
+Eyeling’s builtins are best thought of as _foreign predicates_: they look like ordinary N3 predicates in your rules, but when the engine tries to satisfy a goal whose predicate is a builtin, it does not search the fact store. Instead, it calls a piece of JavaScript that implements the predicate’s semantics.
 
-That one sentence explains a lot of “why does it behave like *that*?”:
+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.
+- 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
 
 The N3 Builtins tradition often describes builtins using “schema” annotations like:
 
-* `$s+` / `$o+` — input must be bound (or at least not a variable in practice)
-* `$s-` / `$o-` — output position (often a variable that will be bound)
-* `$s?` / `$o?` — may be unbound
-* `$s.i` — list element *i* inside the subject list
+- `$s+` / `$o+` — input must be bound (or at least not a variable in practice)
+- `$s-` / `$o-` — output position (often a variable that will be bound)
+- `$s?` / `$o?` — may be unbound
+- `$s.i` — list element _i_ inside the subject list
 
 Eyeling is a little more pragmatic: it implements the spirit of these schemas, but it also has several “engineering” conventions that appear across many builtins:
 
@@ -788,13 +795,12 @@ These builtins hash a string and return a lowercase hex digest as a plain string
 
 ### `crypto:sha`, `crypto:md5`, `crypto:sha256`, `crypto:sha512`
 
-**Shape:**
-`$literal crypto:sha256 $digest`
+**Shape:** `$literal crypto:sha256 $digest`
 
 **Semantics (Eyeling):**
 
-* The **subject must be a literal**. Eyeling takes the literal’s lexical form (stripping quotes) as UTF-8 input.
-* The **object** is unified with a **plain string literal** containing the hex digest.
+- The **subject must be a literal**. Eyeling takes the literal’s lexical form (stripping quotes) as UTF-8 input.
+- The **object** is unified with a **plain string literal** containing the hex digest.
 
 **Important runtime note:** Eyeling uses Node’s `crypto` module. If `crypto` is not available (e.g., in some browser builds), these builtins simply **fail** (return no solutions).
 
@@ -821,12 +827,12 @@ A key design choice: Eyeling parses numeric terms fairly strictly, but compariso
 
 These builtins succeed or fail; they do not introduce new bindings.
 
-* `math:greaterThan`  (>)
-* `math:lessThan`     (<)
-* `math:notGreaterThan` (≤)
-* `math:notLessThan`    (≥)
-* `math:equalTo`        (=)
-* `math:notEqualTo`     (≠)
+- `math:greaterThan` (>)
+- `math:lessThan` (<)
+- `math:notGreaterThan` (≤)
+- `math:notLessThan` (≥)
+- `math:equalTo` (=)
+- `math:notEqualTo` (≠)
 
 **Shapes:**
 
@@ -843,15 +849,15 @@ Eyeling also accepts an older cwm-ish variant where the **subject is a 2-element
 
 **Accepted term types (Eyeling):**
 
-* Proper XSD numeric literals (`xsd:integer`, `xsd:decimal`, `xsd:float`, `xsd:double`, and integer-derived types).
-* Untyped numeric tokens (`123`, `-4.5`, `1.2e3`) when they look numeric.
-* `xsd:duration` literals (treated as seconds via a simplified model).
-* `xsd:date` and `xsd:dateTime` literals (converted to epoch seconds for comparison).
+- Proper XSD numeric literals (`xsd:integer`, `xsd:decimal`, `xsd:float`, `xsd:double`, and integer-derived types).
+- Untyped numeric tokens (`123`, `-4.5`, `1.2e3`) when they look numeric.
+- `xsd:duration` literals (treated as seconds via a simplified model).
+- `xsd:date` and `xsd:dateTime` literals (converted to epoch seconds for comparison).
 
 **Edge cases:**
 
-* `NaN` is treated as **not equal to anything**, including itself, for `math:equalTo`.
-* Comparisons involving non-parsable values simply fail.
+- `NaN` is treated as **not equal to anything**, including itself, for `math:equalTo`.
+- Comparisons involving non-parsable values simply fail.
 
 These are pure tests. In forward rules, if a test builtin is encountered before its inputs are bound and it fails, Eyeling may **defer** it and try other goals first; once variables become bound, the test is retried.
 
@@ -865,15 +871,15 @@ These are “function-like” relations where the subject is usually a list and
 
 **Shape:** `( $x1 $x2 ... ) math:sum $total`
 
-* Subject must be a list of **at least two** numeric terms.
-* Computes the numeric sum.
-* Chooses an output datatype based on the “widest” numeric datatype seen among inputs and (optionally) the object position; integers stay integers unless the result is non-integer.
+- Subject must be a list of **at least two** numeric terms.
+- Computes the numeric sum.
+- Chooses an output datatype based on the “widest” numeric datatype seen among inputs and (optionally) the object position; integers stay integers unless the result is non-integer.
 
 #### `math:product`
 
 **Shape:** `( $x1 $x2 ... ) math:product $total`
 
-* Same conventions as `math:sum`, but multiplies.
+- Same conventions as `math:sum`, but multiplies.
 
 #### `math:difference`
 
@@ -885,11 +891,10 @@ Eyeling supports:
 
 1. **Numeric subtraction**: `c = a - b`.
 2. **DateTime difference**: `(dateTime1 dateTime2) math:difference duration`
+   - Produces an `xsd:duration` in whole days (internally computed via seconds then formatted).
 
-   * Produces an `xsd:duration` in whole days (internally computed via seconds then formatted).
 3. **DateTime minus duration**: `(dateTime duration) math:difference dateTime`
-
-   * Subtracts a duration from a dateTime and yields a new dateTime.
+   - Subtracts a duration from a dateTime and yields a new dateTime.
 
 If the types don’t fit any supported case, the builtin fails.
 
@@ -897,33 +902,33 @@ If the types don’t fit any supported case, the builtin fails.
 
 **Shape:** `( $a $b ) math:quotient $q`
 
-* Parses both inputs as numbers.
-* Requires finite values and `b != 0`.
-* Computes `a / b`, picking a suitable numeric datatype for output.
+- Parses both inputs as numbers.
+- Requires finite values and `b != 0`.
+- Computes `a / b`, picking a suitable numeric datatype for output.
 
 #### `math:integerQuotient`
 
 **Shape:** `( $a $b ) math:integerQuotient $q`
 
-* Intended for integer division with remainder discarded (truncation toward zero).
-* Prefers exact arithmetic using **BigInt** if both inputs are integer literals.
-* Falls back to Number parsing if needed, but still requires integer-like values.
+- Intended for integer division with remainder discarded (truncation toward zero).
+- Prefers exact arithmetic using **BigInt** if both inputs are integer literals.
+- Falls back to Number parsing if needed, but still requires integer-like values.
 
 #### `math:remainder`
 
 **Shape:** `( $a $b ) math:remainder $r`
 
-* Integer-only modulus.
-* Uses BigInt when possible; otherwise requires both numbers to still represent integers.
-* Fails on division by zero.
+- Integer-only modulus.
+- Uses BigInt when possible; otherwise requires both numbers to still represent integers.
+- Fails on division by zero.
 
 #### `math:rounded`
 
 **Shape:** `$x math:rounded $n`
 
-* Rounds to nearest integer.
-* Tie-breaking follows JavaScript `Math.round`, i.e. halves go toward **+∞** (`-1.5 -> -1`, `1.5 -> 2`).
-* Eyeling emits the integer as an **integer token literal** (and also accepts typed numerics if they compare equal).
+- Rounds to nearest integer.
+- Tie-breaking follows JavaScript `Math.round`, i.e. halves go toward **+∞** (`-1.5 -> -1`, `1.5 -> 2`).
+- Eyeling emits the integer as an **integer token literal** (and also accepts typed numerics if they compare equal).
 
 ---
 
@@ -933,13 +938,11 @@ If the types don’t fit any supported case, the builtin fails.
 
 **Shape:** `( $base $exp ) math:exponentiation $result`
 
-* Forward direction: if base and exponent are numeric, computes `base ** exp`.
-* Reverse direction (limited): Eyeling can sometimes solve for the exponent if:
-
-  * base and result are numeric, finite, and **positive**
-  * base is not 1
-  * exponent is unbound
-    In that case it uses logarithms: `exp = log(result) / log(base)`.
+- Forward direction: if base and exponent are numeric, computes `base ** exp`.
+- Reverse direction (limited): Eyeling can sometimes solve for the exponent if:
+  - base and result are numeric, finite, and **positive**
+  - base is not 1
+  - exponent is unbound In that case it uses logarithms: `exp = log(result) / log(base)`.
 
 This is a pragmatic inversion, not a full algebra system.
 
@@ -947,12 +950,12 @@ This is a pragmatic inversion, not a full algebra system.
 
 Eyeling implements these as a shared pattern: if the subject is numeric, compute object; else if the object is numeric, compute subject via an inverse function; if both sides are unbound, succeed once (don’t enumerate).
 
-* `math:absoluteValue`
-* `math:negation`
-* `math:degrees` (and implicitly its inverse “radians” conversion)
-* `math:sin`, `math:cos`, `math:tan`
-* `math:asin`, `math:acos`, `math:atan`
-* `math:sinh`, `math:cosh`, `math:tanh` (only if JS provides the functions)
+- `math:absoluteValue`
+- `math:negation`
+- `math:degrees` (and implicitly its inverse “radians” conversion)
+- `math:sin`, `math:cos`, `math:tan`
+- `math:asin`, `math:acos`, `math:atan`
+- `math:sinh`, `math:cosh`, `math:tanh` (only if JS provides the functions)
 
 **Example:**
 
@@ -973,38 +976,35 @@ Implementation: these helpers live in `lib/time.js` and are called from `lib/eng
 
 ### Component extractors
 
-* `time:year`
-* `time:month`
-* `time:day`
-* `time:hour`
-* `time:minute`
-* `time:second`
+- `time:year`
+- `time:month`
+- `time:day`
+- `time:hour`
+- `time:minute`
+- `time:second`
 
-**Shape:**
-`$dt time:month $m`
+**Shape:** `$dt time:month $m`
 
 **Semantics:**
 
-* Subject must be an `xsd:dateTime` literal in a format Eyeling can parse.
-* Object becomes the corresponding integer component (as an integer token literal).
-* If the object is already a numeric literal, Eyeling accepts it if it matches.
+- Subject must be an `xsd:dateTime` literal in a format Eyeling can parse.
+- Object becomes the corresponding integer component (as an integer token literal).
+- If the object is already a numeric literal, Eyeling accepts it if it matches.
 
 ### `time:timeZone`
 
-**Shape:**
-`$dt time:timeZone $tz`
+**Shape:** `$dt time:timeZone $tz`
 
 Returns the trailing zone designator:
 
-* `"Z"` for UTC, or
-* a string like `"+02:00"` / `"-05:00"`
+- `"Z"` for UTC, or
+- a string like `"+02:00"` / `"-05:00"`
 
 It yields a **plain string literal** (and also accepts typed `xsd:string` literals).
 
 ### `time:localTime`
 
-**Shape:**
-`"" time:localTime ?now`
+**Shape:** `"" time:localTime ?now`
 
 Binds `?now` to the current local time as an `xsd:dateTime` literal.
 
@@ -1021,49 +1021,46 @@ Eyeling has a real internal list term (`ListTerm`) that corresponds to N3’s `(
 
 ### RDF collections (`rdf:first` / `rdf:rest`) are materialized
 
-N3 and RDF can also express lists as linked blank nodes using `rdf:first` / `rdf:rest` and `rdf:nil`. Eyeling *materializes* such structures into internal list terms before reasoning so that `list:*` builtins can operate uniformly.
+N3 and RDF can also express lists as linked blank nodes using `rdf:first` / `rdf:rest` and `rdf:nil`. Eyeling _materializes_ such structures into internal list terms before reasoning so that `list:*` builtins can operate uniformly.
 
 For convenience and compatibility, Eyeling treats:
 
-* `rdf:first` as an alias of `list:first`
-* `rdf:rest`  as an alias of `list:rest`
+- `rdf:first` as an alias of `list:first`
+- `rdf:rest` as an alias of `list:rest`
 
 ### Core list destructuring
 
 #### `list:first` (and `rdf:first`)
 
-**Shape:**
-`(a b c) list:first a`
+**Shape:** `(a b c) list:first a`
 
-* Succeeds iff the subject is a **non-empty closed list**.
-* Unifies the object with the first element.
+- Succeeds iff the subject is a **non-empty closed list**.
+- Unifies the object with the first element.
 
 #### `list:rest` (and `rdf:rest`)
 
-**Shape:**
-`(a b c) list:rest (b c)`
+**Shape:** `(a b c) list:rest (b c)`
 
 Eyeling supports both:
 
-* closed lists `(a b c)`, and
-* *open lists* of the form `(a b ... ?T)` internally.
+- closed lists `(a b c)`, and
+- _open lists_ of the form `(a b ... ?T)` internally.
 
 For open lists, “rest” preserves openness:
 
-* Rest of `(a ... ?T)` is `?T`
-* Rest of `(a b ... ?T)` is `(b ... ?T)`
+- Rest of `(a ... ?T)` is `?T`
+- Rest of `(a b ... ?T)` is `(b ... ?T)`
 
 #### `list:firstRest`
 
 This is a very useful “paired” view of a list.
 
-**Forward shape:**
-`(a b c) list:firstRest (a (b c))`
+**Forward shape:** `(a b c) list:firstRest (a (b c))`
 
 **Backward shapes (construction):**
 
-* If the object is `(first restList)`, it can construct the list.
-* If `rest` is a variable, Eyeling constructs an open list term.
+- If the object is `(first restList)`, it can construct the list.
+- If `rest` is a variable, Eyeling constructs an open list term.
 
 This is the closest thing to Prolog’s `[H|T]` in Eyeling.
 
@@ -1077,26 +1074,23 @@ These builtins can yield multiple solutions.
 
 #### `list:member`
 
-**Shape:**
-`(a b c) list:member ?x`
+**Shape:** `(a b c) list:member ?x`
 
 Generates one solution per element, unifying the object with each member.
 
 #### `list:in`
 
-**Shape:**
-`?x list:in (a b c)`
+**Shape:** `?x list:in (a b c)`
 
 Same idea, but the list is in the **object** position and the **subject** is unified with each element.
 
 #### `list:iterate`
 
-**Shape:**
-`(a b c) list:iterate ?pair`
+**Shape:** `(a b c) list:iterate ?pair`
 
 Generates `(index value)` pairs with **0-based indices**:
 
-* `(0 a)`, `(1 b)`, `(2 c)`, …
+- `(0 a)`, `(1 b)`, `(2 c)`, …
 
 A nice ergonomic detail: the object may be a pattern such as:
 
@@ -1108,16 +1102,15 @@ In that case Eyeling unifies `?i` with `1` and checks the value part appropriate
 
 #### `list:memberAt`
 
-**Shape:**
-`( (a b c) 1 ) list:memberAt b`
+**Shape:** `( (a b c) 1 ) list:memberAt b`
 
 The subject must be a 2-element list: `(listTerm indexTerm)`.
 
 Eyeling can use this relationally:
 
-* If the index is bound, it can return the value.
-* If the value is bound, it can search for indices that match.
-* If both are variables, it generates pairs (similar to `iterate`, but with separate index/value logic).
+- If the index is bound, it can return the value.
+- If the value is bound, it can search for indices that match.
+- If both are variables, it generates pairs (similar to `iterate`, but with separate index/value logic).
 
 Indices are **0-based**.
 
@@ -1127,8 +1120,7 @@ Indices are **0-based**.
 
 #### `list:length`
 
-**Shape:**
-`(a b c) list:length 3`
+**Shape:** `(a b c) list:length 3`
 
 Returns the length as an integer token literal.
 
@@ -1136,8 +1128,7 @@ A small but intentional strictness: if the object is already ground, Eyeling doe
 
 #### `list:last`
 
-**Shape:**
-`(a b c) list:last c`
+**Shape:** `(a b c) list:last c`
 
 Returns the last element of a non-empty list.
 
@@ -1145,15 +1136,14 @@ Returns the last element of a non-empty list.
 
 Reversible in the sense that either side may be the list:
 
-* If subject is a list, object becomes its reversal.
-* If object is a list, subject becomes its reversal.
+- If subject is a list, object becomes its reversal.
+- If object is a list, subject becomes its reversal.
 
 It does not enumerate arbitrary reversals; it’s a deterministic transform once one side is known.
 
 #### `list:remove`
 
-**Shape:**
-`( (a b a c) a ) list:remove (b c)`
+**Shape:** `( (a b a c) a ) list:remove (b c)`
 
 Removes all occurrences of an item from a list.
 
@@ -1161,8 +1151,7 @@ Important constraint: the item to remove must be **ground** (fully known) before
 
 #### `list:notMember` (constraint)
 
-**Shape:**
-`(a b c) list:notMember x`
+**Shape:** `(a b c) list:notMember x`
 
 Succeeds iff the object cannot be unified with any element of the subject list. As a test, it typically works best once its inputs are bound; in forward rules Eyeling may defer it if it is reached before bindings are available.
 
@@ -1170,23 +1159,21 @@ Succeeds iff the object cannot be unified with any element of the subject list.
 
 This is list concatenation, but Eyeling implements it in a pleasantly relational way.
 
-**Forward shape:**
-`( (a b) (c) (d e) ) list:append (a b c d e)`
+**Forward shape:** `( (a b) (c) (d e) ) list:append (a b c d e)`
 
 Subject is a list of lists; object is their concatenation.
 
-**Splitting (reverse-ish) mode:**
-If the **object is a concrete list**, Eyeling tries all ways of splitting it into the given number of parts and unifying each part with the corresponding subject element. This can yield multiple solutions and is handy for logic programming patterns.
+**Splitting (reverse-ish) mode:** If the **object is a concrete list**, Eyeling tries all ways of splitting it into the given number of parts and unifying each part with the corresponding subject element. This can yield multiple solutions and is handy for logic programming patterns.
 
 #### `list:sort`
 
 Sorts a list into a deterministic order.
 
-* Requires the input list’s elements to be **ground**.
-* Orders literals numerically when both sides look numeric; otherwise compares their lexical strings.
-* Orders lists lexicographically by elements.
-* Orders IRIs by IRI string.
-* Falls back to a stable structural key for mixed cases.
+- Requires the input list’s elements to be **ground**.
+- Orders literals numerically when both sides look numeric; otherwise compares their lexical strings.
+- Orders lists lexicographically by elements.
+- Orders IRIs by IRI string.
+- Falls back to a stable structural key for mixed cases.
 
 Like `reverse`, this is “reversible” only in the sense that if one side is a list, the other side can be unified with its sorted form.
 
@@ -1194,8 +1181,7 @@ Like `reverse`, this is “reversible” only in the sense that if one side is a
 
 This is one of Eyeling’s most powerful list builtins because it calls back into the reasoner.
 
-**Shape:**
-`( (x1 x2 x3) ex:pred ) list:map ?outList`
+**Shape:** `( (x1 x2 x3) ex:pred ) list:map ?outList`
 
 Semantics:
 
@@ -1207,7 +1193,8 @@ Semantics:
    el predicateIri ?y.
    ```
 
-   using *the full engine* (facts, backward rules, and builtins).
+   using _the full engine_ (facts, backward rules, and builtins).
+
 4. All resulting `?y` values are collected in proof order and concatenated into the output list.
 5. If an element produces no solutions, it contributes nothing.
 
@@ -1217,14 +1204,13 @@ This makes `list:map` a compact “query over a list” operator.
 
 ## 11.3.5 `log:` — unification, formulas, scoping, and meta-level control
 
-The `log:` family is where N3 stops being “RDF with rules” and becomes a *meta-logic*. Eyeling supports the core operators you need to treat formulas as terms, reason inside quoted graphs, and compute closures.
+The `log:` family is where N3 stops being “RDF with rules” and becomes a _meta-logic_. Eyeling supports the core operators you need to treat formulas as terms, reason inside quoted graphs, and compute closures.
 
 ### Equality and inequality
 
 #### `log:equalTo`
 
-**Shape:**
-`$x log:equalTo $y`
+**Shape:** `$x log:equalTo $y`
 
 This is simply **term unification**: it succeeds if the two terms can be unified and returns any bindings that result.
 
@@ -1238,26 +1224,24 @@ In Eyeling, a quoted formula `{ ... }` is represented as a `GraphTerm` whose con
 
 #### `log:conjunction`
 
-**Shape:**
-`( F1 F2 ... ) log:conjunction F`
+**Shape:** `( F1 F2 ... ) log:conjunction F`
 
-* Subject is a list of formulas.
-* Object becomes a formula containing all triples from all inputs.
-* Duplicate triples are removed.
-* The literal `true` is treated as the **empty formula** and is ignored in the merge.
+- Subject is a list of formulas.
+- Object becomes a formula containing all triples from all inputs.
+- Duplicate triples are removed.
+- The literal `true` is treated as the **empty formula** and is ignored in the merge.
 
 #### `log:conclusion`
 
-**Shape:**
-`F log:conclusion C`
+**Shape:** `F log:conclusion C`
 
-Computes the *deductive closure* of the formula `F` **using only the information inside `F`**:
+Computes the _deductive closure_ of the formula `F` **using only the information inside `F`**:
 
-* Eyeling starts with all triples inside `F` as facts.
-* It treats `{A} => {B}` (represented internally as a `log:implies` triple between formulas) as a forward rule.
-* It treats `{A} <= {B}` as the corresponding forward direction for closure purposes.
-* Then it forward-chains to a fixpoint *within that local fact set*.
-* The result is returned as a formula containing all derived triples.
+- Eyeling starts with all triples inside `F` as facts.
+- It treats `{A} => {B}` (represented internally as a `log:implies` triple between formulas) as a forward rule.
+- It treats `{A} <= {B}` as the corresponding forward direction for closure purposes.
+- Then it forward-chains to a fixpoint _within that local fact set_.
+- The result is returned as a formula containing all derived triples.
 
 Eyeling caches `log:conclusion` results per formula object, so repeated calls with the same formula term are cheap.
 
@@ -1267,35 +1251,32 @@ These builtins reach outside the current fact set. They are synchronous by desig
 
 #### `log:content`
 
-**Shape:**
-`<doc> log:content ?txt`
+**Shape:** `<doc> log:content ?txt`
 
-* Dereferences the IRI (fragment stripped) and returns the raw bytes as an `xsd:string` literal.
-* In Node: HTTP(S) is fetched synchronously; non-HTTP is treated as a local file path (including `file://`).
-* In browsers/workers: uses synchronous XHR (subject to CORS).
+- Dereferences the IRI (fragment stripped) and returns the raw bytes as an `xsd:string` literal.
+- In Node: HTTP(S) is fetched synchronously; non-HTTP is treated as a local file path (including `file://`).
+- In browsers/workers: uses synchronous XHR (subject to CORS).
 
 #### `log:semantics`
 
-**Shape:**
-`<doc> log:semantics ?formula`
+**Shape:** `<doc> log:semantics ?formula`
 
 Dereferences and parses the remote/local resource as N3/Turtle-like syntax, returning a formula.
 
-A nice detail: top-level rules in the parsed document are represented *as data* inside the returned formula using `log:implies` / `log:impliedBy` triples between formula terms. This means you can treat “a document plus its rules” as a single first-class formula object.
+A nice detail: top-level rules in the parsed document are represented _as data_ inside the returned formula using `log:implies` / `log:impliedBy` triples between formula terms. This means you can treat “a document plus its rules” as a single first-class formula object.
 
 #### `log:semanticsOrError`
 
 Like `log:semantics`, but on failure it returns a string literal such as:
 
-* `error(dereference_failed,...)`
-* `error(parse_error,...)`
+- `error(dereference_failed,...)`
+- `error(parse_error,...)`
 
 This is convenient in robust pipelines where you want logic that can react to failures.
 
 #### `log:parsedAsN3`
 
-**Shape:**
-`" ...n3 text... " log:parsedAsN3 ?formula`
+**Shape:** `" ...n3 text... " log:parsedAsN3 ?formula`
 
 Parses an in-memory string as N3 and returns the corresponding formula.
 
@@ -1305,10 +1286,10 @@ Parses an in-memory string as N3 and returns the corresponding formula.
 
 Returns one of four IRIs:
 
-* `log:Formula` (quoted graph)
-* `log:Literal`
-* `rdf:List` (closed or open list terms)
-* `log:Other` (IRIs, blank nodes, etc.)
+- `log:Formula` (quoted graph)
+- `log:Literal`
+- `rdf:List` (closed or open list terms)
+- `log:Other` (IRIs, blank nodes, etc.)
 
 ### Literal constructors
 
@@ -1318,9 +1299,9 @@ These two are classic N3 “bridge” operators between structured data and conc
 
 Relates a datatype literal to a pair `(lex datatypeIri)`.
 
-* If object is a literal, it can produce the subject list `(stringLiteral datatypeIri)`.
-* If subject is such a list, it can produce the corresponding datatype literal.
-* If both subject and object are variables, Eyeling treats this as satisfiable and succeeds once.
+- If object is a literal, it can produce the subject list `(stringLiteral datatypeIri)`.
+- If subject is such a list, it can produce the corresponding datatype literal.
+- If both subject and object are variables, Eyeling treats this as satisfiable and succeeds once.
 
 Language-tagged strings are normalized: they are treated as having datatype `rdf:langString`.
 
@@ -1328,20 +1309,20 @@ Language-tagged strings are normalized: they are treated as having datatype `rdf
 
 Relates a language-tagged literal to a pair `(lex langTag)`.
 
-* If object is `"hello"@en`, subject can become `("hello" "en")`.
-* If subject is `("hello" "en")`, object can become `"hello"@en`.
-* Fully unbound succeeds once.
+- If object is `"hello"@en`, subject can become `("hello" "en")`.
+- If subject is `("hello" "en")`, object can become `"hello"@en`.
+- Fully unbound succeeds once.
 
 ### Rules as data: introspection
 
 #### `log:implies` and `log:impliedBy`
 
-As *syntax*, Eyeling parses `{A} => {B}` and `{A} <= {B}` into internal forward/backward rules.
+As _syntax_, Eyeling parses `{A} => {B}` and `{A} <= {B}` into internal forward/backward rules.
 
-As *builtins*, `log:implies` and `log:impliedBy` let you **inspect the currently loaded rule set**:
+As _builtins_, `log:implies` and `log:impliedBy` let you **inspect the currently loaded rule set**:
 
-* `log:implies` enumerates forward rules as `(premiseFormula, conclusionFormula)` pairs.
-* `log:impliedBy` enumerates backward rules similarly.
+- `log:implies` enumerates forward rules as `(premiseFormula, conclusionFormula)` pairs.
+- `log:impliedBy` enumerates backward rules similarly.
 
 Each enumerated rule is standardized apart (fresh variable names) before unification so you can safely query over it.
 
@@ -1349,29 +1330,26 @@ Each enumerated rule is standardized apart (fresh variable names) before unifica
 
 #### `log:includes`
 
-**Shape:**
-`Scope log:includes GoalFormula`
+**Shape:** `Scope log:includes GoalFormula`
 
 This proves all triples in `GoalFormula` as goals, returning the substitutions that make them provable.
 
 Eyeling has **two modes**:
 
 1. **Explicit scope graph**: if `Scope` is a formula `{...}`
-
-   * Eyeling reasons *only inside that formula* (its triples are the fact store).
-   * External rules are not used.
+   - Eyeling reasons _only inside that formula_ (its triples are the fact store).
+   - External rules are not used.
 
 2. **Priority-gated global scope**: otherwise
-
-   * Eyeling uses a *frozen snapshot* of the current global closure.
-   * The “priority” is read from the subject if it’s a positive integer literal `N`.
-   * If the closure level is below `N`, the builtin “delays” by failing at that point in the search.
+   - Eyeling uses a _frozen snapshot_ of the current global closure.
+   - The “priority” is read from the subject if it’s a positive integer literal `N`.
+   - If the closure level is below `N`, the builtin “delays” by failing at that point in the search.
 
 This priority mechanism exists because Eyeling’s forward chaining runs in outer iterations with a “freeze snapshot then evaluate scoped builtins” phase. The goal is to make scoped meta-builtins stable and deterministic: they query a fixed snapshot rather than chasing a fact store that is being mutated mid-iteration.
 
 Also supported:
 
-* The object may be the literal `true`, meaning the empty formula, which is always included (subject to the priority gating above).
+- The object may be the literal `true`, meaning the empty formula, which is always included (subject to the priority gating above).
 
 #### `log:notIncludes` (constraint)
 
@@ -1379,20 +1357,18 @@ Negation-as-failure version: it succeeds iff `log:includes` would yield no solut
 
 #### `log:collectAllIn`
 
-**Shape:**
-`( ValueTemplate WhereFormula OutList ) log:collectAllIn Scope`
+**Shape:** `( ValueTemplate WhereFormula OutList ) log:collectAllIn Scope`
 
-* Proves `WhereFormula` in the chosen scope.
-* For each solution, applies it to `ValueTemplate` and collects the instantiated terms into a list.
-* Unifies `OutList` with that list.
-* If `OutList` is a blank node, Eyeling just checks satisfiable without binding/collecting.
+- Proves `WhereFormula` in the chosen scope.
+- For each solution, applies it to `ValueTemplate` and collects the instantiated terms into a list.
+- Unifies `OutList` with that list.
+- If `OutList` is a blank node, Eyeling just checks satisfiable without binding/collecting.
 
 This is essentially a list-producing “findall”.
 
 #### `log:forAllIn` (constraint)
 
-**Shape:**
-`( WhereFormula ThenFormula ) log:forAllIn Scope`
+**Shape:** `( WhereFormula ThenFormula ) log:forAllIn Scope`
 
 For every solution of `WhereFormula`, `ThenFormula` must be provable under the bindings of that solution. If any witness fails, the builtin fails. No bindings are returned.
 
@@ -1402,18 +1378,17 @@ As a pure test (no returned bindings), this typically works best once its inputs
 
 #### `log:skolem`
 
-**Shape:**
-`$groundTerm log:skolem ?iri`
+**Shape:** `$groundTerm log:skolem ?iri`
 
-Deterministically maps a *ground* term to a Skolem IRI in Eyeling’s well-known namespace. This is extremely useful when you want a repeatable identifier derived from structured content.
+Deterministically maps a _ground_ term to a Skolem IRI in Eyeling’s well-known namespace. This is extremely useful when you want a repeatable identifier derived from structured content.
 
 #### `log:uri`
 
 Bidirectional conversion between IRIs and their string form:
 
-* If subject is an IRI, object can be unified with a string literal of its IRI.
-* If object is a string literal, subject can be unified with the corresponding IRI — **but** Eyeling rejects strings that cannot be safely serialized as `<...>` in Turtle/N3, and it rejects `_:`-style strings to avoid confusing blank nodes with IRIs.
-* Some “fully unbound / don’t-care” combinations succeed once to avoid infinite enumeration.
+- If subject is an IRI, object can be unified with a string literal of its IRI.
+- If object is a string literal, subject can be unified with the corresponding IRI — **but** Eyeling rejects strings that cannot be safely serialized as `<...>` in Turtle/N3, and it rejects `_:`-style strings to avoid confusing blank nodes with IRIs.
+- Some “fully unbound / don’t-care” combinations succeed once to avoid infinite enumeration.
 
 ### Side effects and output directives
 
@@ -1433,8 +1408,8 @@ Implementation: this is implemented by `lib/trace.js` and called from `lib/engin
 
 As a goal, this builtin simply checks that the terms are sufficiently bound/usable and then succeeds. The actual “printing” behavior is handled by the CLI:
 
-* When you run Eyeling with `--strings` / `-r`, the CLI collects all `log:outputString` triples from the *saturated* closure.
-* It sorts them deterministically by the subject “key” and concatenates the string values in that order.
+- When you run Eyeling with `--strings` / `-r`, the CLI collects all `log:outputString` triples from the _saturated_ closure.
+- It sorts them deterministically by the subject “key” and concatenates the string values in that order.
 
 This is a pure test/side-effect marker (it shouldn’t drive search; it should merely validate that strings exist once other reasoning has produced them). In forward rules Eyeling may defer it if it is reached before the terms are usable.
 
@@ -1444,53 +1419,51 @@ This is a pure test/side-effect marker (it shouldn’t drive search; it should m
 
 Eyeling implements string builtins with a deliberate interpretation of “domain is `xsd:string`”:
 
-* Any **IRI** can be cast to a string (its IRI text).
-* Any **literal** can be cast to a string:
+- Any **IRI** can be cast to a string (its IRI text).
+- Any **literal** can be cast to a string:
+  - quoted lexical forms decode N3/Turtle escapes,
+  - unquoted lexical tokens are taken as-is (numbers, booleans, dateTimes, …).
 
-  * quoted lexical forms decode N3/Turtle escapes,
-  * unquoted lexical tokens are taken as-is (numbers, booleans, dateTimes, …).
-* Blank nodes, lists, formulas, and variables are not string-castable (and cause the builtin to fail).
+- Blank nodes, lists, formulas, and variables are not string-castable (and cause the builtin to fail).
 
 ### Construction and concatenation
 
 #### `string:concatenation`
 
-**Shape:**
-`( s1 s2 ... ) string:concatenation s`
+**Shape:** `( s1 s2 ... ) string:concatenation s`
 
 Casts each element to a string and concatenates.
 
 #### `string:format`
 
-**Shape:**
-`( fmt a1 a2 ... ) string:format out`
+**Shape:** `( fmt a1 a2 ... ) string:format out`
 
 A tiny `sprintf` subset:
 
-* Supports only `%s` and `%%`.
-* Any other specifier (`%d`, `%f`, …) causes the builtin to fail.
-* Missing arguments are treated as empty strings.
+- Supports only `%s` and `%%`.
+- Any other specifier (`%d`, `%f`, …) causes the builtin to fail.
+- Missing arguments are treated as empty strings.
 
 ### Containment and prefix/suffix tests (constraints)
 
-* `string:contains`
-* `string:containsIgnoringCase`
-* `string:startsWith`
-* `string:endsWith`
+- `string:contains`
+- `string:containsIgnoringCase`
+- `string:startsWith`
+- `string:endsWith`
 
 All are pure tests: they succeed or fail.
 
 ### Case-insensitive equality tests (constraints)
 
-* `string:equalIgnoringCase`
-* `string:notEqualIgnoringCase`
+- `string:equalIgnoringCase`
+- `string:notEqualIgnoringCase`
 
 ### Lexicographic comparisons (constraints)
 
-* `string:greaterThan`
-* `string:lessThan`
-* `string:notGreaterThan` (≤ in Unicode codepoint order)
-* `string:notLessThan`    (≥ in Unicode codepoint order)
+- `string:greaterThan`
+- `string:lessThan`
+- `string:notGreaterThan` (≤ in Unicode codepoint order)
+- `string:notLessThan` (≥ in Unicode codepoint order)
 
 These compare JavaScript strings directly, i.e., Unicode code unit order (practically “lexicographic” for many uses, but not locale-aware collation).
 
@@ -1498,41 +1471,37 @@ These compare JavaScript strings directly, i.e., Unicode code unit order (practi
 
 Eyeling compiles patterns using JavaScript `RegExp`, with a small compatibility layer:
 
-* 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.
+- 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)
 
-**Shape:**
-`data string:matches pattern`
+**Shape:** `data string:matches pattern`
 
 Tests whether `pattern` matches `data`.
 
 #### `string:replace`
 
-**Shape:**
-`( data pattern replacement ) string:replace out`
+**Shape:** `( data pattern replacement ) string:replace out`
 
-* Compiles `pattern` as a global regex (`/g`).
-* Uses JavaScript replacement semantics (so `$1`, `$2`, etc. work).
-* Returns the replaced string.
+- Compiles `pattern` as a global regex (`/g`).
+- Uses JavaScript replacement semantics (so `$1`, `$2`, etc. work).
+- Returns the replaced string.
 
 #### `string:scrape`
 
-**Shape:**
-`( data pattern ) string:scrape out`
+**Shape:** `( data pattern ) string:scrape out`
 
 Matches the regex once and returns the **first capturing group** (group 1). If there is no match or no group, it fails.
 
-
 ## 11.4 `log:outputString` as a controlled side effect
 
-From a logic-programming point of view, printing is awkward: if you print *during* proof search, you risk producing output along branches that later backtrack, or producing the same line multiple times in different derivations. Eyeling avoids that whole class of problems by treating “output” as **data**.
+From a logic-programming point of view, printing is awkward: if you print _during_ proof search, you risk producing output along branches that later backtrack, or producing the same line multiple times in different derivations. Eyeling avoids that whole class of problems by treating “output” as **data**.
 
 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 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:
 
    ```n3
    :k log:outputString "Hello\n".
@@ -1540,47 +1509,47 @@ The predicate `log:outputString` is the only officially supported “side-effect
 
 then that triple simply becomes part of the fact base like any other fact.
 
-2. **After reasoning (rendering phase):**
-   Once saturation finishes, Eyeling scans the *final closure* for `log:outputString` facts and renders them deterministically (this post-pass lives in `lib/explain.js`). Concretely, the CLI collects all such triples, orders them in a stable way (using the subject as a key so output order is reproducible), and concatenates their string objects into the final emitted text.
+2. **After reasoning (rendering phase):** Once saturation finishes, Eyeling scans the _final closure_ for `log:outputString` facts and renders them deterministically (this post-pass lives in `lib/explain.js`). Concretely, the CLI collects all such triples, orders them in a stable way (using the subject as a key so output order is reproducible), and concatenates their string objects into the final emitted text.
 
 This separation is not just an aesthetic choice; it preserves the meaning of logic search:
 
-* Proof search may explore multiple branches and backtrack. Because output is only rendered from the **final** set of facts, backtracking cannot “un-print” anything and cannot cause duplicated prints from transient branches.
-* Output becomes explainable. If you enable proof comments or inspect the closure, `log:outputString` facts can be traced back to the rules that produced them.
-* Output becomes compositional. You can reason about output strings (e.g., sort them, filter them, derive them conditionally) just like any other data.
+- Proof search may explore multiple branches and backtrack. Because output is only rendered from the **final** set of facts, backtracking cannot “un-print” anything and cannot cause duplicated prints from transient branches.
+- Output becomes explainable. If you enable proof comments or inspect the closure, `log:outputString` facts can be traced back to the rules that produced them.
+- Output becomes compositional. You can reason about output strings (e.g., sort them, filter them, derive them conditionally) just like any other data.
 
-In short: Eyeling makes `log:outputString` safe by refusing to treat it as an immediate effect. It is a *declarative output fact* whose concrete rendering is a final, deterministic post-processing step.
+In short: Eyeling makes `log:outputString` safe by refusing to treat it as an immediate effect. It is a _declarative output fact_ whose concrete rendering is a final, deterministic post-processing step.
 
 ---
 
 <a id="ch12"></a>
+
 ## Chapter 12 — Dereferencing and web-like semantics (`lib/deref.js`)
 
 Some N3 workflows treat IRIs as pointers to more knowledge. Eyeling supports this with:
 
-* `log:content` — fetch raw text
-* `log:semantics` — fetch and parse into a formula
-* `log:semanticsOrError` — produce either a formula or an error literal
+- `log:content` — fetch raw text
+- `log:semantics` — fetch and parse into a formula
+- `log:semanticsOrError` — produce either a formula or an error literal
 
 `deref.js` is deliberately synchronous so the engine can remain synchronous.
 
 ### 12.1 Two environments: Node vs browser/worker
 
-* In **Node**, dereferencing can read:
-
-  * HTTP(S) via a subprocess (still synchronous)
-  * local files (including `file://` URIs) via `fs.readFileSync`
-  * in practice, any non-http IRI is treated as a local path for convenience.
+- In **Node**, dereferencing can read:
+  - HTTP(S) via a subprocess that runs `fetch()` (keeps the engine synchronous)
+  - local files (including `file://` URIs) via `fs.readFileSync`
+  - in practice, any non-http IRI is treated as a local path for convenience.
 
-* In **browser/worker**, dereferencing uses synchronous XHR, subject to CORS, and only for HTTP(S).
+- In **browser/worker**, dereferencing uses synchronous XHR (HTTP(S) only), subject to CORS.
+  - Many browsers restrict synchronous XHR on the main thread; use a worker (as in `demo.html`) to avoid UI blocking.
 
 ### 12.2 Caching
 
 Dereferencing is cached by IRI-without-fragment (fragments are stripped). There are separate caches for:
 
-* raw content text
-* parsed semantics (GraphTerm)
-* semantics-or-error
+- raw content text
+- parsed semantics (GraphTerm)
+- semantics-or-error
 
 This is both a performance and a stability feature: repeated `log:semantics` calls in backward proofs won’t keep refetching.
 
@@ -1591,6 +1560,7 @@ Eyeling can optionally rewrite `http://…` to `https://…` before dereferencin
 ---
 
 <a id="ch13"></a>
+
 ## Chapter 13 — Printing, proofs, and the user-facing output
 
 Once reasoning is done (or as it happens in streaming mode), Eyeling converts derived facts back to N3.
@@ -1599,10 +1569,10 @@ Once reasoning is done (or as it happens in streaming mode), Eyeling converts de
 
 Printing handles:
 
-* compact qnames via `PrefixEnv`
-* `rdf:type` as `a`
-* `owl:sameAs` as `=`
-* nice formatting for lists and formulas
+- compact qnames via `PrefixEnv`
+- `rdf:type` as `a`
+- `owl:sameAs` as `=`
+- nice formatting for lists and formulas
 
 The printer is intentionally simple; it prints what Eyeling can parse.
 
@@ -1610,9 +1580,9 @@ The printer is intentionally simple; it prints what Eyeling can parse.
 
 When enabled, Eyeling prints a compact comment block per derived triple:
 
-* the derived triple
-* the instantiated rule body that was provable
-* the schematic forward rule that produced it
+- the derived triple
+- the instantiated rule body that was provable
+- the schematic forward rule that produced it
 
 It’s a “why this triple holds” explanation, not a globally exported proof graph.
 
@@ -1627,6 +1597,7 @@ This is especially useful in interactive demos (and is the basis of the playgrou
 ---
 
 <a id="ch14"></a>
+
 ## Chapter 14 — Entry points: CLI, bundle exports, and npm API
 
 Eyeling exposes itself in three layers.
@@ -1635,50 +1606,51 @@ Eyeling exposes itself in three layers.
 
 The bundle contains the whole engine. The CLI path is the “canonical behavior”:
 
-* parse input file
-* reason to closure
-* print derived triples or output strings
-* optional proof comments
-* optional streaming
+- parse input file
+- reason to closure
+- print derived triples or output strings
+- optional proof comments
+- optional streaming
 
 #### 14.1.1 CLI options at a glance
 
 The current CLI supports a small set of flags (see `lib/cli.js`):
 
-* `-a`, `--ast` — print the parsed AST as JSON and exit.
-* `-d`, `--deterministic-skolem` — make `log:skolem` stable across runs.
-* `-e`, `--enforce-https` — rewrite `http://…` to `https://…` for dereferencing builtins.
-* `-p`, `--proof-comments` — include per-fact proof comment blocks in output.
-* `-r`, `--strings` — after reasoning, render only `log:outputString` values (ordered by subject key).
-* `-s`, `--super-restricted` — disable all builtins except `log:implies` / `log:impliedBy`.
-* `-t`, `--stream` — stream derived triples as soon as they are derived.
-* `-v`, `--version` — print version and exit.
-* `-h`, `--help` — show usage.
+- `-a`, `--ast` — print the parsed AST as JSON and exit.
+- `-d`, `--deterministic-skolem` — make `log:skolem` stable across runs.
+- `-e`, `--enforce-https` — rewrite `http://…` to `https://…` for dereferencing builtins.
+- `-p`, `--proof-comments` — include per-fact proof comment blocks in output.
+- `-r`, `--strings` — after reasoning, render only `log:outputString` values (ordered by subject key).
+- `-s`, `--super-restricted` — disable all builtins except `log:implies` / `log:impliedBy`.
+- `-t`, `--stream` — stream derived triples as soon as they are derived.
+- `-v`, `--version` — print version and exit.
+- `-h`, `--help` — show usage.
 
 ### 14.2 `lib/entry.js`: bundler-friendly exports
 
 `lib/entry.js` exports:
 
-* public APIs: `reasonStream`, `main`, `version`
-* plus a curated set of internals used by the demo (`lex`, `Parser`, `forwardChain`, etc.)
+- public APIs: `reasonStream`, `main`, `version`
+- plus a curated set of internals used by the demo (`lex`, `Parser`, `forwardChain`, etc.)
 
 ### 14.3 `index.js`: the npm API wrapper
 
 The npm `reason(...)` function does something intentionally simple and robust:
 
-* write your N3 input to a temp file
-* spawn the bundled CLI (`node eyeling.js ... input.n3`)
-* return stdout (and forward stderr)
+- write your N3 input to a temp file
+- spawn the bundled CLI (`node eyeling.js ... input.n3`)
+- return stdout (and forward stderr)
 
 This ensures the API matches the CLI perfectly and keeps the public surface small.
 
 One practical implication:
 
-* if you want *in-process* access to the engine objects (facts arrays, derived proof objects), use `reasonStream` from the bundle entry rather than the subprocess-based API.
+- if you want _in-process_ access to the engine objects (facts arrays, derived proof objects), use `reasonStream` from the bundle entry rather than the subprocess-based API.
 
 ---
 
 <a id="ch15"></a>
+
 ## Chapter 15 — A worked example: Socrates, step by step
 
 Consider:
@@ -1696,19 +1668,16 @@ Consider:
 What Eyeling does:
 
 1. Parsing yields two facts:
-
-   * `(:Socrates rdf:type :Human)`
-   * `(:Human rdfs:subClassOf :Mortal)`
-     and one forward rule:
-   * premise goals: `?S a ?A`, `?A rdfs:subClassOf ?B`
-   * head: `?S a ?B`
+   - `(:Socrates rdf:type :Human)`
+   - `(:Human rdfs:subClassOf :Mortal)` and one forward rule:
+   - premise goals: `?S a ?A`, `?A rdfs:subClassOf ?B`
+   - head: `?S a ?B`
 
 2. Forward chaining scans the rule and calls `proveGoals` on the body.
 
 3. Proving `?S a ?A` matches the first fact, producing `{ S = :Socrates, A = :Human }`.
 
-4. With that substitution, the second goal becomes `:Human rdfs:subClassOf ?B`.
-   It matches the second fact, extending to `{ B = :Mortal }`.
+4. With that substitution, the second goal becomes `:Human rdfs:subClassOf ?B`. It matches the second fact, extending to `{ B = :Mortal }`.
 
 5. Eyeling instantiates the head `?S a ?B` → `:Socrates a :Mortal`.
 
@@ -1719,6 +1688,7 @@ That’s the whole engine in miniature: unify, compose substitutions, emit head
 ---
 
 <a id="ch16"></a>
+
 ## Chapter 16 — Extending Eyeling (without breaking it)
 
 Eyeling is small, which makes it pleasant to extend — but there are a few invariants worth respecting.
@@ -1727,20 +1697,20 @@ Eyeling is small, which makes it pleasant to extend — but there are a few inva
 
 Most extensions belong in `lib/builtins.js` (inside `evalBuiltin`):
 
-* Decide if your builtin is:
-  * a test (0/1 solution)
-  * functional (bind output)
-  * generator (many solutions)
-* Return *deltas* `{ varName: Term }`, not full substitutions.
-* Be cautious with fully-unbound cases: generators can explode the search space.
-* If you add a *new predicate* (not just a new case inside an existing namespace), make sure it is recognized by `isBuiltinPred(...)`.
+- Decide if your builtin is:
+  - a test (0/1 solution)
+  - functional (bind output)
+  - generator (many solutions)
+- Return _deltas_ `{ varName: Term }`, not full substitutions.
+- Be cautious with fully-unbound cases: generators can explode the search space.
+- If you add a _new predicate_ (not just a new case inside an existing namespace), make sure it is recognized by `isBuiltinPred(...)`.
 
 A small architectural note: `lib/builtins.js` is initialized by the engine via `makeBuiltins(deps)`. It receives hooks (unification, proving, deref, scoped-closure helpers, …) instead of importing the engine directly, which keeps the module graph acyclic and makes browser bundling easier.
 
 If your builtin needs a stable view of the scoped closure, follow the scoped-builtin pattern:
 
-* read from `facts.__scopedSnapshot`
-* honor `facts.__scopedClosureLevel` and priority gating
+- read from `facts.__scopedSnapshot`
+- honor `facts.__scopedClosureLevel` and priority gating
 
 And if your builtin is “forward-only” (needs inputs bound), it’s fine to **fail early** until inputs are available — forward rule proving enables builtin deferral, so the goal can be retried later in the same conjunction.
 
@@ -1748,23 +1718,24 @@ And if your builtin is “forward-only” (needs inputs bound), it’s fine to *
 
 If you add a new Term subclass, you’ll likely need to touch:
 
-* printing (`termToN3`)
-* unification and equality (`unifyTerm`, `termsEqual`, fast keys)
-* variable collection for compaction (`gcCollectVarsInTerm`)
-* groundness checks
+- printing (`termToN3`)
+- unification and equality (`unifyTerm`, `termsEqual`, fast keys)
+- variable collection for compaction (`gcCollectVarsInTerm`)
+- groundness checks
 
 ### 16.3 Parser extensions
 
 If you extend parsing, preserve the Rule invariants:
 
-* rule premise is a triple list
-* rule conclusion is a triple list
-* blanks in premise are lifted (or handled consistently)
-* `headBlankLabels` must reflect blanks occurring explicitly in the head *before* skolemization
+- rule premise is a triple list
+- rule conclusion is a triple list
+- blanks in premise are lifted (or handled consistently)
+- `headBlankLabels` must reflect blanks occurring explicitly in the head _before_ skolemization
 
 ---
 
 <a id="epilogue"></a>
+
 ## Epilogue: the philosophy of this engine
 
 Eyeling’s codebase is compact because it chooses one powerful idea and leans into it:
@@ -1782,10 +1753,10 @@ Everything else is engineering detail — interesting, careful, sometimes subtle
 ---
 
 <a id="app-a"></a>
+
 ## Appendix A — Eyeling user notes
 
-This appendix is a compact, user-facing reference for **running Eyeling** and **writing inputs that work well**.
-For deeper explanations and implementation details, follow the chapter links in each section.
+This appendix is a compact, user-facing reference for **running Eyeling** and **writing inputs that work well**. For deeper explanations and implementation details, follow the chapter links in each section.
 
 ### A.1 Install and run
 
@@ -1809,10 +1780,10 @@ See also: [Chapter 14 — Entry points: CLI, bundle exports, and npm API](#ch14)
 
 ### A.2 What Eyeling prints
 
-By default, Eyeling prints **newly derived forward facts** (the heads of fired `=>` rules), serialized as N3.
-It does **not** reprint your input facts.
+By default, Eyeling prints **newly derived forward facts** (the heads of fired `=>` rules), serialized as N3. It does **not** reprint your input facts.
 
 For proof/explanation output and output modes, see:
+
 - [Chapter 13 — Printing, proofs, and the user-facing output](#ch13)
 
 ### A.3 CLI quick reference
@@ -1824,6 +1795,7 @@ eyeling --help
 ```
 
 Options:
+
 ```
   -a, --ast                    Print parsed AST as JSON and exit.
   -d, --deterministic-skolem   Make log:skolem stable across reasoning runs.
@@ -1837,6 +1809,7 @@ Options:
 ```
 
 See also:
+
 - [Chapter 13 — Printing, proofs, and the user-facing output](#ch13)
 - [Chapter 12 — Dereferencing and web-like semantics](#ch12)
 
@@ -1867,9 +1840,11 @@ Quoted graphs/formulas use `{ ... }`. Inside a quoted formula, directive scope m
 - `@prefix/@base` and `PREFIX/BASE` directives may appear at top level **or inside `{ ... }`**, and apply to the formula they occur in (formula-local scoping).
 
 For the formal grammar, see the N3 spec grammar:
+
 - [https://w3c.github.io/N3/spec/#grammar](https://w3c.github.io/N3/spec/#grammar)
 
 See also:
+
 - [Chapter 4 — From characters to AST: lexing and parsing](#ch04)
 
 ### A.5 Builtins
@@ -1877,6 +1852,7 @@ See also:
 Eyeling supports a built-in “standard library” across namespaces like `log:`, `math:`, `string:`, `list:`, `time:`, `crypto:`.
 
 References:
+
 - W3C N3 Built-ins overview: [https://w3c.github.io/N3/reports/20230703/builtins.html](https://w3c.github.io/N3/reports/20230703/builtins.html)
 - Eyeling implementation details: [Chapter 11 — Built-ins as a standard library](#ch11)
 - The shipped builtin catalogue: `eyeling-builtins.ttl` (in this repo)
@@ -1888,42 +1864,49 @@ If you are running untrusted inputs, consider `--super-restricted` to disable al
 When forward rule heads contain blank nodes (existentials), Eyeling replaces them with generated Skolem IRIs so derived facts are ground.
 
 See:
+
 - [Chapter 9 — Forward chaining: saturation, skolemization, and meta-rules](#ch09)
 
 ### A.7 Networking and `log:semantics`
 
-`log:content`, `log:semantics`, and related builtins dereference IRIs and parse retrieved content.
-This is powerful, but it is also I/O.
+`log:content`, `log:semantics`, and related builtins dereference IRIs and parse retrieved content. This is powerful, but it is also I/O.
 
 See:
+
 - [Chapter 12 — Dereferencing and web-like semantics](#ch12)
 
 Safety tip:
-- Use `--super-restricted` if you want to ensure *no* dereferencing (and no other builtins) can run.
+
+- Use `--super-restricted` if you want to ensure _no_ dereferencing (and no other builtins) can run.
 
 ### A.8 Embedding Eyeling in JavaScript
 
 If you depend on Eyeling as a library, the package exposes:
+
 - a CLI wrapper API (`reason(...)`), and
 - in-process engine entry points (via the bundle exports).
 
 See:
+
 - [Chapter 14 — Entry points: CLI, bundle exports, and npm API](#ch14)
 
 ### A.9 Further reading
+
 If you want to go deeper into N3 itself and the logic/programming ideas behind Eyeling, these are good starting points:
 
 N3 / Semantic Web specs and reports:
+
 - [https://w3c.github.io/N3/spec/](https://w3c.github.io/N3/spec/)
 - [https://w3c.github.io/N3/spec/builtins](https://w3c.github.io/N3/spec/builtins)
 - [https://w3c.github.io/N3/spec/semantics](https://w3c.github.io/N3/spec/semantics)
 
 Logic & reasoning background (Wikipedia):
+
 - [https://en.wikipedia.org/wiki/Mathematical_logic](https://en.wikipedia.org/wiki/Mathematical_logic)
 - [https://en.wikipedia.org/wiki/Automated_reasoning](https://en.wikipedia.org/wiki/Automated_reasoning)
 - [https://en.wikipedia.org/wiki/Forward_chaining](https://en.wikipedia.org/wiki/Forward_chaining)
 - [https://en.wikipedia.org/wiki/Backward_chaining](https://en.wikipedia.org/wiki/Backward_chaining)
-- [https://en.wikipedia.org/wiki/Unification_%28computer_science%29](https://en.wikipedia.org/wiki/Unification_%28computer_science%29)
+- [https://en.wikipedia.org/wiki/Unification\_%28computer_science%29](https://en.wikipedia.org/wiki/Unification_%28computer_science%29)
 - [https://en.wikipedia.org/wiki/Prolog](https://en.wikipedia.org/wiki/Prolog)
 - [https://en.wikipedia.org/wiki/Datalog](https://en.wikipedia.org/wiki/Datalog)
 - [https://en.wikipedia.org/wiki/Skolem_normal_form](https://en.wikipedia.org/wiki/Skolem_normal_form)