eyeling 1.24.8 → 1.24.10

package/HANDBOOK.md

@@ -1818,7 +1818,7 @@ Some N3 workflows treat IRIs as pointers to more knowledge. Eyeling supports thi
   - in practice, any non-http IRI is treated as a local path for convenience.
 
 - 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.
+  - Many browsers restrict synchronous XHR on the main thread; use a worker (as in `playground.html`) to avoid UI blocking.
 
 ### 12.2 Caching
 
@@ -2004,7 +2004,7 @@ For browser apps, prefer running Eyeling in a **Web Worker** and importing `eyel
 `lib/entry.js` exports:
 
 - public APIs: `reasonStream`, `reasonRdfJs`, `rdfjs`, `main`, `version`
-- plus a curated set of internals used by the demo (`lex`, `Parser`, `forwardChain`, etc.)
+- plus a curated set of internals used by the playground (`lex`, `Parser`, `forwardChain`, etc.)
 
 `rdfjs` is a small built-in RDF/JS `DataFactory`, so browser / worker code can construct quads without pulling in another package first.
 

package/README.md

@@ -16,5 +16,5 @@ echo '@prefix : <http://example.org/> .
 ## Read more
 
 - [Handbook](https://eyereasoner.github.io/eyeling/HANDBOOK)
-- [Playground](https://eyereasoner.github.io/eyeling/demo)
+- [Playground](https://eyereasoner.github.io/eyeling/playground)
 - [Conformance report](https://codeberg.org/phochste/notation3tests/src/branch/main/reports/report.md)

package/dist/browser/eyeling.browser.js

@@ -8898,10 +8898,10 @@ function main() {
 }
 
 // ---------------------------------------------------------------------------
-// Internals (exposed for demo.html)
+// Internals (exposed for playground.html)
 // ---------------------------------------------------------------------------
 // The original monolithic eyeling.js exposed many internal functions and flags
-// as globals. demo.html (web worker) still relies on a subset of these.
+// as globals. playground.html (web worker) still relies on a subset of these.
 
 function getEnforceHttpsEnabled() {
   return deref.getEnforceHttpsEnabled();
@@ -8946,12 +8946,12 @@ module.exports = {
   N3SyntaxError,
   Parser,
   lex,
-  // demo internals
+  // playground internals
   forwardChain,
   materializeRdfLists,
   isGroundTriple,
   printExplanation,
-  // used by demo worker to stringify derived triples with prefixes
+  // used by playground worker to stringify derived triples with prefixes
   tripleToN3,
   tripleToRdfCompatible,
   // pretty log:query output (when proof comments are disabled)
@@ -8985,7 +8985,7 @@ module.exports = {
 'use strict';
 
 // Entry point for the bundled eyeling.js.
-// We intentionally re-export a small set of internals so demo.html (worker)
+// We intentionally re-export a small set of internals so playground.html (worker)
 // can call into the reasoner like the original monolithic build did.
 
 const engine = require('./engine');
@@ -8999,7 +8999,7 @@ module.exports = {
   main: engine.main,
   version: engine.version,
 
-  // internals for demo.html
+  // internals for playground.html
   lex: engine.lex,
   Parser: engine.Parser,
   forwardChain: engine.forwardChain,
@@ -12283,7 +12283,7 @@ module.exports = {
  * Eyeling Reasoner — printing
  *
  * Pretty-printing / serialization helpers for terms, triples, and formulas.
- * Used by the CLI, demo, and explanations.
+ * Used by the CLI, playground, and explanations.
  */
 
 'use strict';
@@ -13813,7 +13813,7 @@ module.exports = {
 'use strict';
 
 // Small module for debug/trace printing (log:trace) and its run-level state.
-// Kept separate from engine.js so browser demo + CLI can share behavior.
+// Kept separate from engine.js so browser playground + CLI can share behavior.
 
 let tracePrefixes = null;
 
@@ -13899,9 +13899,9 @@ module.exports = {
   try { if (__outerModule && __outerModule.exports) __outerModule.exports = __api; } catch (ignoredError) {}
   try { if (__outerSelf) __outerSelf.eyeling = __api; } catch (ignoredError) {}
 
-  // ---- demo.html compatibility ----
+  // ---- playground.html compatibility ----
   // The original monolithic eyeling.js exposed internal functions/flags as globals.
-  // demo.html still uses these via importScripts(...) inside a web worker.
+  // playground.html still uses these via importScripts(...) inside a web worker.
   try {
     if (__outerSelf && __entry) {
       if (typeof __entry.lex === "function") __outerSelf.lex = __entry.lex;

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

@@ -15,7 +15,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-alarm-bit-interoperability\n\n" .
+:000_md_title log:outputString "# act-alarm-bit-interoperability\n\n## Source files\n\n- [N3 rules](../act-alarm-bit-interoperability.n3)\n\n" .
 
 :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?" .
@@ -160,14 +160,14 @@
 {
   :out log:outputString """ACT harbor alarm bit interoperability
 
-Answer
+## Answer
 YES for the classical alarm bit.
 NO for universal cloning and unrestricted fan-out of the quantum-like token.
 
-Reason Why
+## 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
+## 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

package/examples/act-barley-seed-lineage.n3

@@ -22,7 +22,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-barley-seed-lineage\n\n" .
+:000_md_title log:outputString "# act-barley-seed-lineage\n\n## Source files\n\n- [N3 rules](../act-barley-seed-lineage.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a barley seed lineage achieve accurate self-reproduction, dormancy, development, and adaptive persistence under no-design laws — and what exactly can't happen when key ingredients are missing?" .
@@ -540,14 +540,14 @@
 {
   :out log:outputString """ACT barley seed lineage — can and can't
 
-Answer
+## Answer
 YES for the viable barley lineage.
 NO for the contrast lineages when digital heredity, repair, protected dormancy, or heritable variation are missing.
 
-Reason Why
+## Reason Why
 The main lineage can achieve genome copying under no-design laws because its hereditary information is digitally instantiated. It can also pass through protected dormancy, germinate, produce propagules, reproduce accurately, close its life cycle, and adaptively persist under saline selection. But the contrast lineages show the "can't" side: non-digital heredity blocks accurate genome copying under no-design laws, lack of repair blocks accurate self-reproduction, lack of dormancy protection blocks lineage closure through a protected seed phase, and lack of heritable variation blocks adaptive evolution and thus blocks evolvability.
 
-Check
+## Check
 C1  OK - no-design laws are assumed
 C2  OK - the viable genome can be copied under no-design laws
 C3  OK - the viable seed can achieve protected dormancy

package/examples/act-docking-abort.n3

@@ -16,7 +16,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-docking-abort\n\n" .
+:000_md_title log:outputString "# act-docking-abort\n\n## Source files\n\n- [N3 rules](../act-docking-abort.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a docking-abort token be propagated, permuted, measured and audited across unlike classical media, and what exactly can't be done with the quantum authenticity seal?" .
@@ -263,14 +263,14 @@
 {
   :out log:outputString """ACT docking abort token — constructor-theory coverage case
 
-Answer
+## Answer
 YES for the classical abort token.
 NO for universal cloning and unrestricted audit fan-out of the quantum seal.
 
-Reason Why
+## Reason Why
 The docking-abort token is treated as an abstract information variable carried by unlike classical media: lamp state, PLC register, radio frame, and audit display. Because those substrates are information media for the same variable, the token can be permuted locally, cloned locally, copied across media, measured into an output record, and embedded in serial and parallel task networks. By contrast, the quantum authenticity seal is treated as a superinformation medium, so cloning all of its states is impossible and unrestricted audit fan-out is blocked.
 
-Check
+## Check
 C1  OK - the abort lamp is a computation medium
 C2  OK - the abort lamp distinguishes the abort bit
 C3  OK - permutation of the abort bit is possible on the abort lamp

package/examples/act-gravity-mediator-witness.n3

@@ -16,7 +16,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-gravity-mediator-witness\n\n" .
+:000_md_title log:outputString "# act-gravity-mediator-witness\n\n## Source files\n\n- [N3 rules](../act-gravity-mediator-witness.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "If two quantum sensors become entangled only through a gravitational mediator, while locality and interoperability hold, what can be concluded, and what can't a purely classical mediator model do?" .
@@ -211,14 +211,14 @@
 {
   :out log:outputString """ACT gravity mediator witness
 
-Answer
+## Answer
 YES for the mediator-only witness run.
 NO for a purely classical mediator model under the same mediator-only conditions.
 
-Reason Why
+## Reason Why
 The positive run assumes locality and interoperability, excludes direct coupling between the two quantum systems, and records an entanglement witness after interaction through the mediator alone. Under those constructor-theoretic conditions, the mediator must be non-classical, so the run rules out a purely classical mediator model. The contrast run keeps the same locality, interoperability, and mediator-only structure but assigns the mediator a purely classical model. In that case the mediator-only entanglement witness is blocked, so the run cannot support the same non-classicality conclusion.
 
-Check
+## Check
 C1  OK - locality is assumed in the positive run
 C2  OK - interoperability is assumed in the positive run
 C3  OK - direct coupling between the two quantum systems is excluded

package/examples/act-isolation-breach.n3

@@ -17,7 +17,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-isolation-breach\n\n" .
+:000_md_title log:outputString "# act-isolation-breach\n\n## Source files\n\n- [N3 rules](../act-isolation-breach.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can an isolation-breach token be prepared, permuted, copied, measured, and audited across unlike classical media, and what exactly can't be done with the quantum provenance seal?" .
@@ -327,14 +327,14 @@
 {
   :out log:outputString """ACT isolation-breach token — broad constructor-theory coverage case
 
-Answer
+## Answer
 YES for the classical isolation-breach token.
 NO for universal cloning and unrestricted fan-out of the quantum provenance seal.
 
-Reason Why
+## Reason Why
 The isolation-breach token is treated as an abstract information variable carried by unlike classical media: a door beacon, a containment PLC, a nurse pager, and an incident board. Because those substrates are information media for the same variable, the token can be prepared, permuted, reversed, cloned locally, copied across media, measured into an output record, and composed into serial and parallel task networks. By contrast, the specimen seal is treated as a superinformation medium, so cloning all of its states is impossible and unrestricted parallel fan-out is blocked.
 
-Check
+## Check
 C1  OK - the door beacon is an information medium
 C2  OK - the containment PLC is an information medium
 C3  OK - the nurse pager is an information medium

package/examples/act-photosynthetic-exciton-transfer.n3

@@ -22,7 +22,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-photosynthetic-exciton-transfer\n\n" .
+:000_md_title log:outputString "# act-photosynthetic-exciton-transfer\n\n## Source files\n\n- [N3 rules](../act-photosynthetic-exciton-transfer.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a tuned photosynthetic antenna deliver excitation efficiently to a reaction center by short-lived quantum-assisted transfer, while a detuned contrast complex cannot?" .
@@ -225,14 +225,14 @@
 {
   :out log:outputString """ACT photosynthetic exciton transfer
 
-Answer
+## Answer
 YES for the tuned antenna complex.
 NO for the detuned, strongly decohered contrast complex.
 
-Reason Why
+## Reason Why
 The tuned complex can sample exciton pathways coherently, use vibronically assisted transfer, and exploit short-lived quantum assistance along a downhill route to the reaction center. That makes efficient exciton transfer and reaction-center delivery possible in this case. The detuned contrast complex lacks the same alignment: coherent pathway sampling is blocked, vibronic assistance is unavailable, and the energy landscape is mismatched, so efficient reaction-center delivery is not possible in the same operating picture.
 
-Check
+## Check
 C1  OK - the tuned complex can sample exciton pathways coherently
 C2  OK - the tuned complex can use vibronically assisted transfer
 C3  OK - short-lived quantum assistance is enough in the tuned downhill regime

package/examples/act-sensor-memory-reset.n3

@@ -19,7 +19,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-sensor-memory-reset\n\n" .
+:000_md_title log:outputString "# act-sensor-memory-reset\n\n## Source files\n\n- [N3 rules](../act-sensor-memory-reset.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a radiation sensor's alarm memory be reliably reset with a battery pack, and can the same reset be done using only an ambient heat bath?" .
@@ -170,14 +170,14 @@
 {
   :out log:outputString """ACT sensor memory reset
 
-Answer
+## Answer
 YES with the battery pack.
 NO with the ambient heat bath alone.
 
-Reason Why
+## Reason Why
 The alarm latch is a one-bit memory that must be reset to its standard clear state before the radiation sensor can be reused. In this case, the charged battery pack is treated as a work medium, so it can drive a controlled reset and prepare the latch in its reusable standard state. The ambient bath is treated as a heat medium, so by itself it cannot perform the same reliable directed reset. The example also shows an irreversibility pattern: useful work can be degraded into dissipated heat during reset, but the ambient heat bath alone cannot reconstruct the charged work resource.
 
-Check
+## Check
 C1  OK - the battery pack can drive a controlled reset
 C2  OK - the alarm latch can be reliably reset from work
 C3  OK - the latch can be prepared in its standard reusable state

package/examples/act-tunnel-junction-wake-switch.n3

@@ -18,7 +18,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-tunnel-junction-wake-switch\n\n" .
+:000_md_title log:outputString "# act-tunnel-junction-wake-switch\n\n## Source files\n\n- [N3 rules](../act-tunnel-junction-wake-switch.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a tunnel-junction wake switch trigger a low-bias leak alarm in a regime where a conventional PN junction cannot?" .
@@ -204,14 +204,14 @@
 {
   :out log:outputString """ACT tunnel-junction wake switch
 
-Answer
+## Answer
 YES for the tunnel junction.
 NO for the conventional low-bias PN junction in the same wake-switch regime.
 
-Reason Why
+## Reason Why
 The tunnel junction is modeled as a heavily doped narrow PN junction with overlapping states, so quantum barrier transfer is possible. That makes sub-threshold current possible in the low-forward-bias regime, which in turn makes ultra-low-bias switching possible for the wake circuit. Because the device is also scanned through a peak-to-valley window, a negative differential response is possible as well. By contrast, the conventional junction lacks the structural conditions for the same transfer mode, so it cannot deliver the same low-bias switching task in this case.
 
-Check
+## Check
 C1  OK - the tunnel junction can support quantum barrier transfer
 C2  OK - the tunnel junction is classified as tunneling-dominant
 C3  OK - the tunnel junction can deliver sub-threshold current

package/examples/act-yeast-self-reproduction.n3

@@ -19,7 +19,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# act-yeast-self-reproduction\n\n" .
+:000_md_title log:outputString "# act-yeast-self-reproduction\n\n## Source files\n\n- [N3 rules](../act-yeast-self-reproduction.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a yeast starter culture self-reproduce accurately under no-design laws, and what exactly can't happen for a non-digital contrast lineage?" .
@@ -225,14 +225,14 @@
 {
   :out log:outputString """ACT yeast self-reproduction
 
-Answer
+## Answer
 YES for the viable starter culture.
 NO for accurate self-reproduction in the non-digital contrast lineage.
 
-Reason Why
+## Reason Why
 The starter genome is treated as a replicator storing digital hereditary information, while the cell machinery is treated as the vehicle that enables metabolism and copying support. Under no-design laws, digital information makes accurate genome copying possible. Because the replicator is accurate and paired with a vehicle, the whole starter cell qualifies as a self-reproducer. With a variation source and a selection environment, natural selection also becomes possible. By contrast, the non-digital lineage cannot support accurate genome copying under the same no-design-laws assumption, so it cannot sustain the same accurate self-reproduction or natural-selection story.
 
-Check
+## Check
 C1  OK - no-design laws are assumed
 C2  OK - digital information is physically instantiated for the viable lineage
 C3  OK - a viable replicator is present

package/examples/annotation.n3

@@ -8,5 +8,5 @@
 
 
 # Markdown rendering via log:outputString.
-:__md_output :text "# annotation\n" .
+:__md_output :text "# annotation\n\n## Source files\n\n- [N3 rules](../annotation.n3)\n- [Input TriG](../input/annotation.trig)\n\nRDF 1.2 annotation evidence is loaded from the TriG sidecar and represented as ordinary facts.\n\n## Answer\nYES — the annotated statement says `:a :name \"Alice\"` and gives that statement the identifier `:t`.\n\n## Reason Why\nThe input evidence contains the statement that Alice has the name \"Alice\" and records metadata for the named statement `:t`. In RDF compatibility mode, the named graph form is represented with `log:nameOf`, so `:t` names the statement while `:statedBy` and `:recorded` keep its provenance metadata.\n\n## Check\nC1 OK - the statement `:a :name \"Alice\"` is present\nC2 OK - `:t` names the annotated statement\nC3 OK - the statement is attributed to `:bob`\nC4 OK - the statement is recorded as `2021-07-07`\nC5 OK - the RDF/TriG input sidecar is linked as source evidence\n" .
 { :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/auroracare.n3

@@ -350,19 +350,19 @@
 # Emit one complete output block per scenario to avoid ordering issues between
 # separately derived log:outputString facts.
 
-:out_000_intro log:outputString "# auroracare\n\nAuroraCare — Purpose-based Medical Data Exchange\n\n" .
+:out_000_intro log:outputString "# auroracare\n\n## Source files\n\n- [N3 rules](../auroracare.n3)\n\nAuroraCare — Purpose-based Medical Data Exchange\n\n" .
 
 { :scenario_A :decision "PERMIT" . } => {
   :out_010_A log:outputString """## A – Primary care visit
 Clinician in the patient's care team accessing the patient summary for primary care management.
 
-Answer
+## Answer
 PERMIT
 
-Reason Why
+## Reason Why
 Permitted: clinician in the patient's care team, and the primary-care policy matched.
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 OK - clinician
 C3 OK - care-team linked
@@ -381,13 +381,13 @@ C10 INFO - matched policy: urn:policy:primary-care-001
   :out_020_B log:outputString """## B – Quality improvement (in scope)
 QI analyst using lab results + summary in a secure environment.
 
-Answer
+## Answer
 PERMIT
 
-Reason Why
+## Reason Why
 Permitted: ODRL/DPV policy matched for secondary use.
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 SKIPPED
 C3 SKIPPED
@@ -406,13 +406,13 @@ C10 INFO - matched policy: urn:policy:qi-2025-aurora
   :out_030_C log:outputString """## C – Quality improvement (out of scope)
 QI analyst with only lab results; policy expects labs + summary.
 
-Answer
+## Answer
 DENY
 
-Reason Why
+## Reason Why
 Denied: no policy matched (purpose, environment, TOMs, or categories out of scope).
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 SKIPPED
 C3 SKIPPED
@@ -431,13 +431,13 @@ C10 SKIPPED - no matched policy
   :out_040_D log:outputString """## D – Insurance management
 Insurance bot attempting to use health data for insurance management (prohibited purpose).
 
-Answer
+## Answer
 DENY
 
-Reason Why
+## Reason Why
 Denied: the requested purpose (insurance management) is prohibited by policy.
 
-Check
+## Check
 C1 OK - denied prohibited purpose
 C2 SKIPPED
 C3 SKIPPED
@@ -456,13 +456,13 @@ C10 SKIPPED - no matched policy
   :out_050_E log:outputString """## E – GP checks labs
 GP for the same patient checking lab results via the API gateway.
 
-Answer
+## Answer
 PERMIT
 
-Reason Why
+## Reason Why
 Permitted: clinician in the patient's care team, and the primary-care policy matched.
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 OK - clinician
 C3 OK - care-team linked
@@ -481,13 +481,13 @@ C10 INFO - matched policy: urn:policy:primary-care-001
   :out_060_F log:outputString """## F – Research on anonymised dataset
 Researcher using anonymised labs + summary in a secure environment, with opt-in.
 
-Answer
+## Answer
 PERMIT
 
-Reason Why
+## Reason Why
 Permitted: subject opted in and an ODRL/DPV policy matched (anonymised dataset in secure environment).
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 SKIPPED
 C3 SKIPPED
@@ -506,13 +506,13 @@ C10 INFO - matched policy: urn:policy:research-aurora-diabetes
   :out_070_G log:outputString """## G – AI training (opt-out)
 Data user wants to train AI, but the subject opted out of AI training.
 
-Answer
+## Answer
 DENY
 
-Reason Why
+## Reason Why
 Denied: you opted out of your data being used to train AI systems.
 
-Check
+## Check
 C1 SKIPPED - not a prohibited purpose
 C2 SKIPPED
 C3 SKIPPED

package/examples/backward-recursion.n3

@@ -11,5 +11,5 @@
 
 
 # Markdown rendering via log:outputString.
-:__md_output :text "# backward-recursion\n\n@prefix : <urn:example#> .\n\n:a :reaches :b .\n:a :reaches :c .\n" .
+:__md_output :text "# backward-recursion\n\n## Source files\n\n- [N3 rules](../backward-recursion.n3)\n- [Input TriG](../input/backward-recursion.trig)\n\n@prefix : <urn:example#> .\n\n:a :reaches :b .\n:a :reaches :c .\n" .
 { :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/barley-seed-becoming.n3

@@ -21,7 +21,7 @@
 @prefix arc: <https://example.org/arc#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# barley-seed-becoming\n\n" .
+:000_md_title log:outputString "# barley-seed-becoming\n\n## Source files\n\n- [N3 rules](../barley-seed-becoming.n3)\n\n" .
 
 :case a arc:Case ;
   arc:question "Can a barley seed lineage become a self-renewing and adaptively persistent cycle under no-design laws — and what blocks that becoming when digital heredity, repair, protected dormancy, or variation are missing?" .
@@ -472,14 +472,14 @@
 {
   :out log:outputString """Barley seed lineage — becoming
 
-Answer
+## Answer
 YES for the viable barley lineage.
 NO for the contrast lineages when digital heredity, repair, protected dormancy, or heritable variation are missing.
 
-Reason Why
+## Reason Why
 The main lineage can be read as a becoming: a protected dormant seed can germinate, an adult plant can become a next seed stage, and the lineage can therefore become a self-renewing cycle. Because its hereditary information is digitally instantiated and repair is available, it can also become an accurately reproduced next generation under no-design laws. And because heritable variation is present under a matching selection environment, it can become an adaptively persistent lineage. The contrast lineages mark blocked becomings: non-digital heredity blocks accurate copying, lack of repair blocks reliable renewal, lack of dormancy protection blocks closure through the seed phase, and lack of heritable variation blocks adaptive becoming.
 
-Check
+## Check
 B1  OK - no-design laws are assumed
 B2  OK - the viable genome can become accurately copied
 B3  OK - the viable seed can become a protected dormant phase

package/examples/bmi.n3

@@ -15,7 +15,7 @@
 @prefix math: <http://www.w3.org/2000/10/swap/math#> .
 @prefix string: <http://www.w3.org/2000/10/swap/string#> .
 
-:000_md_title log:outputString "# bmi\n\n" .
+:000_md_title log:outputString "# bmi\n\n## Source files\n\n- [N3 rules](../bmi.n3)\n\n" .
 
 # --------------
 # Editable input
@@ -198,15 +198,15 @@
   :Check :c9 ?C9.
   (
     "BMI — ARC-style Body Mass Index example\n\n"
-    "Answer\n"
+    "## Answer\n"
     "BMI = " ?BmiRounded "\n"
     "Category = " ?Category "\n"
     "At height " ?CmRounded " cm, a healthy-weight range is about " ?HealthyMinRounded "–" ?HealthyMaxRounded " kg (BMI 18.5–24.9).\n\n"
-    "Reason Why\n"
+    "## Reason Why\n"
     "BMI is defined as weight in kilograms divided by height in meters squared. "
     "This program first normalizes the input to SI units, computes BMI, and then applies WHO adult categories as half-open intervals. "
     "The healthy-weight band is the weight range at the same height that corresponds to BMI 18.5 through 24.9.\n\n"
-    "Check\n"
+    "## Check\n"
     "C1 " ?C1 "\n"
     "C2 " ?C2 "\n"
     "C3 " ?C3 "\n"

package/examples/builtin-coverage.n3

@@ -69,5 +69,5 @@
 
 
 # Markdown rendering via log:outputString.
-:__md_output :text "# builtin-coverage\n" .
+:__md_output :text "# builtin-coverage\n\n## Source files\n\n- [N3 rules](../builtin-coverage.n3)\n- [Input TriG](../input/builtin-coverage.trig)\n\n" .
 { :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/calidor.n3

@@ -419,7 +419,7 @@
 # ARC rendering through log:outputString
 # --------------------------------------
 
-:out01 log:outputString "# calidor\n\n## Answer\n" .
+:out01 log:outputString "# calidor\n\n## Source files\n\n- [N3 rules](../calidor.n3)\n\n## Answer\n" .
 
 {
     :case :recommendedPackage ?pkg .

package/examples/collection.n3

@@ -4,5 +4,5 @@ _:b2 :p :q .
 
 
 # Markdown rendering via log:outputString.
-:__md_output :text "# collection\n" .
+:__md_output :text "# collection\n\n## Source files\n\n- [N3 rules](../collection.n3)\n- [Input TriG](../input/collection.trig)\n\n" .
 { :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/complex-matrix-stability.n3

@@ -17,7 +17,7 @@
 @prefix math: <http://www.w3.org/2000/10/swap/math#> .
 @prefix string: <http://www.w3.org/2000/10/swap/string#> .
 
-:000_md_title log:outputString "# complex-matrix-stability\n\n" .
+:000_md_title log:outputString "# complex-matrix-stability\n\n## Source files\n\n- [N3 rules](../complex-matrix-stability.n3)\n\n" .
 
 # --------------
 # Editable input
@@ -256,7 +256,7 @@
     "Complex Matrix Stability — ARC-style
 
 "
-    "Answer
+    "## Answer
 "
     "We compare three diagonal 2x2 complex matrices for discrete-time stability: "
     "A_unstable = " ?MuS ", A_stable = " ?MsS ", and A_damped = " ?MdS ". "
@@ -264,7 +264,7 @@
     "So A_unstable is unstable, A_stable is marginally stable, and A_damped is damped.
 
 "
-    "Reason Why
+    "## Reason Why
 "
     "For a discrete-time linear system x_{k+1} = A x_k, the eigenvalues of A govern the behaviour of the modes. "
     "Because these matrices are diagonal, the eigenvalues are just the diagonal entries. "
@@ -273,7 +273,7 @@
     "Here the diagonal entries give radii 2, 1, and 0 respectively, which explains the three classifications.
 
 "
-    "Check
+    "## Check
 "
     "C1 " ?C1 "
 "

package/examples/context-association.n3

@@ -46,6 +46,6 @@
 }
 =>
 {
-  :report log:outputString "# Context association\n\n## Entailment\nThe RDF dataset associates Bob's data graph with a Data Integrity proof graph and a second metadata proof graph.\n\n## Explanation\nThe input TriG names three graph contexts. The data graph states Bob's name. The signature graph links to that data graph with a proof and records an ecdsa-rdfc-2019 Data Integrity proof from the university issuer. The metadata graph then signs the signature graph itself, giving a chained context association.".
+  :report log:outputString "# Context association\n\n## Source files\n\n- [N3 rules](../context-association.n3)\n- [Input TriG](../input/context-association.trig)\n\n## Entailment\nThe RDF dataset associates Bob's data graph with a Data Integrity proof graph and a second metadata proof graph.\n\n## Explanation\nThe input TriG names three graph contexts. The data graph states Bob's name. The signature graph links to that data graph with a proof and records an ecdsa-rdfc-2019 Data Integrity proof from the university issuer. The metadata graph then signs the signature graph itself, giving a chained context association.".
 }.