eyeling 1.24.8 → 1.24.9

package/examples/output/genetic-algorithm.md

@@ -1,3 +1,7 @@
 # genetic-algorithm  
 
+## Source files  
+
+- [N3 rules](../genetic-algorithm.n3)  
+
 GA evolved 11111101010 -> 2026 in 8 generations.  

package/examples/output/genetic-knapsack-selection.md

@@ -1,5 +1,10 @@
 # genetic-knapsack-selection  
 
+## Source files  
+
+- [N3 rules](../genetic-knapsack-selection.n3)  
+- [Input TriG](../input/genetic-knapsack-selection.trig)  
+
 ## Answer  
 final genome : 101000000101  
 selected items : item01, item03, item10, item12  

package/examples/output/gps.md

@@ -1,15 +1,19 @@
 # gps  
 
+## Source files  
+
+- [N3 rules](../gps.n3)  
+
 GPS — Goal driven route planning  
 
-Answer  
+## Answer  
 Take the direct route via Brugge.  
 Recommended route: Gent → Brugge → Oostende  
 
-Reason Why  
+## Reason Why  
 From Gent to Oostende, the planner found two routes in this small map. The direct route (Gent → Brugge → Oostende) takes 2400 seconds at cost 0.01, with belief 0.9408 and comfort 0.99. The alternative (Gent → Kortrijk → Brugge → Oostende) takes 4100 seconds at cost 0.018, with belief 0.903168 and comfort 0.9801. So the direct route is faster, cheaper, more reliable, and slightly more comfortable.  
 
-Check  
+## Check  
 C1 OK - the direct Gent → Brugge → Oostende route was derived.  
 C2 OK - the alternative Gent → Kortrijk → Brugge → Oostende route was derived.  
 C3 OK - the recommended route is faster than the alternative.  

package/examples/output/harborsmr.md

@@ -1,15 +1,19 @@
 # harborsmr  
 
+## Source files  
+
+- [N3 rules](../harborsmr.n3)  
+
 HarborSMR — bounded flexible-export insight for port electrolysis  
 
-Answer  
+## Answer  
 PERMIT  
 The port hydrogen hub may use the SMR insight to run PEM electrolyzer train 2 at 16 MW from 14:00 to 18:00.  
 
-Reason Why  
+## Reason Why  
 The operator shares only a narrow, expiring insight that a temporary 18 MW flexible-export window is available. The request is for electrolysis dispatch only, the requested 16 MW fits inside the permitted window, safety margins are above threshold, no outage blocks the window, and the policy forbids redistribution for market resale. Raw reactor telemetry stays local.  
 
-Check  
+## Check  
 C1  OK - reserve margin exceeds the dispatch threshold  
 C2  OK - cooling margin exceeds the dispatch threshold  
 C3  OK - no planned outage blocks the window  

package/examples/output/interop-demo.md

@@ -1,3 +1,7 @@
 # interop-demo  
 
+## Source files  
+
+- [N3 rules](../interop-demo.n3)  
+
 ACTION: apply GoldDiscount and send invoice reminder (opt-in confirmed).  

package/examples/output/matrix-mechanics.md

@@ -1,5 +1,9 @@
 # matrix-mechanics  
 
+## Source files  
+
+- [N3 rules](../matrix-mechanics.n3)  
+
 ## Answer  
 In this toy matrix-mechanics model, the Hamiltonian has two discrete energy levels and does not commute with a second observable.  
 

package/examples/output/medior.md

@@ -1,5 +1,9 @@
 # medior  
 
+## Source files  
+
+- [N3 rules](../medior.n3)  
+
 ## Answer  
 Name: Medior  
 Region: Flanders  

package/examples/output/n3-speaks-for-itself.md

@@ -1,5 +1,9 @@
 # n3-speaks-for-itself  
 
+## Source files  
+
+- [N3 rules](../n3-speaks-for-itself.n3)  
+
 @prefix : <https://example.org/n3-speaks#> .  
 @prefix foaf: <http://xmlns.com/foaf/0.1/> .  
 @prefix id: <https://example.org/id/> .  

package/examples/output/odrl-dpv-ehds-risk-ranked.md

@@ -1,5 +1,9 @@
 # odrl-dpv-ehds-risk-ranked  
 
+## Source files  
+
+- [N3 rules](../odrl-dpv-ehds-risk-ranked.n3)  
+
 ## Ranked DPV Risk Report (EHDS-aligned)  
 Agreement: EHDS Secondary Use Agreement (example)  
 Profile: Example patient profile (EHDS rights expectations)  

package/examples/output/odrl-dpv-healthcare-risk-ranked.md

@@ -1,5 +1,9 @@
 # odrl-dpv-healthcare-risk-ranked  
 
+## Source files  
+
+- [N3 rules](../odrl-dpv-healthcare-risk-ranked.n3)  
+
 ## Ranked DPV Risk Report (Healthcare & Life Sciences)  
 Agreement: Example Healthcare & Life-Sciences Data Use Agreement  
 Profile: Example patient profile  

package/examples/output/odrl-dpv-risk-ranked.md

@@ -1,5 +1,9 @@
 # odrl-dpv-risk-ranked  
 
+## Source files  
+
+- [N3 rules](../odrl-dpv-risk-ranked.n3)  
+
 ## Ranked DPV Risk Report  
 Agreement: Example Agreement  
 Profile: Example consumer profile  

package/examples/output/odrl-risk-mitigation.md

@@ -1,5 +1,9 @@
 # odrl-risk-mitigation  
 
+## Source files  
+
+- [N3 rules](../odrl-risk-mitigation.n3)  
+
 ## Risk report for Example Platform Agreement (with fixes) (profile: Carol (example consumer))  
 1) score=100 (https://example.org/odrl-mitigation-demo#High), clause D6 — Provider can delete user data. This clause is risky because it allows the provider to delete the consumer’s data. Clause D6: We may delete your data at our discretion.  
 2) score=93 (https://example.org/odrl-mitigation-demo#High), clause D5 — No data export / portability. This clause is risky because it prohibits exporting data, undermining portability. Clause D5: You may not export or download your data from the service.  

package/examples/output/odrl-risk.md

@@ -1,5 +1,9 @@
 # odrl-risk  
 
+## Source files  
+
+- [N3 rules](../odrl-risk.n3)  
+
 ## Risk report for Example SaaS Agreement (profile: Alice (example consumer))  
 1) score=100 (https://example.org/agreement#High), clause C2 — Provider can delete user data. This clause is risky because it allows the provider to remove (delete) the consumer’s data. Clause C2: We may delete your data at our discretion, with or without notice.  
 2) score=95 (https://example.org/agreement#High), clause C3 — Data sharing without consent. This clause is risky because it permits data sharing without an explicit consent requirement. Clause C3: We may share your data with partners for any purpose.  

package/examples/output/ontology-question-generation.md

@@ -0,0 +1,31 @@
+# ontology-question-generation  
+
+This example uses N3 rules to generate candidate competency questions from OWL/RDFS ontology patterns. The rules derive structured `q:CompetencyQuestion` resources and render this Markdown with `log:outputString`.  
+
+## Source files  
+
+- [N3 rules](../ontology-question-generation.n3)  
+- [Input ontology TriG](../input/ontology-question-generation.trig)  
+
+## Detected competency questions  
+
+- **Class population** — Which things are instances of `employee`?  
+- **Class population** — Which things are instances of `organization`?  
+- **Class population** — Which things are instances of `person`?  
+- **Class population** — Which things are instances of `project`?  
+- **Subclass distinction** — What distinguishes `employee` from a general `person`?  
+- **Object property** — For a given `employee`, which `project` is related by `assigned to`?  
+- **Object property** — For a given `organization`, which `person` is related by `employs`?  
+- **Object property** — For a given `person`, which `organization` is related by `works for`?  
+- **Datatype property** — What is the `birth date` value of a given `person`?  
+- **Datatype property** — What is the `legal name` value of a given `organization`?  
+- **Existential restriction** — For each `employee`, which `organization` must exist via `works for`?  
+- **Minimum cardinality** — Does every `employee` need at least `1` value for `assigned to`?  
+- **Disjointness** — Can something ever be both an `organization` and a `person`?  
+- **Functional property** — Can one subject have multiple values for `birth date`?  
+- **Inverse property** — If `x` has `works for` `y`, should `y` have `employs` `x`?  
+- **Subproperty** — When `principal employer` holds, should `works for` also hold?  
+
+## RDF shape behind the Markdown  
+
+Each rendered line is backed by a structured generated resource with a pattern, slots, an answer shape, and priority. That means a later layer can verbalize the same generated questions as Markdown, SPARQL skeletons, SHACL prompts, UI forms, or documentation checks.  

package/examples/output/parcellocker.md

@@ -1,15 +1,19 @@
 # parcellocker  
 
+## Source files  
+
+- [N3 rules](../parcellocker.n3)  
+
 ParcelLocker — One-time parcel pickup by a friend  
 
-Answer  
+## Answer  
 PERMIT  
 Noah may collect Maya's parcel from locker B17.  
 
-Reason Why  
+## Reason Why  
 Maya created a one-time authorization for Noah only, for this parcel only, at this locker only, and for pickup only. The token is active, the parcel is ready, and the same authorization does not reveal billing details or allow redirection.  
 
-Check  
+## Check  
 C1  OK - requester matches the named delegate  
 C2  OK - requested parcel matches the authorized parcel  
 C3  OK - requested locker matches the authorized locker  

package/examples/output/pn-junction-tunneling.md

@@ -1,5 +1,9 @@
 # pn-junction-tunneling  
 
+## Source files  
+
+- [N3 rules](../pn-junction-tunneling.n3)  
+
 ## Answer  
 In this toy PN-junction tunneling model, heavy doping narrows the depletion region enough for a tunneling window that rises to a peak and then falls, producing a negative-differential region.  
 case                          : pn-junction-tunneling  

package/examples/output/queens.md

@@ -1,5 +1,9 @@
 # queens  
 
+## Source files  
+
+- [N3 rules](../queens.n3)  
+
 Solving 14-Queens...  
 Printing at most 1 solution(s).  
 

package/examples/output/rc-discharge-envelope.md

@@ -1,5 +1,10 @@
 # rc-discharge-envelope  
 
+## Source files  
+
+- [N3 rules](../rc-discharge-envelope.n3)  
+- [Input TriG](../input/rc-discharge-envelope.trig)  
+
 ## Answer  
 exact decay symbol : exp(-1/4)  
 certified decay interval : [0.7788007830, 0.7788007831]  

package/examples/output/rdf-dataset.md

@@ -1,5 +1,10 @@
 # rdf-dataset  
 
+## Source files  
+
+- [N3 rules](../rdf-dataset.n3)  
+- [Input TriG](../input/rdf-dataset.trig)  
+
 VERSION "1.2"  
 
 @prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-dataset#> .  

package/examples/output/rdf-message-flow.md

@@ -1,5 +1,10 @@
 # rdf-message-flow  
 
+## Source files  
+
+- [N3 rules](../rdf-message-flow.n3)  
+- [Input TriG](../input/rdf-message-flow.trig)  
+
 ## Answer  
 Continuous RDF Message flow accepted: 5 ordered messages moved through the ingest → validate → interpret → route → sink pipeline. The threshold was 26, so results 21 and 22 were archived, the heartbeat kept the stream alive, and results 28 and 29 were emitted as alerts.  
 

package/examples/output/rdf-messages.md

@@ -1,5 +1,10 @@
 # rdf-messages  
 
+## Source files  
+
+- [N3 rules](../rdf-messages.n3)  
+- [Input TriG](../input/rdf-messages.trig)  
+
 ## Answer  
 RDF Message log accepted: 3 explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label _:b0 is safely reused in separate messages.  
 

package/examples/output/resto.md

@@ -1,17 +1,21 @@
 # resto  
 
+## Source files  
+
+- [N3 rules](../resto.n3)  
+
 RESTdesc — Restaurant finder  
 
-Answer  
+## Answer  
 A restaurant was found and reserved.  
 Restaurant: Maximiliaan  
 Date: 2026-04-08  
 Seating: outside terrace  
 
-Reason Why  
+## Reason Why  
 The plan resolved the person's address, turned it into a map point, checked the local weather, selected a suitable restaurant, and then created a reservation. Because the weather came back mild and stable (22 C and 1016 mbar), the chosen seating stayed outdoors.  
 
-Check  
+## Check  
 C1 OK - the preferences service resolved the person's address.  
 C2 OK - the location service turned the address into map coordinates.  
 C3 OK - the weather services supplied temperature and pressure for that location.  

package/examples/output/school-placement-audit.md

@@ -1,5 +1,10 @@
 # school-placement-audit  
 
+## Source files  
+
+- [N3 rules](../school-placement-audit.n3)  
+- [Input TriG](../input/school-placement-audit.trig)  
+
 ## Answer  
 audit result : fail  
 children affected by straight-line rule : Ada, Björn, Davi  

package/examples/output/smoke-arithmetic.md

@@ -1,5 +1,10 @@
 # smoke-arithmetic  
 
+## Source files  
+
+- [N3 rules](../smoke-arithmetic.n3)  
+- [Input TriG](../input/smoke-arithmetic.trig)  
+
 ## Answer  
 product = 42  
 

package/examples/output/sqrt2-cauchy.md

@@ -1,5 +1,9 @@
 # sqrt2-cauchy  
 
+## Source files  
+
+- [N3 rules](../sqrt2-cauchy.n3)  
+
 Approximation (at limit): sqrt2 ≈ 1.414213562373095  
 n=0  x=1.0  delta=seed  err=1  
 n=1  x=1.5  delta=0.5  err=0.25  

package/examples/output/sqrt2-dedekind.md

@@ -1,5 +1,9 @@
 # sqrt2-dedekind  
 
+## Source files  
+
+- [N3 rules](../sqrt2-dedekind.n3)  
+
 q=-2  q^2=4  => LEFT (q<0 OR q^2<2)  
 q=-1  q^2=1  => LEFT (q<0 OR q^2<2)  
 q=-0.5  q^2=0.25  => LEFT (q<0 OR q^2<2)  

package/examples/output/sudoku.md

@@ -1,5 +1,9 @@
 # sudoku  
 
+## Source files  
+
+- [N3 rules](../sudoku.n3)  
+
 ## Answer  
 The puzzle is solved, and the completed grid is the unique valid Sudoku solution.  
 case              : sudoku  

package/examples/output/transcendental-numbers-stretched.md

@@ -1,5 +1,9 @@
 # transcendental-numbers-stretched  
 
+## Source files  
+
+- [N3 rules](../transcendental-numbers-stretched.n3)  
+
 @prefix : <https://example.org/transcendental#> .  
 
 :report :concerns :prod_e_pi .  

package/examples/output/transistor-switch.md

@@ -1,5 +1,9 @@
 # transistor-switch  
 
+## Source files  
+
+- [N3 rules](../transistor-switch.n3)  
+
 ## Answer  
 In this toy transistor-switch model, a low input leaves the transistor in cutoff (OFF) and a high input drives it into saturation (ON), so the load behaves like an on/off branch rather than a linear amplifier.  
 case                             : transistor-switch  

package/examples/output/triple-terms.md

@@ -1,5 +1,10 @@
 # triple-terms  
 
+## Source files  
+
+- [N3 rules](../triple-terms.n3)  
+- [Input TriG](../input/triple-terms.trig)  
+
 VERSION "1.2"  
 
 @prefix : <https://eyereasoner.github.io/eyeling/examples/triple_terms#> .  

package/examples/output/tunnel-junction-wake-switch-becoming.md

@@ -1,15 +1,19 @@
 # tunnel-junction-wake-switch-becoming  
 
+## Source files  
+
+- [N3 rules](../tunnel-junction-wake-switch-becoming.n3)  
+
 tunnel-junction wake switch — becoming  
 
-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 can be read as a becoming under low forward bias. Because it is modeled as a heavily doped narrow PN junction with overlapping states, it can become a quantum-transfer state. In that regime it can become a sub-threshold current state, and under peak-to-valley scanning it can also become a negative differential response state. As a wake-switch device, that lets it become an ultra-low-bias switching state and finally a leak-alarm wake-serving state. By contrast, the conventional junction lacks the structural conditions needed for the same transition into quantum transfer, so the later wake-serving becoming is blocked as well.  
 
-Check  
+## Check  
 B1  OK - the tunnel junction can become a quantum-transfer state  
 B2  OK - the tunnel junction is classified as tunneling-dominant  
 B3  OK - the tunnel junction can become a sub-threshold current state  

package/examples/output/wind-turbine.md

@@ -1,14 +1,18 @@
 # wind-turbine  
 
+## Source files  
+
+- [N3 rules](../wind-turbine.n3)  
+
 Wind turbine — Predictive maintenance  
 
-Answer  
+## Answer  
 Act now: schedule an urgent inspection and gearbox maintenance.  
 
-Reason Why  
+## Reason Why  
 North field turbine reports vibration 0.42 against a threshold of 0.35, temperature 78 against a threshold of 75, and rotor speed 1650 against a critical limit of 1800. Both vibration and temperature are above their safety thresholds, so the turbine shows a combined warning pattern. The gearbox is also degraded, so maintenance is needed even though the rotor speed is still below the critical RPM limit.  
 
-Check  
+## Check  
 C1 OK - measured vibration is above the vibration threshold.  
 C2 OK - measured temperature is above the temperature threshold.  
 C3 OK - a high-vibration anomaly was inferred from the readings.  

package/examples/parcellocker.n3

@@ -11,7 +11,7 @@
 @prefix : <https://example.org/parcellocker#> .
 @prefix log: <http://www.w3.org/2000/10/swap/log#> .
 
-:000_md_title log:outputString "# parcellocker\n\n" .
+:000_md_title log:outputString "# parcellocker\n\n## Source files\n\n- [N3 rules](../parcellocker.n3)\n\n" .
 
 # -----
 # Facts
@@ -103,7 +103,7 @@
 
 { :case :decision :Permit . }
     => {
-        :out log:outputString "ParcelLocker — One-time parcel pickup by a friend\n\nAnswer\nPERMIT\nNoah may collect Maya's parcel from locker B17.\n\nReason Why\nMaya created a one-time authorization for Noah only, for this parcel only, at this locker only, and for pickup only. The token is active, the parcel is ready, and the same authorization does not reveal billing details or allow redirection.\n\nCheck\nC1  OK - requester matches the named delegate\nC2  OK - requested parcel matches the authorized parcel\nC3  OK - requested locker matches the authorized locker\nC4  OK - requested action is parcel collection\nC5  OK - requested purpose is pickup only\nC6  OK - authorization is active\nC7  OK - authorization is single-use\nC8  OK - parcel is ready for pickup\nC9  OK - billing details stay hidden\nC10 OK - parcel redirection is not allowed\n" .
+        :out log:outputString "ParcelLocker — One-time parcel pickup by a friend\n\n## Answer\nPERMIT\nNoah may collect Maya's parcel from locker B17.\n\n## Reason Why\nMaya created a one-time authorization for Noah only, for this parcel only, at this locker only, and for pickup only. The token is active, the parcel is ready, and the same authorization does not reveal billing details or allow redirection.\n\n## Check\nC1  OK - requester matches the named delegate\nC2  OK - requested parcel matches the authorized parcel\nC3  OK - requested locker matches the authorized locker\nC4  OK - requested action is parcel collection\nC5  OK - requested purpose is pickup only\nC6  OK - authorization is active\nC7  OK - authorization is single-use\nC8  OK - parcel is ready for pickup\nC9  OK - billing details stay hidden\nC10 OK - parcel redirection is not allowed\n" .
     } .
 
 # ----------------

package/examples/pn-junction-tunneling.n3

@@ -136,7 +136,7 @@
   ( "peak current proxy            : %s\n" ?peakCurrent ) string:format ?peakCurrentLine .
 }
     => {
-         :01-answer-1 log:outputString "# pn-junction-tunneling\n\n## Answer\n" .
+         :01-answer-1 log:outputString "# pn-junction-tunneling\n\n## Source files\n\n- [N3 rules](../pn-junction-tunneling.n3)\n\n## Answer\n" .
          :01-answer-2 log:outputString "In this toy PN-junction tunneling model, heavy doping narrows the depletion region enough for a tunneling window that rises to a peak and then falls, producing a negative-differential region.\n" .
          :01-answer-3 log:outputString "case                          : pn-junction-tunneling\n" .
          :01-answer-4 log:outputString ?peakBiasLine .

package/examples/queens.n3

@@ -16,6 +16,6 @@
   :run :n ?N; :maxPrint ?MaxPrint.
   (?N ?MaxPrint) :render ?Report.
 } log:query {
-  :000_md_title log:outputString "# queens\n\n" .
+  :000_md_title log:outputString "# queens\n\n## Source files\n\n- [N3 rules](../queens.n3)\n\n" .
   :answer log:outputString ?Report.
 }.

package/examples/rc-discharge-envelope.n3

@@ -44,5 +44,5 @@
 {
   :case :exactDecaySymbol ?Symbol; :decayLower ?Lower; :decayUpper ?Upper; :firstBelowToleranceStep ?Step.
   ?Step :index ?Index; :timeSeconds ?Time; :upperVoltage ?Voltage.
-  ("# rc-discharge-envelope\n\n## Answer\nexact decay symbol : %s\ncertified decay interval : [%.10f, %.10f]\nfirst below tolerance step : %d\nfirst below tolerance time : %.3f s\nupper voltage at step %d : %.6f V\n\n## Explanation\nThe physical decay factor is exp(-1/4), but the example uses a finite double interval as the certificate. Because the interval lies strictly between 0 and 1, the capacitor voltage envelope contracts each sample. The upper envelope is the safety-relevant bound: once it falls below 1.0 V, every compatible exact trajectory is below tolerance." ?Symbol ?Lower ?Upper ?Index ?Time ?Index ?Voltage) string:format ?Block.
+  ("# rc-discharge-envelope\n\n## Source files\n\n- [N3 rules](../rc-discharge-envelope.n3)\n- [Input TriG](../input/rc-discharge-envelope.trig)\n\n## Answer\nexact decay symbol : %s\ncertified decay interval : [%.10f, %.10f]\nfirst below tolerance step : %d\nfirst below tolerance time : %.3f s\nupper voltage at step %d : %.6f V\n\n## Explanation\nThe physical decay factor is exp(-1/4), but the example uses a finite double interval as the certificate. Because the interval lies strictly between 0 and 1, the capacitor voltage envelope contracts each sample. The upper envelope is the safety-relevant bound: once it falls below 1.0 V, every compatible exact trajectory is below tolerance." ?Symbol ?Lower ?Upper ?Index ?Time ?Index ?Voltage) string:format ?Block.
 } => { :report log:outputString ?Block. }.

package/examples/rdf-dataset.n3

@@ -26,5 +26,5 @@ VERSION "1.2"
 
 
 # Markdown rendering via log:outputString.
-:__md_output :text "# rdf-dataset\n\nVERSION \"1.2\"\n\n@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-dataset#> .\n\n:workOrder :entails <<( :sensor :needs :inspection )>> .\n" .
+:__md_output :text "# rdf-dataset\n\n## Source files\n\n- [N3 rules](../rdf-dataset.n3)\n- [Input TriG](../input/rdf-dataset.trig)\n\nVERSION \"1.2\"\n\n@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-dataset#> .\n\n:workOrder :entails <<( :sensor :needs :inspection )>> .\n" .
 { :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/rdf-message-flow.n3

@@ -134,7 +134,7 @@
   :m005 :atStage :sink;
     msg:payloadResult ?FifthResult;
     :route :alertSink.
-  ("# rdf-message-flow\n\n## Answer\nContinuous RDF Message flow accepted: %d ordered messages moved through the ingest → validate → interpret → route → sink pipeline. The threshold was %d, so results %s and %s were archived, the heartbeat kept the stream alive, and results %s and %s were emitted as alerts.\n\n## Explanation\nThe N3 source starts only :m001 at ingress. Each message must reach :sink before the continuous-flow rule releases its msg:nextMessage. Observation payloads are inspected with log:includes inside each message formula, while the empty heartbeat uses the same envelope and routing stages without a payload. This models messages flowing through a live stream while preserving message boundaries." ?Count ?Threshold ?FirstResult ?SecondResult ?FourthResult ?FifthResult) string:format ?Block.
+  ("# rdf-message-flow\n\n## Source files\n\n- [N3 rules](../rdf-message-flow.n3)\n- [Input TriG](../input/rdf-message-flow.trig)\n\n## Answer\nContinuous RDF Message flow accepted: %d ordered messages moved through the ingest → validate → interpret → route → sink pipeline. The threshold was %d, so results %s and %s were archived, the heartbeat kept the stream alive, and results %s and %s were emitted as alerts.\n\n## Explanation\nThe N3 source starts only :m001 at ingress. Each message must reach :sink before the continuous-flow rule releases its msg:nextMessage. Observation payloads are inspected with log:includes inside each message formula, while the empty heartbeat uses the same envelope and routing stages without a payload. This models messages flowing through a live stream while preserving message boundaries." ?Count ?Threshold ?FirstResult ?SecondResult ?FourthResult ?FifthResult) string:format ?Block.
 } => {
   :rdfMessageFlowExample log:outputString ?Block.
   :rdfMessageFlowExample :demonstrates :ContinuousFlow, :BackPressureRelease, :AtomicMessageContext, :HeartbeatInFlow, :ThresholdRouting.

package/examples/rdf-messages.n3

@@ -97,7 +97,7 @@
   :BlankNodeScope :reusedLabel ?Label;
     :isPerMessage true.
   :MessageContext :differentObservationsStayContextual true.
-  ("# rdf-messages\n\n## Answer\nRDF Message log accepted: %d explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label %s is safely reused in separate messages.\n\n## Explanation\nThe N3 source models an RDF Message Log as an ordered sequence of RDF Messages. Each non-empty message has a formula-valued payload that is inspected with log:includes, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, %s and %s, are different observations from the same stream but are contextualized by their message boundaries." ?Count ?Label ?FirstResult ?SecondResult) string:format ?Block.
+  ("# rdf-messages\n\n## Source files\n\n- [N3 rules](../rdf-messages.n3)\n- [Input TriG](../input/rdf-messages.trig)\n\n## Answer\nRDF Message log accepted: %d explicit message boundaries are preserved. Message :m002 is an empty heartbeat, and the local blank-node label %s is safely reused in separate messages.\n\n## Explanation\nThe N3 source models an RDF Message Log as an ordered sequence of RDF Messages. Each non-empty message has a formula-valued payload that is inspected with log:includes, so the observation data stays inside the message boundary instead of being treated as one global graph. The two temperature results, %s and %s, are different observations from the same stream but are contextualized by their message boundaries." ?Count ?Label ?FirstResult ?SecondResult) string:format ?Block.
 } => {
   :rdfMessagesExample log:outputString ?Block.
   :rdfMessagesExample :demonstrates :ExplicitBoundaries, :AtomicMessageContext, :EmptyHeartbeat, :MessageScopedBlankNodes, :ReplayableMessageLog.

package/examples/resto.n3

@@ -22,7 +22,7 @@
 @prefix string: <http://www.w3.org/2000/10/swap/string#>.
 @prefix log: <http://www.w3.org/2000/10/swap/log#>.
 
-:000_md_title log:outputString "# resto\n\n" .
+:000_md_title log:outputString "# resto\n\n## Source files\n\n- [N3 rules](../resto.n3)\n\n" .
 
 # ----------------
 # Initial question
@@ -290,15 +290,15 @@
   :Check :c8 ?C8.
   (
     "RESTdesc — Restaurant finder\n\n"
-    "Answer\n"
+    "## Answer\n"
     ?Outcome "\n"
     "Restaurant: " ?RestaurantName "\n"
     "Date: " ?Date "\n"
     "Seating: " ?Seating "\n\n"
-    "Reason Why\n"
+    "## Reason Why\n"
     "The plan resolved the person's address, turned it into a map point, checked the local weather, selected a suitable restaurant, and then created a reservation. "
     "Because the weather came back mild and stable (22 C and 1016 mbar), the chosen seating stayed outdoors.\n\n"
-    "Check\n"
+    "## Check\n"
     "C1 " ?C1 "\n"
     "C2 " ?C2 "\n"
     "C3 " ?C3 "\n"

package/examples/school-placement-audit.n3

@@ -42,7 +42,7 @@
 
 {
   :Audit :result ?Result; :affectedChildren ?Affected; :largestHiddenDetour ?Detour; :recommendedAssignments ?Assignments.
-  ("# school-placement-audit\n\n## Answer\naudit result : %s\nchildren affected by straight-line rule : %s\nlargest hidden detour : %s\nrecommended assignments : %s\nexplanation requested : yes\n\n## Explanation\nThe support-tool rule chooses the school with the smallest straight-line distance, using preference rank only as a tie-breaker. The independent audit recomputes each candidate with walking-route distance plus 600 m per preference step. Any provisional assignment that is not the audited best, or that requires more than 2500 m of walking, is flagged. Ada and Björn look close to Centrum on a map, but their walking routes cross barriers and exceed the walking limit; Davi is also better served by the first-preference Haga route. This illustrates why a decision-support label is not enough: route geometry, preferences, and audit records must be inspectable." ?Result ?Affected ?Detour ?Assignments) string:format ?Block.
+  ("# school-placement-audit\n\n## Source files\n\n- [N3 rules](../school-placement-audit.n3)\n- [Input TriG](../input/school-placement-audit.trig)\n\n## Answer\naudit result : %s\nchildren affected by straight-line rule : %s\nlargest hidden detour : %s\nrecommended assignments : %s\nexplanation requested : yes\n\n## Explanation\nThe support-tool rule chooses the school with the smallest straight-line distance, using preference rank only as a tie-breaker. The independent audit recomputes each candidate with walking-route distance plus 600 m per preference step. Any provisional assignment that is not the audited best, or that requires more than 2500 m of walking, is flagged. Ada and Björn look close to Centrum on a map, but their walking routes cross barriers and exceed the walking limit; Davi is also better served by the first-preference Haga route. This illustrates why a decision-support label is not enough: route geometry, preferences, and audit records must be inspectable." ?Result ?Affected ?Detour ?Assignments) string:format ?Block.
 } => {
   :schoolPlacementAudit log:outputString ?Block.
   :schoolPlacementAudit :reports :Audit.

package/examples/smoke-arithmetic.n3

@@ -16,5 +16,5 @@
 } .
 
 { :Case :product ?Product.
-  ("# smoke-arithmetic\n\n## Answer\nproduct = %s\n\n## Explanation\nThe compiled rule multiplies :x and :y using math:product." ?Product) string:format ?Block.
+  ("# smoke-arithmetic\n\n## Source files\n\n- [N3 rules](../smoke-arithmetic.n3)\n- [Input TriG](../input/smoke-arithmetic.trig)\n\n## Answer\nproduct = %s\n\n## Explanation\nThe compiled rule multiplies :x and :y using math:product." ?Product) string:format ?Block.
 } => { :out01 log:outputString ?Block. } .

package/examples/sqrt2-cauchy.n3

@@ -13,7 +13,7 @@
 @prefix log:   <http://www.w3.org/2000/10/swap/log#>.
 @prefix string:<http://www.w3.org/2000/10/swap/string#>.
 
-:000_md_title log:outputString "# sqrt2-cauchy\n\n" .
+:000_md_title log:outputString "# sqrt2-cauchy\n\n## Source files\n\n- [N3 rules](../sqrt2-cauchy.n3)\n\n" .
 
 :sqrt2Real a :Real;
   :representedBy :sqrt2Seq.

package/examples/sqrt2-dedekind.n3

@@ -9,7 +9,7 @@
 @prefix log:    <http://www.w3.org/2000/10/swap/log#>.
 @prefix string: <http://www.w3.org/2000/10/swap/string#>.
 
-:000_md_title log:outputString "# sqrt2-dedekind\n\n" .
+:000_md_title log:outputString "# sqrt2-dedekind\n\n## Source files\n\n- [N3 rules](../sqrt2-dedekind.n3)\n\n" .
 
 # -----------------------------------------------------------------
 # Data: a finite sample of rationals (decimal tokens are rationals)