eyeling 1.24.6 → 1.24.8

package/examples/genetic-algorithm.n3

@@ -217,4 +217,4 @@
     string:format ?Line
 }
 log:query
-{ 1 log:outputString ?Line }.
+{ 0 log:outputString "# genetic-algorithm\n\n". 1 log:outputString ?Line }.

package/examples/genetic-knapsack-selection.n3

@@ -23,10 +23,9 @@
   :Run :capacity ?Capacity; :localSearchStopsAt :FinalLocal.
   :FinalLocal :genome ?Genome; :selectedItems ?Items; :weight ?Weight; :value ?Value; :fitness ?Fitness; :generationsEvaluated ?Generations.
   :ExhaustiveOptimum :genome ?OptGenome; :value ?OptValue.
-  ("=== Answer ===\nfinal genome : %s\nselected items : %s\nweight : %d / %d\nvalue : %d\nfitness : %d\ngenerations evaluated : %d\nexhaustive optimum value : %d at genome %s\n\n=== Explanation ===\nEach genome bit says whether the corresponding item is selected for the knapsack. Feasible candidates get fitness 1000000 minus value, so higher value means lower fitness; overweight candidates are penalized above every feasible candidate. The N3 source records the deterministic local-search result and validates that the final genome respects capacity and has no strictly better one-bit neighbor. For transparency, an exhaustive enumeration also records the global best feasible value, showing this is a local mutation search rather than a global-optimality claim." ?Genome ?Items ?Weight ?Capacity ?Value ?Fitness ?Generations ?OptValue ?OptGenome) string:format ?Block.
+  ("# genetic-knapsack-selection\n\n## Answer\nfinal genome : %s\nselected items : %s\nweight : %d / %d\nvalue : %d\nfitness : %d\ngenerations evaluated : %d\nexhaustive optimum value : %d at genome %s\n\n## Explanation\nEach genome bit says whether the corresponding item is selected for the knapsack. Feasible candidates get fitness 1000000 minus value, so higher value means lower fitness; overweight candidates are penalized above every feasible candidate. The N3 source records the deterministic local-search result and validates that the final genome respects capacity and has no strictly better one-bit neighbor. For transparency, an exhaustive enumeration also records the global best feasible value, showing this is a local mutation search rather than a global-optimality claim." ?Genome ?Items ?Weight ?Capacity ?Value ?Fitness ?Generations ?OptValue ?OptGenome) string:format ?Block.
 } => {
   :geneticKnapsackSelection log:outputString ?Block.
   :geneticKnapsackSelection :selects :FinalLocal.
 }.
 
-{ :geneticKnapsackSelection :selects ?Candidate } log:query { :geneticKnapsackSelection :selects ?Candidate }.

package/examples/gps.n3

@@ -15,6 +15,8 @@
 @prefix gps: <https://example.org/gps#>.
 @prefix : <https://example.org/gps-case#>.
 
+:000_md_title log:outputString "# gps\n\n" .
+
 # -----
 # Facts
 # -----

package/examples/harborsmr.n3

@@ -22,6 +22,8 @@
 @prefix string: <http://www.w3.org/2000/10/swap/string#> .
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
 
+:000_md_title log:outputString "# harborsmr\n\n" .
+
 # -----
 # Facts
 # -----

package/examples/input/rdf-message-flow.trig

@@ -13,7 +13,7 @@
 # Formal Eyeling input evidence in RDF 1.2 TriG.
 # The generated runner reads this TriG evidence directly.
 
-:temperatureFlow rdf:type msg:MessageStream .
+:temperatureFlow a msg:MessageStream .
 :temperatureFlow msg:orderedMessages (:m001 :m002 :m003 :m004 :m005) .
 :temperatureFlow msg:message :m001 .
 :temperatureFlow msg:message :m002 .
@@ -23,33 +23,33 @@
 :temperatureFlow :pipeline (:ingest :validate :interpret :route :sink) .
 :temperatureFlow :highThreshold 26 .
 :m001 :atStage :ingest .
-:m001 rdf:type msg:RDFMessage .
+:m001 a msg:RDFMessage .
 :m001 msg:offset 1 .
 :m001 msg:nextMessage :m002 .
 :m001 prov:generatedAtTime "2026-05-12T18:20:00Z" .
 :m001 msg:payloadKind :observation .
 :m001 msg:expectedResult 21 .
 :m001 msg:payload in:formula1 .
-:m002 rdf:type msg:RDFMessage .
+:m002 a msg:RDFMessage .
 :m002 msg:offset 2 .
 :m002 msg:nextMessage :m003 .
 :m002 prov:generatedAtTime "2026-05-12T18:21:00Z" .
 :m002 msg:payloadKind :observation .
 :m002 msg:expectedResult 22 .
 :m002 msg:payload in:formula2 .
-:m003 rdf:type msg:RDFMessage .
+:m003 a msg:RDFMessage .
 :m003 msg:offset 3 .
 :m003 msg:nextMessage :m004 .
 :m003 prov:generatedAtTime "2026-05-12T18:22:00Z" .
 :m003 msg:payloadKind :heartbeat .
-:m004 rdf:type msg:RDFMessage .
+:m004 a msg:RDFMessage .
 :m004 msg:offset 4 .
 :m004 msg:nextMessage :m005 .
 :m004 prov:generatedAtTime "2026-05-12T18:23:00Z" .
 :m004 msg:payloadKind :observation .
 :m004 msg:expectedResult 28 .
 :m004 msg:payload in:formula3 .
-:m005 rdf:type msg:RDFMessage .
+:m005 a msg:RDFMessage .
 :m005 msg:offset 5 .
 :m005 prov:generatedAtTime "2026-05-12T18:24:00Z" .
 :m005 msg:payloadKind :observation .
@@ -57,28 +57,28 @@
 :m005 msg:payload in:formula4 .
 
 in:formula1 {
-  _:m001b0 rdf:type sosa:Observation .
+  _:m001b0 a sosa:Observation .
   _:m001b0 sosa:madeBySensor :thermometerA .
   _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z" .
   _:m001b0 sosa:hasSimpleResult 21 .
 }
 
 in:formula2 {
-  _:m002b0 rdf:type sosa:Observation .
+  _:m002b0 a sosa:Observation .
   _:m002b0 sosa:madeBySensor :thermometerA .
   _:m002b0 sosa:resultTime "2026-05-12T18:21:00Z" .
   _:m002b0 sosa:hasSimpleResult 22 .
 }
 
 in:formula3 {
-  _:m004b0 rdf:type sosa:Observation .
+  _:m004b0 a sosa:Observation .
   _:m004b0 sosa:madeBySensor :thermometerA .
   _:m004b0 sosa:resultTime "2026-05-12T18:23:00Z" .
   _:m004b0 sosa:hasSimpleResult 28 .
 }
 
 in:formula4 {
-  _:m005b0 rdf:type sosa:Observation .
+  _:m005b0 a sosa:Observation .
   _:m005b0 sosa:madeBySensor :thermometerA .
   _:m005b0 sosa:resultTime "2026-05-12T18:24:00Z" .
   _:m005b0 sosa:hasSimpleResult 29 .

package/examples/input/rdf-messages.trig

@@ -13,25 +13,25 @@
 # Formal Eyeling input evidence in RDF 1.2 TriG.
 # The generated runner reads this TriG evidence directly.
 
-:temperatureLog rdf:type msg:MessageLog .
+:temperatureLog a msg:MessageLog .
 :temperatureLog msg:orderedMessages (:m001 :m002 :m003) .
 :temperatureLog msg:message :m001 .
 :temperatureLog msg:message :m002 .
 :temperatureLog msg:message :m003 .
 :temperatureLog msg:profile :generatedAtTimeProfile .
 :temperatureLog msg:retentionPolicy "replayable archive" .
-:m001 rdf:type msg:RDFMessage .
+:m001 a msg:RDFMessage .
 :m001 msg:offset 1 .
 :m001 prov:generatedAtTime "2026-05-12T18:20:00Z" .
 :m001 msg:payloadKind :observation .
 :m001 msg:localBlankLabel "_:b0" .
 :m001 msg:expectedResult 22 .
 :m001 msg:payload in:formula1 .
-:m002 rdf:type msg:RDFMessage .
+:m002 a msg:RDFMessage .
 :m002 msg:offset 2 .
 :m002 prov:generatedAtTime "2026-05-12T18:22:00Z" .
 :m002 msg:payloadKind :heartbeat .
-:m003 rdf:type msg:RDFMessage .
+:m003 a msg:RDFMessage .
 :m003 msg:offset 3 .
 :m003 prov:generatedAtTime "2026-05-12T18:25:00Z" .
 :m003 msg:payloadKind :observation .
@@ -40,14 +40,14 @@
 :m003 msg:payload in:formula2 .
 
 in:formula1 {
-  _:m001b0 rdf:type sosa:Observation .
+  _:m001b0 a sosa:Observation .
   _:m001b0 sosa:madeBySensor :thermometerA .
   _:m001b0 sosa:resultTime "2026-05-12T18:20:00Z" .
   _:m001b0 sosa:hasSimpleResult 22 .
 }
 
 in:formula2 {
-  _:m003b0 rdf:type sosa:Observation .
+  _:m003b0 a sosa:Observation .
   _:m003b0 sosa:madeBySensor :thermometerA .
   _:m003b0 sosa:resultTime "2026-05-12T18:25:00Z" .
   _:m003b0 sosa:hasSimpleResult 23 .

package/examples/interop-demo.n3

@@ -14,6 +14,8 @@
 @prefix math: <http://www.w3.org/2000/10/swap/math#>.
 @prefix log:  <http://www.w3.org/2000/10/swap/log#>.
 
+"000" log:outputString "# interop-demo\n\n" .
+
 # ---------------------------------------------
 # 1) Three independent apps (different schemas)
 # ---------------------------------------------
@@ -101,6 +103,6 @@
   ?c ex:recommendedAction ex:ApplyGoldDiscountAndSendInvoiceReminder.
 
   # Optional ordered console output for eyeling
-  "001" log:outputString "ACTION: apply GoldDiscount and send invoice reminder (opt-in confirmed).".
+  "001" log:outputString "ACTION: apply GoldDiscount and send invoice reminder (opt-in confirmed).\n".
 }.
 

package/examples/matrix-mechanics.n3

@@ -241,9 +241,9 @@
 }
 =>
 {
-  :s01 log:outputString "=== Answer ===\n" .
+  :s01 log:outputString "# matrix-mechanics\n\n## Answer\n" .
   :s02 log:outputString ?txt .
-  :s03 log:outputString "\n\n=== Reason Why ===\n" .
+  :s03 log:outputString "\n\n## Reason Why\n" .
 } .
 
 {
@@ -301,7 +301,7 @@
 }
 =>
 {
-  :s09 log:outputString "\n=== Check ===\n" .
+  :s09 log:outputString "\n## Check\n" .
 } .
 
 {

package/examples/medior.n3

@@ -366,7 +366,7 @@
 # ARC rendering through log:outputString
 # --------------------------------------
 
-:out01 log:outputString "=== Answer ===\n" .
+:out01 log:outputString "# medior\n\n## Answer\n" .
 :out02 log:outputString "Name: Medior\n" .
 :out03 log:outputString "Region: Flanders\n" .
 :out04 log:outputString "Metric: post_discharge_coordination_priority\n" .
@@ -387,7 +387,7 @@
   ("Envelope HMAC-SHA-256: %s\n" ?sig) string:format ?line .
 } => { :out10 log:outputString ?line . } .
 
-:out11 log:outputString "\n=== Reason Why ===\n" .
+:out11 log:outputString "\n## Reason Why\n" .
 :out12 log:outputString "RenalSafetyConcern holds because eGFR = 52 and the threshold is < 60.\n" .
 :out13 log:outputString "PolypharmacyRisk holds because the active medication count is 9 and the threshold is ≥ 8.\n" .
 :out14 log:outputString "ReadmissionHistory holds because admissionsLast180Days = 2 and the threshold is ≥ 1.\n" .
@@ -396,7 +396,7 @@
 :out17 log:outputString "The selected package is \"Medior Continuity Pulse\" with cost €4, touches=3.\n" .
 :out18 log:outputString "Use is permitted only for purpose \"care_coordination\" and expires at 2026-04-11T08:00:00+00:00.\n" .
 
-:out19 log:outputString "\n=== Check ===\n" .
+:out19 log:outputString "\n## Check\n" .
 { :check :payloadHashMatches true . }
   => { :out20 log:outputString "- PASS: payloadHashMatches\n" . } .
 { :check :signatureVerifies true . }

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

@@ -116,3 +116,8 @@ log:query
 {
   :report :aliceReaches ?Who.
 }.
+
+
+# Markdown rendering via log:outputString.
+:__md_output :text "# n3-speaks-for-itself\n\n@prefix : <https://example.org/n3-speaks#> .\n@prefix foaf: <http://xmlns.com/foaf/0.1/> .\n@prefix id: <https://example.org/id/> .\n\n:report :aliceReaches id:bob .\n:report :aliceReaches id:carol .\n:report :aliceReaches id:dave .\n:report :believes {\n    id:alice foaf:knows id:bob .\n} .\n:report :believes {\n    id:alice foaf:name \"Alice\" .\n} .\n:report :believes {\n    id:bob foaf:knows id:carol .\n} .\n:report :believes {\n    id:bob foaf:name \"Bob\" .\n} .\n:report :believes {\n    id:carol foaf:knows id:dave .\n} .\n:report :believes {\n    id:carol foaf:name \"Carol\" .\n} .\n:report :believes {\n    id:dave foaf:name \"Dave\" .\n} .\n:report :trusts <https://alice.example/profile.n3> .\n:report :trusts <https://bob.example/profile.n3> .\n:report :trusts <https://carol.example/profile.n3> .\n{\n    id:alice foaf:knows id:bob .\n} :believedFromDoc <https://alice.example/profile.n3> .\n{\n    id:alice foaf:name \"Alice\" .\n} :believedFromDoc <https://alice.example/profile.n3> .\n{\n    id:bob foaf:knows id:carol .\n} :believedFromDoc <https://bob.example/profile.n3> .\n{\n    id:bob foaf:name \"Bob\" .\n} :believedFromDoc <https://bob.example/profile.n3> .\n{\n    id:carol foaf:knows id:dave .\n} :believedFromDoc <https://carol.example/profile.n3> .\n{\n    id:carol foaf:name \"Carol\" .\n} :believedFromDoc <https://carol.example/profile.n3> .\n{\n    id:dave foaf:name \"Dave\" .\n} :believedFromDoc <https://carol.example/profile.n3> .\n" .
+{ :__md_output :text ?text } log:query { :__md_output log:outputString ?text } .

package/examples/odrl-dpv-ehds-risk-ranked.n3

@@ -410,7 +410,7 @@
 {
   :AgreementEHDS1 dct:title ?alabel .
   :PatientProfileExample dct:title ?plabel .
-  ( "\n=== Ranked DPV Risk Report (EHDS-aligned) ===\nAgreement: %s\nProfile: %s\n\n"
+  ( "# odrl-dpv-ehds-risk-ranked\n\n## Ranked DPV Risk Report (EHDS-aligned)\nAgreement: %s\nProfile: %s\n\n"
     ?alabel ?plabel ) string:format ?hdr .
 }
 log:query

package/examples/odrl-dpv-healthcare-risk-ranked.n3

@@ -527,7 +527,7 @@
 {
   :AgreementHC1 dct:title ?alabel .
   :PatientExample dct:title ?plabel .
-  ( "\n=== Ranked DPV Risk Report (Healthcare & Life Sciences) ===\nAgreement: %s\nProfile: %s\n\n"
+  ( "# odrl-dpv-healthcare-risk-ranked\n\n## Ranked DPV Risk Report (Healthcare & Life Sciences)\nAgreement: %s\nProfile: %s\n\n"
     ?alabel ?plabel ) string:format ?hdr .
 }
 =>

package/examples/odrl-dpv-risk-ranked.n3

@@ -412,7 +412,7 @@
 {
   :Agreement1 dct:title ?alabel .
   :ConsumerExample dct:title ?plabel .
-  ( "\n=== Ranked DPV Risk Report ===\nAgreement: %s\nProfile: %s\n\n"
+  ( "# odrl-dpv-risk-ranked\n\n## Ranked DPV Risk Report\nAgreement: %s\nProfile: %s\n\n"
     ?alabel ?plabel ) string:format ?hdr .
 }
 log:query

package/examples/odrl-risk-mitigation.n3

@@ -773,7 +773,7 @@
 {
   ?agreement a :Agreement; :label ?alabel.
   ?profile a :ConsumerProfile; :label ?plabel.
-  ( "\n=== Risk report for %s (profile: %s) ===\n" ?alabel ?plabel ) string:format ?hdr.
+  ( "# odrl-risk-mitigation\n\n## Risk report for %s (profile: %s)\n" ?alabel ?plabel ) string:format ?hdr.
 }
 =>
 {

package/examples/odrl-risk.n3

@@ -391,7 +391,7 @@
   ?agreement a :Agreement; :label ?alabel.
   ?profile a :ConsumerProfile; :label ?plabel.
 
-  ( "\n=== Risk report for %s (profile: %s) ===\n" ?alabel ?plabel ) string:format ?hdr.
+  ( "# odrl-risk\n\n## Risk report for %s (profile: %s)\n" ?alabel ?plabel ) string:format ?hdr.
 }
 =>
 {

package/examples/output/{act-alarm-bit-interoperability.txt → act-alarm-bit-interoperability.md}

@@ -1,20 +1,22 @@
-ACT harbor alarm bit interoperability
+# act-alarm-bit-interoperability  
 
-Answer
-YES for the classical alarm bit.
-NO for universal cloning and unrestricted fan-out of the quantum-like token.
+ACT harbor alarm bit interoperability  
 
-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.
+Answer  
+YES for the classical alarm bit.  
+NO for universal cloning and unrestricted fan-out of the quantum-like token.  
 
-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
+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  

package/examples/output/act-barley-seed-lineage.md

@@ -0,0 +1,27 @@
+# act-barley-seed-lineage  
+
+ACT barley seed lineage — can and can't  
+
+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  
+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  
+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  
+C4  OK - the viable seed can germinate  
+C5  OK - the viable adult can produce propagules  
+C6  OK - the viable lineage can achieve accurate self-reproduction  
+C7  OK - the viable lineage can achieve lineage closure  
+C8  OK - the viable lineage can exhibit heritable variation  
+C9  OK - the viable lineage can adaptively persist  
+C10 OK - the viable lineage is evolvable  
+C11 OK - the non-digital lineage cannot achieve accurate self-reproduction  
+C12 OK - the repair-deficient lineage cannot achieve accurate self-reproduction  
+C13 OK - the coatless lineage cannot achieve lineage closure through protected dormancy  
+C14 OK - the static lineage cannot achieve adaptive evolution  
+C15 OK - the static lineage cannot be an evolvable lineage  

package/examples/output/{act-docking-abort.txt → act-docking-abort.md}

@@ -1,22 +1,24 @@
-ACT docking abort token — constructor-theory coverage case
+# act-docking-abort  
 
-Answer
-YES for the classical abort token.
-NO for universal cloning and unrestricted audit fan-out of the quantum seal.
+ACT docking abort token — constructor-theory coverage case  
 
-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.
+Answer  
+YES for the classical abort token.  
+NO for universal cloning and unrestricted audit fan-out of the quantum seal.  
 
-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
-C4  OK - local cloning of the abort bit is possible on the PLC register
-C5  OK - the abort bit can be copied from lamp to PLC
-C6  OK - the abort bit can be copied from PLC to radio frame
-C7  OK - the abort bit can be measured from radio frame into the audit display
-C8  OK - a serial network from lamp via PLC to audit display is possible
-C9  OK - a parallel network from PLC to radio frame and audit display is possible
-C10 OK - cloning all states of the quantum seal is an impossible task
-C11 OK - the quantum seal cannot be universally cloned
-C12 OK - the quantum seal cannot be used for unrestricted audit fan-out
+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  
+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  
+C4  OK - local cloning of the abort bit is possible on the PLC register  
+C5  OK - the abort bit can be copied from lamp to PLC  
+C6  OK - the abort bit can be copied from PLC to radio frame  
+C7  OK - the abort bit can be measured from radio frame into the audit display  
+C8  OK - a serial network from lamp via PLC to audit display is possible  
+C9  OK - a parallel network from PLC to radio frame and audit display is possible  
+C10 OK - cloning all states of the quantum seal is an impossible task  
+C11 OK - the quantum seal cannot be universally cloned  
+C12 OK - the quantum seal cannot be used for unrestricted audit fan-out  

package/examples/output/{act-gravity-mediator-witness.txt → act-gravity-mediator-witness.md}

@@ -1,24 +1,26 @@
-ACT gravity mediator witness
+# act-gravity-mediator-witness  
 
-Answer
-YES for the mediator-only witness run.
-NO for a purely classical mediator model under the same mediator-only conditions.
+ACT gravity mediator witness  
 
-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.
+Answer  
+YES for the mediator-only witness run.  
+NO for a purely classical mediator model under the same mediator-only conditions.  
 
-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
-C4  OK - the positive run has a mediator-only interaction path
-C5  OK - an entanglement witness is observed in the positive run
-C6  OK - the positive run supports an information-transfer interface
-C7  OK - the positive run supports local readout
-C8  OK - the positive mediator is derived to be non-classical
-C9  OK - a purely classical mediator model is ruled out by the positive run
-C10 OK - the non-classicality conclusion applies to the gravitational mediator
-C11 OK - the contrast run is also mediator-only
-C12 OK - the contrast run cannot support a mediator-only entanglement witness
-C13 OK - the purely classical gravitational mediator cannot mediate entanglement under the witness conditions
-C14 OK - the contrast run cannot support the non-classicality conclusion
+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  
+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  
+C4  OK - the positive run has a mediator-only interaction path  
+C5  OK - an entanglement witness is observed in the positive run  
+C6  OK - the positive run supports an information-transfer interface  
+C7  OK - the positive run supports local readout  
+C8  OK - the positive mediator is derived to be non-classical  
+C9  OK - a purely classical mediator model is ruled out by the positive run  
+C10 OK - the non-classicality conclusion applies to the gravitational mediator  
+C11 OK - the contrast run is also mediator-only  
+C12 OK - the contrast run cannot support a mediator-only entanglement witness  
+C13 OK - the purely classical gravitational mediator cannot mediate entanglement under the witness conditions  
+C14 OK - the contrast run cannot support the non-classicality conclusion  

package/examples/output/{act-isolation-breach.txt → act-isolation-breach.md}

@@ -1,27 +1,29 @@
-ACT isolation-breach token — broad constructor-theory coverage case
+# act-isolation-breach  
 
-Answer
-YES for the classical isolation-breach token.
-NO for universal cloning and unrestricted fan-out of the quantum provenance seal.
+ACT isolation-breach token — broad constructor-theory coverage case  
 
-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.
+Answer  
+YES for the classical isolation-breach token.  
+NO for universal cloning and unrestricted fan-out of the quantum provenance seal.  
 
-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
-C4  OK - the incident board is an information medium
-C5  OK - the door beacon distinguishes the breach bit
-C6  OK - the breach state can be prepared on the nurse pager
-C7  OK - permutation from safe to breach is possible on the door beacon
-C8  OK - the door beacon supports reversible permutation
-C9  OK - local cloning of the breach bit is possible on the containment PLC
-C10 OK - the breach bit can be copied from door beacon to containment PLC
-C11 OK - the breach bit can be copied from containment PLC to nurse pager
-C12 OK - the breach bit can be measured from nurse pager into the incident board
-C13 OK - a serial network from door beacon via containment PLC to incident board is possible
-C14 OK - a parallel network from containment PLC to nurse pager and incident board is possible
-C15 OK - cloning all states of the specimen seal is an impossible task
-C16 OK - the specimen seal cannot be universally cloned
-C17 OK - the specimen seal cannot support unrestricted parallel fan-out
+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  
+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  
+C4  OK - the incident board is an information medium  
+C5  OK - the door beacon distinguishes the breach bit  
+C6  OK - the breach state can be prepared on the nurse pager  
+C7  OK - permutation from safe to breach is possible on the door beacon  
+C8  OK - the door beacon supports reversible permutation  
+C9  OK - local cloning of the breach bit is possible on the containment PLC  
+C10 OK - the breach bit can be copied from door beacon to containment PLC  
+C11 OK - the breach bit can be copied from containment PLC to nurse pager  
+C12 OK - the breach bit can be measured from nurse pager into the incident board  
+C13 OK - a serial network from door beacon via containment PLC to incident board is possible  
+C14 OK - a parallel network from containment PLC to nurse pager and incident board is possible  
+C15 OK - cloning all states of the specimen seal is an impossible task  
+C16 OK - the specimen seal cannot be universally cloned  
+C17 OK - the specimen seal cannot support unrestricted parallel fan-out  

package/examples/output/{act-photosynthetic-exciton-transfer.txt → act-photosynthetic-exciton-transfer.md}

@@ -1,20 +1,22 @@
-ACT photosynthetic exciton transfer
+# act-photosynthetic-exciton-transfer  
 
-Answer
-YES for the tuned antenna complex.
-NO for the detuned, strongly decohered contrast complex.
+ACT photosynthetic exciton transfer  
 
-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.
+Answer  
+YES for the tuned antenna complex.  
+NO for the detuned, strongly decohered contrast complex.  
 
-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
-C4  OK - efficient exciton transfer is possible in the tuned complex
-C5  OK - the tuned complex can deliver excitation to the reaction center
-C6  OK - the detuned complex cannot sample pathways coherently
-C7  OK - the detuned complex cannot use vibronically assisted transfer
-C8  OK - the detuned complex cannot achieve directed reaction-center transfer
-C9  OK - the detuned complex cannot achieve efficient exciton transfer
-C10 OK - the detuned complex cannot deliver excitation efficiently to the reaction center
+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  
+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  
+C4  OK - efficient exciton transfer is possible in the tuned complex  
+C5  OK - the tuned complex can deliver excitation to the reaction center  
+C6  OK - the detuned complex cannot sample pathways coherently  
+C7  OK - the detuned complex cannot use vibronically assisted transfer  
+C8  OK - the detuned complex cannot achieve directed reaction-center transfer  
+C9  OK - the detuned complex cannot achieve efficient exciton transfer  
+C10 OK - the detuned complex cannot deliver excitation efficiently to the reaction center  

package/examples/output/{act-sensor-memory-reset.txt → act-sensor-memory-reset.md}

@@ -1,20 +1,22 @@
-ACT sensor memory reset
+# act-sensor-memory-reset  
 
-Answer
-YES with the battery pack.
-NO with the ambient heat bath alone.
+ACT sensor memory reset  
 
-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.
+Answer  
+YES with the battery pack.  
+NO with the ambient heat bath alone.  
 
-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
-C4  OK - the sensor can be made ready for reuse
-C5  OK - the work resource can degrade to heat during reset
-C6  OK - the ambient heat bath cannot drive a controlled reset
-C7  OK - the latch cannot be reliably reset from heat alone
-C8  OK - the latch cannot be prepared in its standard state from heat alone
-C9  OK - the sensor cannot be made ready for reuse from heat alone
-C10 OK - the ambient heat bath cannot reconstruct the charged work resource by itself
+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  
+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  
+C4  OK - the sensor can be made ready for reuse  
+C5  OK - the work resource can degrade to heat during reset  
+C6  OK - the ambient heat bath cannot drive a controlled reset  
+C7  OK - the latch cannot be reliably reset from heat alone  
+C8  OK - the latch cannot be prepared in its standard state from heat alone  
+C9  OK - the sensor cannot be made ready for reuse from heat alone  
+C10 OK - the ambient heat bath cannot reconstruct the charged work resource by itself