eyeling 1.22.5 → 1.22.7

package/HANDBOOK.md

@@ -32,6 +32,7 @@
 - [Appendix E — How Eyeling reaches 100% on `notation3tests`](#app-e)
 - [Appendix F — The ARC approach: Answer • Reason Why • Check](#app-f)
 - [Appendix G — Eyeling and the W3C CG Notation3 Semantics](#app-g)
+- [Appendix H — Applied Constructor-Theory and the N3 ARC examples](#app-h)
 
 ---
 
@@ -2599,19 +2600,23 @@ In that sense, N3 is less a bid to make the web “smarter” than a bid to make
 
 <a id="app-c"></a>
 
-## Appendix C — N3 beyond Prolog: logic for RDF-style graphs
+## Appendix C — N3 beyond Prolog: logic that survives the open web
 
-Notation3 (N3) rule sets often look similar to Prolog at the surface: they use variables, unification, and implication-style rules (“if these patterns match, then these patterns follow”). N3 is typically used in a different setting: instead of a single program operating over a single local database, N3 rules and data are commonly written as documents that can be published, shared, merged, and referenced across systems.
+Notation3 and Prolog resemble each other at first glance. Both use variables, unification, and implication-shaped rules. Both can be used to derive consequences from a set of premises. But they were shaped for different native environments. Prolog was designed around executing logic programs. N3 was designed around expressing logic in the same world as RDF: a world of IRIs, triples, graphs, linked documents, and shared vocabularies. That difference in native setting gives N3 a wider built-in reach for web-scale knowledge work.
 
-In practice, that setting is reflected in several common features of N3-style rule writing:
+The first difference is the data model. In Prolog, the basic units are terms and clauses. In N3, the basic units are RDF-style triples and graphs, extended with variables, lists, graph terms, and logical implication. N3 is explicitly defined as an extension of RDF, not as a separate programming language that merely happens to manipulate graphs. That means identifiers, data, and inferred results all live in one interoperable form. A rule consumes graph patterns and produces graph patterns, so the output of reasoning can be published, merged, quoted, exchanged, and reasoned over again without changing representation.
 
-- **Identifiers are IRIs.** Terms are usually global identifiers rather than local symbols, which supports linking across datasets.
-- **Input and output are graphs.** Rules consume graph patterns and produce additional triples, so the result of inference can be represented in the same form as the input data.
-- **Quoted graphs allow statements-as-data.** N3 can treat a graph (a set of triples) as a term, which makes it possible to represent and reason about assertions (e.g., “this source says …” or “this formula implies …”) as data.
-- **Rules can be distributed as text artifacts.** Rules can live alongside data, be versioned, and be reused without requiring an external host language to “carry” the meaning.
-- **Built-ins cover common computations.** Many N3 workflows rely on built-ins for operations such as string handling, list processing, comparisons, and related utilities; some workflows also use IRIs as pointers to retrievable content.
+The second difference is more profound: N3 can treat graphs as first-class terms. A graph term is a quoted graph. It can appear in subject, predicate, or object position, and it does not automatically assert its contents as true. It is a resource in its own right. This makes it natural to represent claims, reports, beliefs, policies, source snapshots, and provenance. One can say not only “this is true,” but also “this document says this,” “this authority concludes that,” or “this rule applies to that quoted context.” In other words, N3 can reason about statements as statements, not only about the world those statements describe.
 
-Engines can combine execution styles in different ways. One common pattern is to use a Prolog-like backward-chaining prover to satisfy rule bodies, while still using forward chaining to add the instantiated conclusions to the fact set until no new facts are produced.
+That leads directly to a third advantage: scope is part of the logic. In N3, implicit universal quantification is global, while implicit existential quantification is local to the graph in which it occurs. Once graphs can be nested and quoted, that distinction matters. It allows a reasoner to keep track of what is asserted here, what is asserted inside a quoted subgraph, and what variables belong to which level. This gives N3 a native way to express context-sensitive reasoning that would feel external or encoded-by-convention in classic Prolog.
+
+A fourth difference is that N3 connects logic to the web inside the language itself. The N3 vocabulary includes `log:semantics` and `log:conclusion` for retrieving and reasoning over local or online sources. It also includes scoped operators such as `log:forAllIn` and `log:notIncludes`, which support scoped universal reasoning and scoped negation-as-failure over a chosen graph or document. So web retrieval, source-bounded reasoning, and reasoning over quoted content are not afterthoughts. They are part of the logic vocabulary. This is one of the clearest senses in which N3 has greater inherent potential: it is not only a language for deriving consequences from facts, but a language for locating, quoting, constraining, and comparing the sources of those facts.
+
+By contrast, classic Prolog is centered on a proof procedure over definite clauses. In the usual operational reading, Prolog applies a restricted form of SLD-resolution, chooses the leftmost goal, tries clauses top-to-bottom, and searches depth-first. Traditional negation is negation-as-failure, described in the SWI-Prolog glossary as a weak negation. This makes Prolog extremely effective as an executable logic language, but it also means that much of its practical power comes from the operational behavior of the engine, not from a web-native knowledge model.
+
+This does not make Prolog inferior. Modern Prolog systems add important capabilities beyond the classic core, including tabling, which improves termination behavior and can make Prolog behave more like a bottom-up theorem prover for some classes of problems. But that actually sharpens the comparison: when Prolog needs to work more comfortably in graph-heavy or knowledge-integration settings, it typically gains that power through extensions, libraries, or host-environment choices. N3 starts there. Graphs, quoted formulas, scoped reasoning, and web-connected semantics are part of its native conceptual center.
+
+So the strongest claim is not that N3 replaces Prolog in every domain. The stronger and more precise claim is this: Prolog is a very strong language for executing logic programs, while N3 has greater inherent potential as a language for publishable, linkable, inspectable, and source-aware logic on the open web. It lets facts, rules, quoted claims, retrieved documents, and derived conclusions all live in one semantic space. For a system like Eyeling, that is not a cosmetic difference. It is the reason the language can scale from local inference to web-shaped reasoning without changing its basic form.
 
 ---
 
@@ -3153,6 +3158,9 @@ The following examples are especially useful if you want to see Eyeling files th
 - [`examples/flandor.n3`](examples/flandor.n3) · [`examples/output/flandor.txt`](examples/output/flandor.txt) — macro-economic coordination case for Flanders that turns sensitive local signals into a regional retooling insight.
 - [`examples/medior.n3`](examples/medior.n3) · [`examples/output/medior.txt`](examples/output/medior.txt) — post-discharge care-coordination case that derives a minimal continuity-bundle insight without sharing the full record.
 - [`examples/parcellocker.n3`](examples/parcellocker.n3) · [`examples/output/parcellocker.txt`](examples/output/parcellocker.txt) — one-time parcel pickup authorization with a clear permit decision, justification, and misuse checks.
+- [`examples/harborsmr.n3`](examples/harborsmr.n3) · [`examples/output/harborsmr.txt`](examples/output/harborsmr.txt) — SMR flexibility case where private plant telemetry becomes a narrow, expiring electrolysis-dispatch insight with policy and safety checks.
+
+- [`examples/transistor-switch.n3`](examples/transistor-switch.n3) · [`examples/output/transistor-switch.txt`](examples/output/transistor-switch.txt) — NPN low-side switch model with exact arithmetic and cutoff-versus-saturation checks.
 
 #### Core ARC-style walkthroughs
 
@@ -3167,10 +3175,24 @@ The following examples are especially useful if you want to see Eyeling files th
 
 #### Technical and scientific ARC demos
 
+- [`examples/fundamental-theorem-arithmetic.n3`](examples/fundamental-theorem-arithmetic.n3) · [`examples/output/fundamental-theorem-arithmetic.txt`](examples/output/fundamental-theorem-arithmetic.txt) — smallest-divisor prime factorization of 202692987 with ARC-style existence, uniqueness-up-to-order, and primality checks.
+- [`examples/complex-matrix-stability.n3`](examples/complex-matrix-stability.n3) · [`examples/output/complex-matrix-stability.txt`](examples/output/complex-matrix-stability.txt) — discrete-time stability classification for three diagonal complex 2×2 matrices via spectral radius and ARC-style checks.
 - [`examples/matrix-mechanics.n3`](examples/matrix-mechanics.n3) · [`examples/output/matrix-mechanics.txt`](examples/output/matrix-mechanics.txt) — small 2×2 matrix example deriving trace, determinant, products, and a non-zero commutator.
 - [`examples/pn-junction-tunneling.n3`](examples/pn-junction-tunneling.n3) · [`examples/output/pn-junction-tunneling.txt`](examples/output/pn-junction-tunneling.txt) — semiconductor toy model that explains current-proxy behavior across bias points.
 - [`examples/transistor-switch.n3`](examples/transistor-switch.n3) · [`examples/output/transistor-switch.txt`](examples/output/transistor-switch.txt) — NPN low-side switch model with exact arithmetic and cutoff-versus-saturation checks.
 
+#### Applied Constructor-Theory ARC examples
+
+- [`examples/act-alarm-bit-interoperability.n3`](examples/act-alarm-bit-interoperability.n3) · [`examples/output/act-alarm-bit-interoperability.txt`](examples/output/act-alarm-bit-interoperability.txt) — applied constructor-theory information example showing interoperability of an alarm bit across unlike media together with a no-cloning contrast for a quantum token.
+- [`examples/act-docking-abort.n3`](examples/act-docking-abort.n3) · [`examples/output/act-docking-abort.txt`](examples/output/act-docking-abort.txt) — applied constructor-theory ARC case for a spacecraft docking-abort token covering permutation, copying, measurement, serial and parallel composition, and the impossibility of cloning a quantum seal.
+- [`examples/act-isolation-breach.n3`](examples/act-isolation-breach.n3) · [`examples/output/act-isolation-breach.txt`](examples/output/act-isolation-breach.txt) — applied constructor-theory ARC case for a biosafety isolation-breach token covering preparation, distinguishability, reversible permutation, copying, measurement, composition, and no-cloning.
+- [`examples/act-gravity-mediator-witness.n3`](examples/act-gravity-mediator-witness.n3) · [`examples/output/act-gravity-mediator-witness.txt`](examples/output/act-gravity-mediator-witness.txt) — applied constructor-theory witness showing that, under locality and interoperability, entanglement mediated only by gravity implies a non-classical gravitational mediator.
+- ['examples/act-yeast-self-reproduction.n3'](examples/act-yeast-self-reproduction.n3) · ['examples/output/act-yeast-self-reproduction.txt'](examples/output/act-yeast-self-reproduction.txt) — applied constructor-theory example of a yeast starter culture showing replicator, vehicle, self-reproduction, heritable variation, and natural selection under no-design laws.
+- ['examples/act-barley-seed-lineage.n3'](examples/act-barley-seed-lineage.n3) · ['examples/output/act-barley-seed-lineage.txt'](examples/output/act-barley-seed-lineage.txt) — applied constructor-theory ARC case showing both possible and impossible lineage tasks under no-design laws, including blocked reproduction, dormancy, and evolvability when key ingredients are missing.
+- ['examples/act-tunnel-junction-wake-switch.n3'](examples/act-tunnel-junction-wake-switch.n3) · ['examples/output/act-tunnel-junction-wake-switch.txt'](examples/output/act-tunnel-junction-wake-switch.txt) — applied constructor-theory ARC case comparing a tunnel-junction wake switch with a conventional PN junction via explicit can/can’t rules for tunneling, sub-threshold current, negative differential response, and low-bias switching.
+- ['examples/act-photosynthetic-exciton-transfer.n3'](examples/act-photosynthetic-exciton-transfer.n3) · ['examples/output/act-photosynthetic-exciton-transfer.txt'](examples/output/act-photosynthetic-exciton-transfer.txt) — applied constructor-theory ARC case for quantum-assisted exciton transfer in a photosynthetic antenna, contrasting a tuned complex with a detuned one via explicit can/can’t rules.
+- ['examples/act-sensor-memory-reset.n3'](examples/act-sensor-memory-reset.n3) · ['examples/output/act-sensor-memory-reset.txt'](examples/output/act-sensor-memory-reset.txt) — applied constructor-theory ARC case showing that a sensor memory reset is possible with a work medium but not with heat alone, highlighting work/heat distinction and irreversibility.
+
 #### Deep-classification stress tests
 
 - [`examples/deep-taxonomy-10.n3`](examples/deep-taxonomy-10.n3) · [`examples/output/deep-taxonomy-10.txt`](examples/output/deep-taxonomy-10.txt) — ARC-style deep-taxonomy benchmark at depth 10.
@@ -3256,3 +3278,230 @@ A good short summary is this:
 - Eyeling also defines a wider operational language than the current semantics document, especially through builtins and scoped proof/query features.
 
 So the handbook and the semantics document are best read as complementary. The semantics document explains the abstract shape of Notation3. The handbook explains how a compact working reasoner realizes that shape, and where it chooses a practical execution model over a purely model-theoretic presentation.
+
+<a id="app-h"></a>
+
+## Appendix H — Applied Constructor-Theory and the N3 ARC examples
+
+This appendix explains the idea behind the **Applied Constructor-Theory** examples collected in the `examples/act-*` files.
+
+The short version is:
+
+> Appendix F explains the **presentation style** of ARC.  
+> This appendix explains the **scientific style** of the ACT examples.
+
+In this handbook, **ACT** is used as a practical label for examples that take constructor-theoretic ideas and turn them into concrete, runnable N3 programs. The label is local to this handbook: it is a convenient way to group examples that are about constructor theory in action, not a claim that there is one official file format or one officially standardized subfield called “ACT”.
+
+### H.1 What constructor theory is trying to do
+
+Constructor theory is a proposal for formulating physics in terms of **which transformations are possible, which are impossible, and why**, rather than only in terms of trajectories and initial conditions.
+
+That shift matters because many scientifically important statements already have that shape:
+
+- information can be copied from one medium to another
+- an accurate self-reproducer can exist under no-design laws
+- a work medium can reset a memory in a way that heat alone cannot
+- a mediator that can entangle two quantum systems cannot be purely classical
+
+Those are not merely predictions of one trajectory. They are statements about a space of **allowed and forbidden tasks**. Constructor theory is designed to make such statements fundamental rather than secondary.
+
+### H.2 Why this matters for applied examples
+
+The constructor-theory programme is often presented through applications and research themes rather than as a closed symbolic calculus. In practice, that makes it a good fit for example-driven reasoning in Eyeling.
+
+An Eyeling ACT example does not try to reproduce the full mathematical machinery of a physics paper. Instead, it extracts the **task structure** of the claim:
+
+- what is being attempted
+- which resources or media are available
+- which structural conditions make the task possible
+- which missing conditions make the task impossible
+- what small set of checks would make the conclusion auditable
+
+That is exactly the kind of thing N3 rules are good at expressing.
+
+### H.3 Why N3 fits constructor-theoretic reasoning unusually well
+
+Notation3 is a good match for constructor-theoretic examples for four reasons.
+
+First, N3 rules are naturally relational. They can say:
+
+```n3
+{ ?system :has ?property . } => { ?system :can ?task . } .
+```
+
+and just as naturally:
+
+```n3
+{ ?system :lacks ?property . } => { ?system :cannot ?task . } .
+```
+
+That is already close to the “science of can and can’t” idiom.
+
+Second, N3 can keep the explanation close to the answer. The conditions, the derived `:can` / `:cannot` facts, and the final human-readable report can all live in one file.
+
+Third, Eyeling supports `log:outputString`, so the result can be rendered as a compact ARC report rather than as a raw closure dump.
+
+Fourth, Eyeling supports rule-based checks and hard fuses (`=> false`), so the example can state not only the claim but also what would count as a contradiction of the claim.
+
+That combination makes N3 a strong medium for **pedagogical applied constructor theory**: it is executable, inspectable, and naturally counterfactual.
+
+### H.4 What these ACT examples are — and what they are not
+
+These examples are **not** microscopic simulations.
+
+They do not solve Schrödinger equations, semiconductor transport equations, or full biochemical kinetics. They are closer to **task-logic models**. They capture the counterfactual structure of a scientific claim:
+
+- if these conditions hold, then this task is possible
+- if these conditions are absent, then that task is impossible
+- if the task is possible, what larger conclusion follows
+- if the task is impossible, what stronger claim is ruled out
+
+That is why an ACT example often looks more like a carefully structured scientific argument than like a numerical simulator.
+
+This is a feature, not a bug. The point is to model the **explanatory logic** of the claim in constructor-theoretic form.
+
+### H.5 The recurring shape of an ACT file in Eyeling
+
+Most of the ACT files in this repository follow the same skeleton.
+
+#### H.5.1 A concrete scenario
+
+Each file starts with a scenario that is tangible enough to picture:
+
+- an alarm bit crossing unlike media
+- a docking abort token
+- a biosafety isolation-breach signal
+- a gravitational mediator witness
+- a yeast or barley lineage
+- a tunnel-junction wake switch
+- a photosynthetic transfer complex
+- a sensor memory that must be reset
+
+The point of the scenario is to stop constructor theory from floating away into abstract slogans.
+
+#### H.5.2 Positive rules: what the system can do
+
+The positive rules derive facts such as:
+
+- `:can :Copy`
+- `:can :Measure`
+- `:can :AccurateSelfReproduction`
+- `:can :EfficientExcitonTransfer`
+- `:can :ReliableResetFromWork`
+
+These are the constructor-theoretic heart of the file. They say which tasks become possible when the right structural conditions are present.
+
+#### H.5.3 Negative rules: what the system cannot do
+
+The negative rules derive facts such as:
+
+- `:cannot :CloneAllStates`
+- `:cannot :AccurateSelfReproduction`
+- `:cannot :AdaptivePersistence`
+- `:cannot :ServeLeakAlarmWakeCircuit`
+- `:cannot :ReadyForReuseFromHeatAlone`
+
+These rules matter just as much as the positive ones. A constructor-theoretic explanation is incomplete if it says only what works and never says what is ruled out.
+
+In practice, the negative rules often provide the sharpest insight in the file.
+
+#### H.5.4 An ARC report
+
+The final rule usually emits a `log:outputString` report with three parts:
+
+- **Answer**
+- **Reason Why**
+- **Check**
+
+That is the Appendix F layer. ARC gives the file a readable surface. Constructor theory gives it the inner scientific logic.
+
+#### H.5.5 Comments that explain the scientific role of each rule block
+
+The better ACT examples are heavily commented. The comments should say not just what the syntax is doing, but what scientific role the block plays:
+
+- interoperability
+- locality
+- no-cloning
+- replicator–vehicle logic
+- work versus heat
+- irreversibility
+- short-lived quantum assistance
+- blocked lineage closure
+
+That is important because these examples are meant to teach a way of thinking, not only to demonstrate parser coverage.
+
+### H.6 The main constructor-theory themes represented in the examples
+
+The current ACT examples are listed in Appendix F’s example catalog. This appendix is the conceptual companion to that list.
+
+Here are the main themes those files illustrate.
+
+#### H.6.1 Information as a task-level notion
+
+The alarm-bit, docking-abort, and isolation-breach examples treat information as something that can be copied, permuted, measured, and moved between unlike media.
+
+#### H.6.2 Life as accurate self-reproduction under no-design laws
+
+The yeast and barley files follow the constructor-theory-of-life pattern: replication, self-reproduction, and natural selection are treated as tasks that can be possible under no-design laws when the right structural conditions are present.
+
+These examples are especially good for N3 because the logic is already rule-shaped:
+
+- digital heredity enables accurate copying
+- vehicle structure enables construction and repair
+- variation plus selection enables adaptive persistence
+- missing ingredients block those tasks
+
+#### H.6.3 Thermodynamics as possible and impossible tasks
+
+The sensor-memory-reset example is a compact way to express constructor-theoretic thermodynamics: a work-like resource can drive a reliable reset task that heat alone cannot, and an irreversible degradation path need not have the exact reverse available.
+
+#### H.6.4 Non-classicality witnesses in hybrid systems
+
+The gravity-mediator example shows how a constructor-theoretic application can be expressed as a chain of constraints: if locality and interoperability hold, and a mediator can entangle two quantum systems, then that mediator cannot be purely classical.
+
+That kind of claim is perfect for N3 because it is already naturally expressed as a chain of conditions and consequences rather than as a trajectory simulation.
+
+#### H.6.5 Quantum effects in practical settings
+
+The tunnel-junction and photosynthetic-transfer files show how ACT examples can model quantum effects without pretending to be full microscopic calculations. They capture the counterfactual claim that certain structural conditions make a task possible, while contrast conditions block it.
+
+This is often the right level of abstraction for a reasoning example: detailed enough to be about a real scientific idea, but explicit enough to stay executable and inspectable.
+
+### H.7 How to read an ACT example well
+
+A good reading order is:
+
+1. identify the concrete application scenario
+2. identify the `:can` facts the file is trying to establish
+3. identify the `:cannot` facts that provide the contrast
+4. read the final ARC report
+5. go back and inspect the rule blocks that justify that report
+6. check whether the file includes explicit validation or a fuse
+
+That order preserves the scientific meaning of the example. You first see the task. Then you see the allowed and forbidden transformations. Only then do you look at the syntax in detail.
+
+### H.8 What makes a strong ACT example in this repository
+
+A strong ACT example in Eyeling usually has five traits.
+
+It is **concrete**. The reader can picture the system.
+
+It is **counterfactual**. The file derives both a meaningful `:can` and a meaningful `:cannot`.
+
+It is **commented at the scientific level**. The comments explain principles, not just syntax.
+
+It is **ARC-shaped**. The answer, reason, and checks are visible.
+
+And it is **honest about scope**. It does not pretend to be a full physical simulation when it is really a task-logic model.
+
+### H.9 Why keep these examples in the handbook at all
+
+Because constructor theory can otherwise seem either too abstract or too grand.
+
+The ACT examples solve that by making the ideas runnable. They let a reader see, in a small executable artifact, how a principle about possible and impossible tasks can be turned into explicit rules, explicit contrasts, and explicit checks.
+
+That is valuable even for readers who do not plan to work on constructor theory itself. It shows a wider lesson:
+
+> some scientific explanations are best understood not as “what happened once,” but as “what could be made to happen, what could not, and what structural features make the difference.”
+
+That is exactly the sort of explanation that N3, and Eyeling in particular, can make unusually clear.

package/dist/browser/eyeling.browser.js

@@ -2359,6 +2359,23 @@
     // ===========================================================================
     // Backward proof & builtins mutual recursion — declarations first
 
+    function __varCameFromBoundSubstitution(goalTerm, subst) {
+      if (!(goalTerm instanceof Var)) return false;
+      if (!subst || !Object.prototype.hasOwnProperty.call(subst, goalTerm.name)) return false;
+
+      let cur = subst[goalTerm.name];
+      const seen = new Set([goalTerm.name]);
+
+      while (cur instanceof Var) {
+        if (seen.has(cur.name)) return true;
+        seen.add(cur.name);
+        if (!Object.prototype.hasOwnProperty.call(subst, cur.name)) return true;
+        cur = subst[cur.name];
+      }
+
+      return false;
+    }
+
     function evalBuiltin(goal, subst, facts, backRules, depth, varGen, maxResults) {
       const g = applySubstTriple(goal, subst);
       const pv = iriValue(g.p);
@@ -3834,7 +3851,7 @@
       // Schema: $s+ log:rawType $o-
       // Returns one of log:Formula, log:Literal, rdf:List, or log:Other.
       if (pv === LOG_NS + 'rawType') {
-        if (g.s instanceof Var) return [];
+        if (g.s instanceof Var && !__varCameFromBoundSubstitution(goal.s, subst)) return [];
 
         let ty;
         if (g.s instanceof GraphTerm) ty = internIri(LOG_NS + 'Formula');
@@ -3988,6 +4005,23 @@
           results.push(s2);
         }
 
+        // Also match quoted log:implies triples present as data in the current scope.
+        if (facts && typeof facts.length === 'number') {
+          ensureFactIndexes(facts);
+          const pb = facts.__byPred.get(goal.p.__tid) || [];
+          for (const idx of pb) {
+            const tr = facts[idx];
+
+            let s2 = unifyTerm(goal.s, tr.s, subst);
+            if (s2 === null) continue;
+
+            s2 = unifyTerm(goal.o, tr.o, s2);
+            if (s2 === null) continue;
+
+            results.push(s2);
+          }
+        }
+
         return results;
       }
 
@@ -4017,6 +4051,23 @@
           results.push(s2);
         }
 
+        // Also match quoted log:impliedBy triples present as data in the current scope.
+        if (facts && typeof facts.length === 'number') {
+          ensureFactIndexes(facts);
+          const pb = facts.__byPred.get(goal.p.__tid) || [];
+          for (const idx of pb) {
+            const tr = facts[idx];
+
+            let s2 = unifyTerm(goal.s, tr.s, subst);
+            if (s2 === null) continue;
+
+            s2 = unifyTerm(goal.o, tr.o, s2);
+            if (s2 === null) continue;
+
+            results.push(s2);
+          }
+        }
+
         return results;
       }
 
@@ -4849,7 +4900,11 @@
 
     'use strict';
 
+    const path = require('node:path');
+    const { pathToFileURL } = require('node:url');
+
     const engine = require('./engine');
+    const deref = require('./deref');
     const { PrefixEnv } = require('./prelude');
 
     function offsetToLineCol(text, offset) {
@@ -4892,6 +4947,29 @@
       return fs.readFileSync(0, { encoding: 'utf8' });
     }
 
+    function __isNetworkOrFileIri(s) {
+      return typeof s === 'string' && /^(https?:|file:\/\/)/i.test(s);
+    }
+
+    function __sourceLabelToBaseIri(sourceLabel) {
+      if (!sourceLabel || sourceLabel === '<stdin>') return '';
+      if (__isNetworkOrFileIri(sourceLabel)) return deref.stripFragment(sourceLabel);
+      return pathToFileURL(path.resolve(sourceLabel)).toString();
+    }
+
+    function __readInputSourceSync(sourceLabel) {
+      if (sourceLabel === '<stdin>') return readTextFromStdinSync();
+
+      if (__isNetworkOrFileIri(sourceLabel)) {
+        const txt = deref.derefTextSync(sourceLabel);
+        if (typeof txt !== 'string') throw new Error(`Failed to dereference ${sourceLabel}`);
+        return txt;
+      }
+
+      const fs = require('node:fs');
+      return fs.readFileSync(sourceLabel, { encoding: 'utf8' });
+    }
+
     function main() {
       // Drop "node" and script name; keep only user-provided args
       // Expand combined short options: -pt == -p -t
@@ -5007,13 +5085,11 @@
       }
 
       const sourceLabel = useImplicitStdin || positional[0] === '-' ? '<stdin>' : positional[0];
+      const baseIri = __sourceLabelToBaseIri(sourceLabel);
+
       let text;
       try {
-        if (sourceLabel === '<stdin>') text = readTextFromStdinSync();
-        else {
-          const fs = require('node:fs');
-          text = fs.readFileSync(sourceLabel, { encoding: 'utf8' });
-        }
+        text = __readInputSourceSync(sourceLabel);
       } catch (e) {
         if (sourceLabel === '<stdin>') console.error(`Error reading stdin: ${e.message}`);
         else console.error(`Error reading file ${JSON.stringify(sourceLabel)}: ${e.message}`);
@@ -5025,6 +5101,7 @@
       try {
         toks = engine.lex(text);
         const parser = new engine.Parser(toks);
+        if (baseIri) parser.prefixes.setBase(baseIri);
         [prefixes, triples, frules, brules, qrules] = parser.parseDocument();
         // Make the parsed prefixes available to log:trace output (CLI path)
         engine.setTracePrefixes(prefixes);
@@ -5934,21 +6011,80 @@
     // -----------------------------------------------------------------------------
     // Used to maintain O(1) membership sets for dynamically promoted rules, and to
     // memoize per-firing head-blank skolemization.
+    //
+    // Important: variables and blank nodes *inside quoted formulas* are local to the
+    // formula. Canonicalize those labels by first occurrence so alpha-equivalent
+    // formulas (for example the repeated results of log:semantics after
+    // standardize-apart) get the same identity key. Keep top-level blank labels
+    // untouched so distinct existential witnesses in the global fact set do not
+    // collapse together.
+    function __keyFromTermForRuleIdentity(term) {
+      const ctx = { quotedVar: new Map(), quotedBlank: new Map() };
+
+      function canonQuotedVar(name) {
+        let out = ctx.quotedVar.get(name);
+        if (!out) {
+          out = `v${ctx.quotedVar.size}`;
+          ctx.quotedVar.set(name, out);
+        }
+        return out;
+      }
+
+      function canonQuotedBlank(label) {
+        let out = ctx.quotedBlank.get(label);
+        if (!out) {
+          out = `b${ctx.quotedBlank.size}`;
+          ctx.quotedBlank.set(label, out);
+        }
+        return out;
+      }
+
+      function enc(u, inQuotedFormula) {
+        if (u instanceof Iri) return ['I', u.value];
+        if (u instanceof Literal) return ['L', u.value];
+        if (u instanceof Blank) return inQuotedFormula ? ['BQ', canonQuotedBlank(u.label)] : ['B', u.label];
+        if (u instanceof Var) return inQuotedFormula ? ['VQ', canonQuotedVar(u.name)] : ['V', u.name];
+        if (u instanceof ListTerm) return ['List', u.elems.map((e) => enc(e, inQuotedFormula))];
+        if (u instanceof OpenListTerm) {
+          return [
+            'OpenList',
+            u.prefix.map((e) => enc(e, inQuotedFormula)),
+            inQuotedFormula ? ['TailVQ', canonQuotedVar(u.tailVar)] : ['TailV', u.tailVar],
+          ];
+        }
+        if (u instanceof GraphTerm)
+          return ['Graph', u.triples.map((tr) => [enc(tr.s, true), enc(tr.p, true), enc(tr.o, true)])];
+        return ['Other', String(u)];
+      }
+
+      return JSON.stringify(enc(term, false));
+    }
+
     function __ruleKey(isForward, isFuse, premise, conclusion, dynamicConclusionTerm /* optional */) {
       let out = (isForward ? 'F' : 'B') + (isFuse ? '!' : '') + '|P|';
       for (let i = 0; i < premise.length; i++) {
         const tr = premise[i];
         if (i) out += '\n';
-        out += skolemKeyFromTerm(tr.s) + '\t' + skolemKeyFromTerm(tr.p) + '\t' + skolemKeyFromTerm(tr.o);
+        out +=
+          __keyFromTermForRuleIdentity(tr.s) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.p) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.o);
       }
       out += '|C|';
       for (let i = 0; i < conclusion.length; i++) {
         const tr = conclusion[i];
         if (i) out += '\n';
-        out += skolemKeyFromTerm(tr.s) + '\t' + skolemKeyFromTerm(tr.p) + '\t' + skolemKeyFromTerm(tr.o);
+        out +=
+          __keyFromTermForRuleIdentity(tr.s) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.p) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.o);
       }
       if (dynamicConclusionTerm) {
-        out += '|T|' + skolemKeyFromTerm(dynamicConclusionTerm);
+        out += '|T|' + __keyFromTermForRuleIdentity(dynamicConclusionTerm);
       }
       return out;
     }
@@ -5959,7 +6095,12 @@
       for (let i = 0; i < instantiatedPremises.length; i++) {
         const tr = instantiatedPremises[i];
         if (i) out += '\n';
-        out += skolemKeyFromTerm(tr.s) + '\t' + skolemKeyFromTerm(tr.p) + '\t' + skolemKeyFromTerm(tr.o);
+        out +=
+          __keyFromTermForRuleIdentity(tr.s) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.p) +
+          '\t' +
+          __keyFromTermForRuleIdentity(tr.o);
       }
       return out;
     }
@@ -8201,7 +8342,17 @@
           if (remaining <= 0) continue;
           const builtinMax = Number.isFinite(remaining) && !restGoals.length ? remaining : undefined;
 
-          let deltas = evalBuiltin(goal0, {}, facts, backRules, frame.curDepth, varGen, builtinMax);
+          const builtinGoalForEval = goalPredicateIri === LOG_NS + 'rawType' ? rawGoal : goal0;
+          const builtinSubstForEval = goalPredicateIri === LOG_NS + 'rawType' ? substMut : {};
+          let deltas = evalBuiltin(
+            builtinGoalForEval,
+            builtinSubstForEval,
+            facts,
+            backRules,
+            frame.curDepth,
+            varGen,
+            builtinMax,
+          );
 
           const dc = typeof frame.deferCount === 'number' ? frame.deferCount : 0;
           const builtinDeltasAreVacuous = deltas.length > 0 && deltas.every((d) => Object.keys(d).length === 0);