eyeling 1.22.6 → 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)
 
 ---
 
@@ -3157,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
 
@@ -3171,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.
@@ -3260,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');
@@ -4883,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) {
@@ -4926,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
@@ -5041,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}`);
@@ -5059,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);
@@ -5968,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;
     }
@@ -5993,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;
     }
@@ -8235,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);

package/examples/act-alarm-bit-interoperability.n3

@@ -0,0 +1,180 @@
+# =====================================================================================
+# ACT harbor alarm bit — interoperability of information media
+#
+# Concrete topic from "The Science of Can and Can't":
+# the same abstract bit can be carried by unlike physical substrates when the
+# relevant information tasks are possible. Constructor theory expresses that in
+# terms of tasks such as permutation, copying, and cloning.
+#
+# This example therefore has both sides:
+#   - CAN   : a classical alarm bit can be permuted and copied between unlike media
+#   - CAN'T : a superinformation token cannot have all of its states universally cloned
+# =====================================================================================
+
+@prefix : <http://example.org/alarm-bit/> .
+@prefix arc: <https://example.org/arc#> .
+@prefix log: <http://www.w3.org/2000/10/swap/log#> .
+
+:case a arc:Case ;
+  arc:question "Can the harbor alarm bit be copied between an optical beacon and a relay register, and what exactly can't be done for a quantum-like token?" .
+
+# --------------------------------------------------------
+# Classical substrates carrying the same abstract variable
+# --------------------------------------------------------
+
+:opticalBeacon a :InformationMedium ;
+  :encodes :AlarmBit ;
+  :zeroState :BlueLamp ;
+  :oneState :RedLamp .
+
+:relayRegister a :InformationMedium ;
+  :encodes :AlarmBit ;
+  :zeroState :LowVoltage ;
+  :oneState :HighVoltage .
+
+# ------------------------------------------------------
+# Contrast substrate with superinformation-like behavior
+# ------------------------------------------------------
+
+:quantumToken a :SuperinformationMedium ;
+  :encodes :PolarizationVariable ;
+  :state :Horizontal ;
+  :state :Vertical ;
+  :state :Diagonal ;
+  :state :AntiDiagonal .
+
+# -------------------------------------------------------
+# CAN rules — what becomes possible for information media
+# -------------------------------------------------------
+
+# Any information medium supports a local permutation of its designated variable.
+{ ?M a :InformationMedium ;
+     :encodes ?V ;
+     :zeroState ?Z ;
+     :oneState ?O . }
+=>
+{ ?M :can :LocalPermutation .
+  [ a :PossibleTask ;
+    :taskType :Permute ;
+    :on ?M ;
+    :variable ?V ;
+    :fromState ?Z ;
+    :toState ?O ] . } .
+
+# Two unlike information media that encode the same variable can interoperate.
+{ ?A a :InformationMedium ; :encodes ?V .
+  ?B a :InformationMedium ; :encodes ?V . }
+=>
+{ ?A :can :InteroperateForVariable .
+  ?B :can :InteroperateForVariable .
+  [ a :PossibleTask ;
+    :taskType :Copy ;
+    :from ?A ;
+    :to ?B ;
+    :variable ?V ] . } .
+
+# ------------------------------------------------------------------
+# CAN'T rules — what becomes impossible for a superinformation token
+# ------------------------------------------------------------------
+
+# A superinformation medium cannot have all of its states universally cloned.
+{ ?M a :SuperinformationMedium ; :encodes ?V . }
+=>
+{ ?M :cannot :UniversalClone .
+  [ a :ImpossibleTask ;
+    :taskType :CloneAllStates ;
+    :on ?M ;
+    :variable ?V ] . } .
+
+# If universal cloning is unavailable, unrestricted classical-style fan-out of
+# the entire state space is unavailable too.
+{ ?M :cannot :UniversalClone . }
+=>
+{ ?M :cannot :UnrestrictedStateFanOut . } .
+
+# ------
+# Checks
+# ------
+
+# Positive checks for the classical alarm bit.
+{ :opticalBeacon a :InformationMedium . }
+=> { :case :checkC1 :Passed . } .
+
+{ :relayRegister a :InformationMedium . }
+=> { :case :checkC2 :Passed . } .
+
+{ :opticalBeacon :encodes :AlarmBit .
+  :relayRegister :encodes :AlarmBit . }
+=> { :case :checkC3 :Passed . } .
+
+{ ?T a :PossibleTask ;
+     :taskType :Copy ;
+     :from :opticalBeacon ;
+     :to :relayRegister ;
+     :variable :AlarmBit . }
+=> { :case :checkC4 :Passed . } .
+
+{ ?T a :PossibleTask ;
+     :taskType :Copy ;
+     :from :relayRegister ;
+     :to :opticalBeacon ;
+     :variable :AlarmBit . }
+=> { :case :checkC5 :Passed . } .
+
+{ :opticalBeacon :can :LocalPermutation . }
+=> { :case :checkC6 :Passed . } .
+
+{ :relayRegister :can :LocalPermutation . }
+=> { :case :checkC7 :Passed . } .
+
+# Negative checks for the superinformation token.
+{ ?T a :ImpossibleTask ;
+     :taskType :CloneAllStates ;
+     :on :quantumToken ;
+     :variable :PolarizationVariable . }
+=> { :case :checkC8 :Passed . } .
+
+{ :quantumToken :cannot :UniversalClone . }
+=> { :case :checkC9 :Passed . } .
+
+{ :quantumToken :cannot :UnrestrictedStateFanOut . }
+=> { :case :checkC10 :Passed . } .
+
+# ----------------
+# ARC-style output
+# ----------------
+
+{ :case :checkC1 :Passed .
+  :case :checkC2 :Passed .
+  :case :checkC3 :Passed .
+  :case :checkC4 :Passed .
+  :case :checkC5 :Passed .
+  :case :checkC6 :Passed .
+  :case :checkC7 :Passed .
+  :case :checkC8 :Passed .
+  :case :checkC9 :Passed .
+  :case :checkC10 :Passed . }
+=>
+{
+  :out log:outputString """ACT harbor alarm bit interoperability
+
+Answer
+YES for the classical alarm bit.
+NO for universal cloning and unrestricted fan-out of the quantum-like token.
+
+Reason Why
+The alarm state is modeled as an abstract bit carried by two unlike classical substrates. Because both the optical beacon and the relay register are information media for the same variable, local permutation and copying in both directions are possible. By contrast, the quantum-like token is treated as a superinformation medium, so universal cloning of all of its states is impossible, and unrestricted classical-style fan-out is blocked as well.
+
+Check
+C1  OK - the optical beacon is an information medium
+C2  OK - the relay register is an information medium
+C3  OK - both substrates encode the same abstract variable: AlarmBit
+C4  OK - AlarmBit can be copied from optical beacon to relay register
+C5  OK - AlarmBit can be copied from relay register to optical beacon
+C6  OK - local permutation of AlarmBit is possible on the optical beacon
+C7  OK - local permutation of AlarmBit is possible on the relay register
+C8  OK - cloning all states of the quantum token is an impossible task
+C9  OK - the quantum token cannot be universally cloned
+C10 OK - the quantum token cannot support unrestricted classical-style fan-out
+""" .
+} .