eyeling 1.24.8 → 1.24.10

package/examples/ontology-question-generation.n3

@@ -0,0 +1,409 @@
+# Question generation from ontological patterns
+#
+# Run:
+#   npx eyeling -r examples/ontology-question-generation.n3 examples/input/ontology-question-generation.trig
+#
+# The input TriG file contains the ontology. These N3 rules detect common
+# OWL/RDFS modeling patterns, derive structured q:CompetencyQuestion nodes,
+# and render a Markdown report with log:outputString.
+
+@prefix :      <https://eyereasoner.github.io/eyeling/examples/ontology-question-generation#>.
+@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix owl:   <http://www.w3.org/2002/07/owl#>.
+@prefix log:   <http://www.w3.org/2000/10/swap/log#>.
+@prefix string:<http://www.w3.org/2000/10/swap/string#>.
+
+@prefix q:     <http://example.org/question#>.
+@prefix pat:   <http://example.org/question/pattern#>.
+
+#################################################################
+# Markdown frame
+#################################################################
+
+<urn:eyeling:oqg:000:title>
+    log:outputString "# ontology-question-generation\n\n".
+
+<urn:eyeling:oqg:010:intro>
+    log:outputString "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`.\n\n".
+
+<urn:eyeling:oqg:015:sources>
+    log:outputString "## Source files\n\n- [N3 rules](../ontology-question-generation.n3)\n- [Input ontology TriG](../input/ontology-question-generation.trig)\n\n".
+
+<urn:eyeling:oqg:020:patterns>
+    log:outputString "## Detected competency questions\n\n".
+
+<urn:eyeling:oqg:900:shape-title>
+    log:outputString "\n## RDF shape behind the Markdown\n\n".
+
+<urn:eyeling:oqg:910:shape-body>
+    log:outputString "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.\n".
+
+#################################################################
+# Helper classifications
+#################################################################
+
+{ ?class a owl:Class. }
+=>
+{ ?class q:isOntologicalClass true. }.
+
+{ ?class a rdfs:Class. }
+=>
+{ ?class q:isOntologicalClass true. }.
+
+{ ?property a owl:ObjectProperty. }
+=>
+{ ?property q:isObjectProperty true. }.
+
+{ ?property a owl:DatatypeProperty. }
+=>
+{ ?property q:isDatatypeProperty true. }.
+
+{ ?property rdfs:domain ?domain. ?property rdfs:range ?range. ?range q:isOntologicalClass true. }
+=>
+{ ?property q:isObjectProperty true. }.
+
+{ ?property rdfs:domain ?domain. ?property rdfs:range ?datatype. ?datatype a rdfs:Datatype. }
+=>
+{ ?property q:isDatatypeProperty true. }.
+
+#################################################################
+# 1. Class population pattern
+#################################################################
+
+{ ?class q:isOntologicalClass true. ?class rdfs:label ?classLabel. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:ClassPopulationQuestion;
+        q:aboutClass ?class;
+        q:questionTemplate "Which things are instances of {class}?";
+        q:slot [ q:slotName "class"; q:slotValue ?class; q:slotLabel ?classLabel ];
+        q:expectedAnswerShape pat:SetOfIndividuals;
+        q:priority 3
+    ].
+}.
+
+{
+    ?class q:isOntologicalClass true.
+    ?class rdfs:label ?classLabel.
+    ?class log:uri ?classIri.
+    ("urn:eyeling:oqg:100:class:%s" ?classIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Class population** — Which things are instances of `%s`?\n" ?classLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 2. Subclass distinction pattern
+#################################################################
+
+{ ?subClass rdfs:subClassOf ?superClass. ?subClass q:isOntologicalClass true. ?superClass q:isOntologicalClass true. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:SubclassDistinctionQuestion;
+        q:sourcePattern rdfs:subClassOf;
+        q:aboutClass ?subClass;
+        q:questionTemplate "What distinguishes a {subClass} from a general {superClass}?";
+        q:slot [ q:slotName "subClass"; q:slotValue ?subClass ];
+        q:slot [ q:slotName "superClass"; q:slotValue ?superClass ];
+        q:expectedAnswerShape pat:DefinitionOrConstraint;
+        q:priority 4
+    ].
+}.
+
+{
+    ?subClass rdfs:subClassOf ?superClass.
+    ?subClass q:isOntologicalClass true.
+    ?superClass q:isOntologicalClass true.
+    ?subClass rdfs:label ?subLabel.
+    ?superClass rdfs:label ?superLabel.
+    ?subClass log:uri ?subIri.
+    ?superClass log:uri ?superIri.
+    ("urn:eyeling:oqg:200:subclass:%s:%s" ?subIri ?superIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Subclass distinction** — What distinguishes `%s` from a general `%s`?\n" ?subLabel ?superLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 3. Object property domain/range pattern
+#################################################################
+
+{ ?property q:isObjectProperty true. ?property rdfs:domain ?domain. ?property rdfs:range ?range. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:ObjectPropertyQuestion;
+        q:sourcePattern pat:DomainRangePattern;
+        q:aboutProperty ?property;
+        q:questionTemplate "For a given {domain}, which {range} is related by {property}?";
+        q:slot [ q:slotName "domain"; q:slotValue ?domain ];
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:slot [ q:slotName "range"; q:slotValue ?range ];
+        q:expectedAnswerShape pat:SubjectPredicateObjectBindings;
+        q:priority 5
+    ].
+}.
+
+{
+    ?property q:isObjectProperty true.
+    ?property rdfs:domain ?domain.
+    ?property rdfs:range ?range.
+    ?property rdfs:label ?propertyLabel.
+    ?domain rdfs:label ?domainLabel.
+    ?range rdfs:label ?rangeLabel.
+    ?property log:uri ?propertyIri.
+    ("urn:eyeling:oqg:300:object-property:%s" ?propertyIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Object property** — For a given `%s`, which `%s` is related by `%s`?\n" ?domainLabel ?rangeLabel ?propertyLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 4. Datatype property pattern
+#################################################################
+
+{ ?property q:isDatatypeProperty true. ?property rdfs:domain ?domain. ?property rdfs:range ?datatype. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:DatatypePropertyQuestion;
+        q:sourcePattern pat:DomainDatatypeRangePattern;
+        q:aboutProperty ?property;
+        q:questionTemplate "What is the {property} value of a given {domain}?";
+        q:slot [ q:slotName "domain"; q:slotValue ?domain ];
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:slot [ q:slotName "datatype"; q:slotValue ?datatype ];
+        q:expectedAnswerShape pat:LiteralValue;
+        q:priority 5
+    ].
+}.
+
+{
+    ?property q:isDatatypeProperty true.
+    ?property rdfs:domain ?domain.
+    ?property rdfs:range ?datatype.
+    ?property rdfs:label ?propertyLabel.
+    ?domain rdfs:label ?domainLabel.
+    ?property log:uri ?propertyIri.
+    ("urn:eyeling:oqg:400:datatype-property:%s" ?propertyIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Datatype property** — What is the `%s` value of a given `%s`?\n" ?propertyLabel ?domainLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 5. Existential restriction pattern
+#################################################################
+
+{ ?class rdfs:subClassOf ?restriction. ?restriction a owl:Restriction. ?restriction owl:onProperty ?property. ?restriction owl:someValuesFrom ?filler. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:ExistentialRestrictionQuestion;
+        q:sourcePattern owl:someValuesFrom;
+        q:aboutClass ?class;
+        q:aboutProperty ?property;
+        q:questionTemplate "For each {class}, which {filler} must exist via {property}?";
+        q:slot [ q:slotName "class"; q:slotValue ?class ];
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:slot [ q:slotName "filler"; q:slotValue ?filler ];
+        q:expectedAnswerShape pat:RequiredExistentialWitness;
+        q:priority 8
+    ].
+}.
+
+{
+    ?class rdfs:subClassOf ?restriction.
+    ?restriction a owl:Restriction.
+    ?restriction owl:onProperty ?property.
+    ?restriction owl:someValuesFrom ?filler.
+    ?class rdfs:label ?classLabel.
+    ?property rdfs:label ?propertyLabel.
+    ?filler rdfs:label ?fillerLabel.
+    ?class log:uri ?classIri.
+    ?property log:uri ?propertyIri.
+    ?filler log:uri ?fillerIri.
+    ("urn:eyeling:oqg:500:some-values:%s:%s:%s" ?classIri ?propertyIri ?fillerIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Existential restriction** — For each `%s`, which `%s` must exist via `%s`?\n" ?classLabel ?fillerLabel ?propertyLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 6. Minimum cardinality pattern
+#################################################################
+
+{ ?class rdfs:subClassOf ?restriction. ?restriction a owl:Restriction. ?restriction owl:onProperty ?property. ?restriction owl:minCardinality ?n. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:MinimumCardinalityQuestion;
+        q:sourcePattern owl:minCardinality;
+        q:aboutClass ?class;
+        q:aboutProperty ?property;
+        q:questionTemplate "Does every {class} need at least {n} value(s) for {property}?";
+        q:slot [ q:slotName "class"; q:slotValue ?class ];
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:slot [ q:slotName "n"; q:slotValue ?n ];
+        q:expectedAnswerShape pat:MinimumCardinalityConstraint;
+        q:priority 8
+    ].
+}.
+
+{
+    ?class rdfs:subClassOf ?restriction.
+    ?restriction a owl:Restriction.
+    ?restriction owl:onProperty ?property.
+    ?restriction owl:minCardinality ?n.
+    ?class rdfs:label ?classLabel.
+    ?property rdfs:label ?propertyLabel.
+    ?class log:uri ?classIri.
+    ?property log:uri ?propertyIri.
+    ("urn:eyeling:oqg:600:min-cardinality:%s:%s:%s" ?classIri ?propertyIri ?n) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Minimum cardinality** — Does every `%s` need at least `%s` value for `%s`?\n" ?classLabel ?n ?propertyLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 7. Disjointness pattern
+#################################################################
+
+{ ?classA owl:disjointWith ?classB. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:DisjointnessQuestion;
+        q:sourcePattern owl:disjointWith;
+        q:questionTemplate "Can something ever be both a {classA} and a {classB}?";
+        q:slot [ q:slotName "classA"; q:slotValue ?classA ];
+        q:slot [ q:slotName "classB"; q:slotValue ?classB ];
+        q:expectedAnswerShape pat:BooleanOrExceptionList;
+        q:priority 6
+    ].
+}.
+
+{
+    ?classA owl:disjointWith ?classB.
+    ?classA rdfs:label ?labelA.
+    ?classB rdfs:label ?labelB.
+    ?classA log:uri ?iriA.
+    ?classB log:uri ?iriB.
+    ("urn:eyeling:oqg:700:disjoint:%s:%s" ?iriA ?iriB) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Disjointness** — Can something ever be both an `%s` and a `%s`?\n" ?labelA ?labelB) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 8. Functional property pattern
+#################################################################
+
+{ ?property a owl:FunctionalProperty. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:FunctionalPropertyQuestion;
+        q:sourcePattern owl:FunctionalProperty;
+        q:aboutProperty ?property;
+        q:questionTemplate "Can one subject have multiple values for {property}?";
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:expectedAnswerShape pat:BooleanOrConstraint;
+        q:priority 6
+    ].
+}.
+
+{
+    ?property a owl:FunctionalProperty.
+    ?property rdfs:label ?propertyLabel.
+    ?property log:uri ?propertyIri.
+    ("urn:eyeling:oqg:800:functional:%s" ?propertyIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Functional property** — Can one subject have multiple values for `%s`?\n" ?propertyLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 9. Inverse property pattern
+#################################################################
+
+{ ?property owl:inverseOf ?inverseProperty. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:InversePropertyQuestion;
+        q:sourcePattern owl:inverseOf;
+        q:aboutProperty ?property;
+        q:questionTemplate "If {x} has {property} {y}, should {y} have {inverseProperty} {x}?";
+        q:slot [ q:slotName "property"; q:slotValue ?property ];
+        q:slot [ q:slotName "inverseProperty"; q:slotValue ?inverseProperty ];
+        q:expectedAnswerShape pat:InverseRelationCheck;
+        q:priority 5
+    ].
+}.
+
+{
+    ?property owl:inverseOf ?inverseProperty.
+    ?property rdfs:label ?propertyLabel.
+    ?inverseProperty rdfs:label ?inverseLabel.
+    ?property log:uri ?propertyIri.
+    ?inverseProperty log:uri ?inverseIri.
+    ("urn:eyeling:oqg:810:inverse:%s:%s" ?propertyIri ?inverseIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Inverse property** — If `x` has `%s` `y`, should `y` have `%s` `x`?\n" ?propertyLabel ?inverseLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.
+
+#################################################################
+# 10. Property hierarchy pattern
+#################################################################
+
+{ ?subProperty rdfs:subPropertyOf ?superProperty. }
+=>
+{
+    [
+        a q:CompetencyQuestion;
+        q:pattern pat:SubpropertyQuestion;
+        q:sourcePattern rdfs:subPropertyOf;
+        q:aboutProperty ?subProperty;
+        q:questionTemplate "When {subProperty} holds, should {superProperty} also hold?";
+        q:slot [ q:slotName "subProperty"; q:slotValue ?subProperty ];
+        q:slot [ q:slotName "superProperty"; q:slotValue ?superProperty ];
+        q:expectedAnswerShape pat:BooleanOrRule;
+        q:priority 4
+    ].
+}.
+
+{
+    ?subProperty rdfs:subPropertyOf ?superProperty.
+    ?subProperty rdfs:label ?subLabel.
+    ?superProperty rdfs:label ?superLabel.
+    ?subProperty log:uri ?subIri.
+    ?superProperty log:uri ?superIri.
+    ("urn:eyeling:oqg:820:subproperty:%s:%s" ?subIri ?superIri) string:format ?key.
+    ?out log:uri ?key.
+    ("- **Subproperty** — When `%s` holds, should `%s` also hold?\n" ?subLabel ?superLabel) string:format ?line.
+}
+=>
+{ ?out log:outputString ?line. }.

package/examples/output/act-alarm-bit-interoperability.md

@@ -1,15 +1,19 @@
 # act-alarm-bit-interoperability  
 
+## Source files  
+
+- [N3 rules](../act-alarm-bit-interoperability.n3)  
+
 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/output/act-barley-seed-lineage.md

@@ -1,15 +1,19 @@
 # act-barley-seed-lineage  
 
+## Source files  
+
+- [N3 rules](../act-barley-seed-lineage.n3)  
+
 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/output/act-docking-abort.md

@@ -1,15 +1,19 @@
 # act-docking-abort  
 
+## Source files  
+
+- [N3 rules](../act-docking-abort.n3)  
+
 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/output/act-gravity-mediator-witness.md

@@ -1,15 +1,19 @@
 # act-gravity-mediator-witness  
 
+## Source files  
+
+- [N3 rules](../act-gravity-mediator-witness.n3)  
+
 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/output/act-isolation-breach.md

@@ -1,15 +1,19 @@
 # act-isolation-breach  
 
+## Source files  
+
+- [N3 rules](../act-isolation-breach.n3)  
+
 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/output/act-photosynthetic-exciton-transfer.md

@@ -1,15 +1,19 @@
 # act-photosynthetic-exciton-transfer  
 
+## Source files  
+
+- [N3 rules](../act-photosynthetic-exciton-transfer.n3)  
+
 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/output/act-sensor-memory-reset.md

@@ -1,15 +1,19 @@
 # act-sensor-memory-reset  
 
+## Source files  
+
+- [N3 rules](../act-sensor-memory-reset.n3)  
+
 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/output/act-tunnel-junction-wake-switch.md

@@ -1,15 +1,19 @@
 # act-tunnel-junction-wake-switch  
 
+## Source files  
+
+- [N3 rules](../act-tunnel-junction-wake-switch.n3)  
+
 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/output/act-yeast-self-reproduction.md

@@ -1,15 +1,19 @@
 # act-yeast-self-reproduction  
 
+## Source files  
+
+- [N3 rules](../act-yeast-self-reproduction.n3)  
+
 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/output/annotation.md

@@ -1 +1,21 @@
 # annotation  
+
+## Source files  
+
+- [N3 rules](../annotation.n3)  
+- [Input TriG](../input/annotation.trig)  
+
+RDF 1.2 annotation evidence is loaded from the TriG sidecar and represented as ordinary facts.  
+
+## Answer  
+YES — the annotated statement says `:a :name "Alice"` and gives that statement the identifier `:t`.  
+
+## Reason Why  
+The 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.  
+
+## Check  
+C1 OK - the statement `:a :name "Alice"` is present  
+C2 OK - `:t` names the annotated statement  
+C3 OK - the statement is attributed to `:bob`  
+C4 OK - the statement is recorded as `2021-07-07`  
+C5 OK - the RDF/TriG input sidecar is linked as source evidence