eyeling 1.24.7 → 1.24.9

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

@@ -0,0 +1,58 @@
+# 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/> .  
+
+:report :aliceReaches id:bob .  
+:report :aliceReaches id:carol .  
+:report :aliceReaches id:dave .  
+:report :believes {  
+    id:alice foaf:knows id:bob .  
+} .  
+:report :believes {  
+    id:alice foaf:name "Alice" .  
+} .  
+:report :believes {  
+    id:bob foaf:knows id:carol .  
+} .  
+:report :believes {  
+    id:bob foaf:name "Bob" .  
+} .  
+:report :believes {  
+    id:carol foaf:knows id:dave .  
+} .  
+:report :believes {  
+    id:carol foaf:name "Carol" .  
+} .  
+:report :believes {  
+    id:dave foaf:name "Dave" .  
+} .  
+:report :trusts <https://alice.example/profile.n3> .  
+:report :trusts <https://bob.example/profile.n3> .  
+:report :trusts <https://carol.example/profile.n3> .  
+{  
+    id:alice foaf:knows id:bob .  
+} :believedFromDoc <https://alice.example/profile.n3> .  
+{  
+    id:alice foaf:name "Alice" .  
+} :believedFromDoc <https://alice.example/profile.n3> .  
+{  
+    id:bob foaf:knows id:carol .  
+} :believedFromDoc <https://bob.example/profile.n3> .  
+{  
+    id:bob foaf:name "Bob" .  
+} :believedFromDoc <https://bob.example/profile.n3> .  
+{  
+    id:carol foaf:knows id:dave .  
+} :believedFromDoc <https://carol.example/profile.n3> .  
+{  
+    id:carol foaf:name "Carol" .  
+} :believedFromDoc <https://carol.example/profile.n3> .  
+{  
+    id:dave foaf:name "Dave" .  
+} :believedFromDoc <https://carol.example/profile.n3> .  

package/examples/output/{odrl-dpv-ehds-risk-ranked.txt → odrl-dpv-ehds-risk-ranked.md}

@@ -1,21 +1,26 @@
+# odrl-dpv-ehds-risk-ranked  
 
-=== Ranked DPV Risk Report (EHDS-aligned) ===
-Agreement: EHDS Secondary Use Agreement (example)
-Profile: Example patient profile (EHDS rights expectations)
+## Source files  
 
-score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H1
- Risk: secondary use is permitted without an EHDS Data Permit safeguard. Clause H1: Hospital may provide electronic health data for secondary use based on a bilateral data use agreement with the applicant.
+- [N3 rules](../odrl-dpv-ehds-risk-ranked.n3)  
 
- - mitigation for clause H1: Require an EHDS Data Permit (eu-ehds:DataPermit) issued by a Health Data Access Body prior to secondary use.
-score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H2
- Risk: secondary use may include patients who opted out (EHDS A71). Clause H2: Secondary use may include all patient records for training and evaluating health-related algorithms.
+## Ranked DPV Risk Report (EHDS-aligned)  
+Agreement: EHDS Secondary Use Agreement (example)  
+Profile: Example patient profile (EHDS rights expectations)  
 
- - mitigation for clause H2: Add an explicit safeguard to exclude records of persons who exercised the EHDS opt-out from secondary use (A71).
-score=88 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H3
- Risk: the agreement permits local downloads rather than processing within a secure processing environment. Clause H3: The applicant may download a complete local copy of the dataset to its own infrastructure for analysis.
+score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H1  
+ Risk: secondary use is permitted without an EHDS Data Permit safeguard. Clause H1: Hospital may provide electronic health data for secondary use based on a bilateral data use agreement with the applicant.  
 
- - mitigation for clause H3: Require processing only within a secure processing environment (e.g., eu-dga:SecureProcessingEnvironment), and prohibit local downloads of raw datasets.
-score=80 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H4
- Risk: secondary-use dataset is only described as pseudonymised, without a safeguard requiring statistically anonymised data for secondary use. Clause H4: The dataset will be provided in pseudonymised form by removing direct identifiers.
+ - mitigation for clause H1: Require an EHDS Data Permit (eu-ehds:DataPermit) issued by a Health Data Access Body prior to secondary use.  
+score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H2  
+ Risk: secondary use may include patients who opted out (EHDS A71). Clause H2: Secondary use may include all patient records for training and evaluating health-related algorithms.  
 
- - mitigation for clause H4: Require an EHDS Health Data Request for statistically anonymised data (eu-ehds:HealthDataRequest), and add a constraint that secondary-use data must be statistically anonymised.
+ - mitigation for clause H2: Add an explicit safeguard to exclude records of persons who exercised the EHDS opt-out from secondary use (A71).  
+score=88 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H3  
+ Risk: the agreement permits local downloads rather than processing within a secure processing environment. Clause H3: The applicant may download a complete local copy of the dataset to its own infrastructure for analysis.  
+
+ - mitigation for clause H3: Require processing only within a secure processing environment (e.g., eu-dga:SecureProcessingEnvironment), and prohibit local downloads of raw datasets.  
+score=80 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity) clause H4  
+ Risk: secondary-use dataset is only described as pseudonymised, without a safeguard requiring statistically anonymised data for secondary use. Clause H4: The dataset will be provided in pseudonymised form by removing direct identifiers.  
+
+ - mitigation for clause H4: Require an EHDS Health Data Request for statistically anonymised data (eu-ehds:HealthDataRequest), and add a constraint that secondary-use data must be statistically anonymised.  

package/examples/output/{odrl-dpv-healthcare-risk-ranked.txt → odrl-dpv-healthcare-risk-ranked.md}

@@ -1,17 +1,22 @@
+# odrl-dpv-healthcare-risk-ranked  
 
-=== Ranked DPV Risk Report (Healthcare & Life Sciences) ===
-Agreement: Example Healthcare & Life-Sciences Data Use Agreement
-Profile: Example patient profile
+## Source files  
 
-score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause H1
-  Risk: health/genomic data may be used for research without explicit opt-in consent. Clause H1: Hospital may use EHR and genomic data for internal clinical research and publication.
+- [N3 rules](../odrl-dpv-healthcare-risk-ranked.n3)  
 
-  - mitigation for clause H1: Add an explicit consent constraint for secondary research use.
-score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause H2
-  Risk: genomic data may be shared with external pharma partners without a de-identification/pseudonymisation requirement. Clause H2: Hospital may share genomic data with pharmaceutical partners for drug discovery and R&D.
+## Ranked DPV Risk Report (Healthcare & Life Sciences)  
+Agreement: Example Healthcare & Life-Sciences Data Use Agreement  
+Profile: Example patient profile  
 
-  - mitigation for clause H2: Require de-identification/pseudonymisation before external sharing of genomic data.
-score=70 (https://w3id.org/dpv/risk#ModerateRisk, https://w3id.org/dpv/risk#ModerateSeverity)  clause H4
-  Risk: retention (3650 days) exceeds patient preference (1095 days). Clause H4: Hospital retains patient health records for 10 years.
+score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause H1  
+  Risk: health/genomic data may be used for research without explicit opt-in consent. Clause H1: Hospital may use EHR and genomic data for internal clinical research and publication.  
 
-  - mitigation for clause H4: Limit retention to 3 years (or document the legal obligation requiring longer retention).
+  - mitigation for clause H1: Add an explicit consent constraint for secondary research use.  
+score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause H2  
+  Risk: genomic data may be shared with external pharma partners without a de-identification/pseudonymisation requirement. Clause H2: Hospital may share genomic data with pharmaceutical partners for drug discovery and R&D.  
+
+  - mitigation for clause H2: Require de-identification/pseudonymisation before external sharing of genomic data.  
+score=70 (https://w3id.org/dpv/risk#ModerateRisk, https://w3id.org/dpv/risk#ModerateSeverity)  clause H4  
+  Risk: retention (3650 days) exceeds patient preference (1095 days). Clause H4: Hospital retains patient health records for 10 years.  
+
+  - mitigation for clause H4: Limit retention to 3 years (or document the legal obligation requiring longer retention).  

package/examples/output/{odrl-dpv-risk-ranked.txt → odrl-dpv-risk-ranked.md}

@@ -1,22 +1,27 @@
+# odrl-dpv-risk-ranked  
 
-=== Ranked DPV Risk Report ===
-Agreement: Example Agreement
-Profile: Example consumer profile
+## Source files  
 
-score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C1
-  Risk: account/data removal is permitted without notice safeguards (no notice constraint and no duty to inform). Clause C1: Provider may remove the user account (and associated data) at its discretion.
+- [N3 rules](../odrl-dpv-risk-ranked.n3)  
 
-  - mitigation for clause C1: Add a notice constraint (minimum noticeDays) before account removal.
-  - mitigation for clause C1: Add a duty to inform the consumer prior to account removal.
-score=97 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C3
-  Risk: user data sharing is permitted without an explicit consent constraint. Clause C3: Provider may share user data with partners for business purposes.
+## Ranked DPV Risk Report  
+Agreement: Example Agreement  
+Profile: Example consumer profile  
 
-  - mitigation for clause C3: Add an explicit consent constraint before data sharing.
-score=85 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C2
-  Risk: terms may change with notice (3 days) below consumer requirement (14 days). Clause C2: Provider may change terms by informing users at least 3 days in advance.
+score=100 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C1  
+  Risk: account/data removal is permitted without notice safeguards (no notice constraint and no duty to inform). Clause C1: Provider may remove the user account (and associated data) at its discretion.  
 
-  - mitigation for clause C2: Increase minimum noticeDays in the inform duty to meet the consumer requirement.
-score=70 (https://w3id.org/dpv/risk#ModerateRisk, https://w3id.org/dpv/risk#ModerateSeverity)  clause C4
-  Risk: portability is restricted because exporting user data is prohibited. Clause C4: Users are not permitted to export their data.
+  - mitigation for clause C1: Add a notice constraint (minimum noticeDays) before account removal.  
+  - mitigation for clause C1: Add a duty to inform the consumer prior to account removal.  
+score=97 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C3  
+  Risk: user data sharing is permitted without an explicit consent constraint. Clause C3: Provider may share user data with partners for business purposes.  
 
-  - mitigation for clause C4: Add a permission allowing data export (or remove the prohibition) to support portability.
+  - mitigation for clause C3: Add an explicit consent constraint before data sharing.  
+score=85 (https://w3id.org/dpv/risk#HighRisk, https://w3id.org/dpv/risk#HighSeverity)  clause C2  
+  Risk: terms may change with notice (3 days) below consumer requirement (14 days). Clause C2: Provider may change terms by informing users at least 3 days in advance.  
+
+  - mitigation for clause C2: Increase minimum noticeDays in the inform duty to meet the consumer requirement.  
+score=70 (https://w3id.org/dpv/risk#ModerateRisk, https://w3id.org/dpv/risk#ModerateSeverity)  clause C4  
+  Risk: portability is restricted because exporting user data is prohibited. Clause C4: Users are not permitted to export their data.  
+
+  - mitigation for clause C4: Add a permission allowing data export (or remove the prohibition) to support portability.  

package/examples/output/{odrl-risk-mitigation.txt → odrl-risk-mitigation.md}

@@ -1,18 +1,23 @@
+# odrl-risk-mitigation  
 
-=== 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.
-3) score=89 (https://example.org/odrl-mitigation-demo#High), clause D4 — Tracking without opt-in. This clause is risky because it permits tracking without explicit opt-in consent. Clause D4: We may track your activity to improve services.
-4) score=85 (https://example.org/odrl-mitigation-demo#High), clause D2 — Auto-renewal without reminder. This clause is risky because it allows auto-renewal without a reminder. Consumer needs at least 7 days reminder. Clause D2: Your subscription renews automatically unless you cancel.
-5) score=85 (https://example.org/odrl-mitigation-demo#High), clause D1 — Notice period too short. This clause is risky because the notice period (3 days) is below the consumer requirement (14 days). Clause D1: We may change these terms with notice. Notice may be as short as 3 days.
-6) score=79 (https://example.org/odrl-mitigation-demo#Medium), clause D3 — Non-refundable fees. This clause is risky because it declares fees non-refundable, conflicting with a refund/cooling-off expectation (>= 14 days). Clause D3: All fees are non-refundable.
-7) score=73 (https://example.org/odrl-mitigation-demo#Medium), clause D2 — Liability cap too low. This clause is risky because the liability cap (20 EUR) is below the consumer minimum (200 EUR). Clause D2: Your subscription renews automatically unless you cancel.
+## Source files  
 
---- Suggested mitigations (highest risk first) ---
-1) clause D6 — Provider can delete user data (score=100). Suggested fix: remove provider discretion to delete data; allow deletion only on consumer request or legal obligation.
-2) clause D5 — No data export / portability (score=93). Suggested fix: add a permission to export/download user data (data portability).
-3) clause D4 — Tracking without opt-in (score=89). Suggested fix: require opt-in consent for tracking (optInConsent=true).
-4) clause D2 — Auto-renewal without reminder (score=85). Suggested fix: add a reminder duty for auto-renewal with reminderDays >= 7.
-5) clause D1 — Notice period too short (score=85). Suggested fix: ensure prior-notice duty specifies noticeDays >= 14.
-6) clause D3 — Non-refundable fees (score=79). Suggested fix: allow refunds (e.g., refundAllowed=true) or define a cooling-off period >= 14 days.
-7) clause D2 — Liability cap too low (score=73). Suggested fix: raise liabilityCapEuro so it is >= 200 EUR (or remove the cap where inappropriate).
+- [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.  
+3) score=89 (https://example.org/odrl-mitigation-demo#High), clause D4 — Tracking without opt-in. This clause is risky because it permits tracking without explicit opt-in consent. Clause D4: We may track your activity to improve services.  
+4) score=85 (https://example.org/odrl-mitigation-demo#High), clause D2 — Auto-renewal without reminder. This clause is risky because it allows auto-renewal without a reminder. Consumer needs at least 7 days reminder. Clause D2: Your subscription renews automatically unless you cancel.  
+5) score=85 (https://example.org/odrl-mitigation-demo#High), clause D1 — Notice period too short. This clause is risky because the notice period (3 days) is below the consumer requirement (14 days). Clause D1: We may change these terms with notice. Notice may be as short as 3 days.  
+6) score=79 (https://example.org/odrl-mitigation-demo#Medium), clause D3 — Non-refundable fees. This clause is risky because it declares fees non-refundable, conflicting with a refund/cooling-off expectation (>= 14 days). Clause D3: All fees are non-refundable.  
+7) score=73 (https://example.org/odrl-mitigation-demo#Medium), clause D2 — Liability cap too low. This clause is risky because the liability cap (20 EUR) is below the consumer minimum (200 EUR). Clause D2: Your subscription renews automatically unless you cancel.  
+
+--- Suggested mitigations (highest risk first) ---  
+1) clause D6 — Provider can delete user data (score=100). Suggested fix: remove provider discretion to delete data; allow deletion only on consumer request or legal obligation.  
+2) clause D5 — No data export / portability (score=93). Suggested fix: add a permission to export/download user data (data portability).  
+3) clause D4 — Tracking without opt-in (score=89). Suggested fix: require opt-in consent for tracking (optInConsent=true).  
+4) clause D2 — Auto-renewal without reminder (score=85). Suggested fix: add a reminder duty for auto-renewal with reminderDays >= 7.  
+5) clause D1 — Notice period too short (score=85). Suggested fix: ensure prior-notice duty specifies noticeDays >= 14.  
+6) clause D3 — Non-refundable fees (score=79). Suggested fix: allow refunds (e.g., refundAllowed=true) or define a cooling-off period >= 14 days.  
+7) clause D2 — Liability cap too low (score=73). Suggested fix: raise liabilityCapEuro so it is >= 200 EUR (or remove the cap where inappropriate).  

package/examples/output/{odrl-risk.txt → odrl-risk.md}

@@ -1,6 +1,11 @@
+# odrl-risk  
 
-=== 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.
-3) score=95 (https://example.org/agreement#High), clause C1 — Unilateral change without notice. This clause is risky because it allows unilateral changes without any prior notice. Clause C1: We may change these terms at any time. Continued use means acceptance.
-4) score=60 (https://example.org/agreement#Medium), clause C4 — Court access waiver / mandatory arbitration. This clause is risky because it restricts access to court (mandatory arbitration / waiver). Clause C4: You waive your right to go to court; disputes must be arbitrated.
+## 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.  
+3) score=95 (https://example.org/agreement#High), clause C1 — Unilateral change without notice. This clause is risky because it allows unilateral changes without any prior notice. Clause C1: We may change these terms at any time. Continued use means acceptance.  
+4) score=60 (https://example.org/agreement#Medium), clause C4 — Court access waiver / mandatory arbitration. This clause is risky because it restricts access to court (mandatory arbitration / waiver). Clause C4: You waive your right to go to court; disputes must be arbitrated.  

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

@@ -0,0 +1,26 @@
+# parcellocker  
+
+## Source files  
+
+- [N3 rules](../parcellocker.n3)  
+
+ParcelLocker — One-time parcel pickup by a friend  
+
+## Answer  
+PERMIT  
+Noah may collect Maya's parcel from locker B17.  
+
+## 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  
+C1  OK - requester matches the named delegate  
+C2  OK - requested parcel matches the authorized parcel  
+C3  OK - requested locker matches the authorized locker  
+C4  OK - requested action is parcel collection  
+C5  OK - requested purpose is pickup only  
+C6  OK - authorization is active  
+C7  OK - authorization is single-use  
+C8  OK - parcel is ready for pickup  
+C9  OK - billing details stay hidden  
+C10 OK - parcel redirection is not allowed  

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

@@ -0,0 +1,29 @@
+# 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  
+peak bias                     : 2  
+peak current proxy            : 4  
+negative differential region  : yes  
+
+## Reason Why  
+We model tunneling current as an exact overlap count between filled N-side states and empty P-side states while forward bias shifts the bands. Heavy doping is represented by a much narrower depletion region.  
+ordinary depletion width (nm) : 8  
+tunnel depletion width (nm)   : 1  
+filled N-side states          : [1, 2, 3, 4]  
+empty P-side states at 0 bias : [3, 4, 5, 6]  
+bias -> overlap current proxy : 0->2, 1->3, 2->4, 3->3, 4->2, 5->1, 6->0  
+peak point                    : 2 -> 4  
+high-bias point               : 6 -> 0  
+
+## Check  
+heavily doped barrier is narrower : yes  
+peak occurs before overlap closes : yes  
+negative differential region present : yes  
+high-bias overlap closes           : yes  
+peak equals full four-state overlap: yes  

package/examples/output/queens.md

@@ -0,0 +1,27 @@
+# queens  
+
+## Source files  
+
+- [N3 rules](../queens.n3)  
+
+Solving 14-Queens...  
+Printing at most 1 solution(s).  
+
+Solution 1:  
+Q . . . . . . . . . . . . .  
+. . Q . . . . . . . . . . .  
+. . . . Q . . . . . . . . .  
+. . . . . . Q . . . . . . .  
+. . . . . . . . . . . Q . .  
+. . . . . . . . . Q . . . .  
+. . . . . . . . . . . . Q .  
+. . . Q . . . . . . . . . .  
+. . . . . . . . . . . . . Q  
+. . . . . . . . Q . . . . .  
+. Q . . . . . . . . . . . .  
+. . . . . Q . . . . . . . .  
+. . . . . . . Q . . . . . .  
+. . . . . . . . . . Q . . .  
+As column positions by row: [1, 3, 5, 7, 12, 10, 13, 4, 14, 9, 2, 6, 8, 11]  
+
+Total solutions for 14-Queens: 365596  

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

@@ -0,0 +1,16 @@
+# 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]  
+first below tolerance step : 13  
+first below tolerance time : 0.325 s  
+upper voltage at step 13 : 0.930581 V  
+
+## Explanation  
+The 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.  

package/examples/output/rdf-dataset.md

@@ -0,0 +1,12 @@
+# 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#> .  
+
+:workOrder :entails <<( :sensor :needs :inspection )>> .  

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

@@ -0,0 +1,12 @@
+# 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.  
+
+## Explanation  
+The 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.  

package/examples/output/rdf-messages.md

@@ -0,0 +1,12 @@
+# 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.  
+
+## Explanation  
+The 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, 22 and 23, are different observations from the same stream but are contextualized by their message boundaries.  

package/examples/output/{resto.txt → resto.md}

@@ -1,20 +1,26 @@
-RESTdesc — Restaurant finder
+# resto  
 
-Answer
-A restaurant was found and reserved.
-Restaurant: Maximiliaan
-Date: 2026-04-08
-Seating: outside terrace
+## Source files  
 
-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.
+- [N3 rules](../resto.n3)  
 
-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.
-C4 OK - the weather interpretation justified outdoor seating.
-C5 OK - the recommendation step selected a restaurant that can accept reservations.
-C6 OK - the reservation preserved the requested dinner date.
-C7 OK - the reservation preserved the outdoor seating preference.
-C8 OK - the final goal pattern from the original RESTdesc query is satisfied.
+RESTdesc — Restaurant finder  
+
+## Answer  
+A restaurant was found and reserved.  
+Restaurant: Maximiliaan  
+Date: 2026-04-08  
+Seating: outside terrace  
+
+## 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  
+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.  
+C4 OK - the weather interpretation justified outdoor seating.  
+C5 OK - the recommendation step selected a restaurant that can accept reservations.  
+C6 OK - the reservation preserved the requested dinner date.  
+C7 OK - the reservation preserved the outdoor seating preference.  
+C8 OK - the final goal pattern from the original RESTdesc query is satisfied.  

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

@@ -0,0 +1,16 @@
+# 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  
+largest hidden detour : Ada, 3000 m  
+recommended assignments : Ada -> Lindholmen; Björn -> Backa; Clara -> Haga; Davi -> Haga  
+explanation requested : yes  
+
+## Explanation  
+The 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.  

package/examples/output/smoke-arithmetic.md

@@ -0,0 +1,12 @@
+# smoke-arithmetic  
+
+## Source files  
+
+- [N3 rules](../smoke-arithmetic.n3)  
+- [Input TriG](../input/smoke-arithmetic.trig)  
+
+## Answer  
+product = 42  
+
+## Explanation  
+The compiled rule multiplies :x and :y using math:product.  

package/examples/output/sqrt2-cauchy.md

@@ -0,0 +1,19 @@
+# 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  
+n=2  x=1.4166666666666665  delta=0.08333333333333348  err=0.006944444444444198  
+n=3  x=1.4142156862745097  delta=0.002450980392156854  err=0.000006007304882427178  
+n=4  x=1.4142135623746899  delta=0.0000021238998197947723  err=4.510614104447086e-12  
+n=5  x=1.414213562373095  delta=1.5949463971764999e-12  err=4.440892098500626e-16  
+n=6  x=1.414213562373095  delta=0  err=4.440892098500626e-16  
+n=7  x=1.414213562373095  delta=0  err=4.440892098500626e-16  
+n=8  x=1.414213562373095  delta=0  err=4.440892098500626e-16  
+n=9  x=1.414213562373095  delta=0  err=4.440892098500626e-16  
+n=10  x=1.414213562373095  delta=0  err=4.440892098500626e-16  
+Tail check: for i,j in (4..10), all |x_i - x_j| < 0.0001 (finite check)  

package/examples/output/sqrt2-dedekind.md

@@ -0,0 +1,37 @@
+# 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)  
+q=-0.1  q^2=0.010000000000000002  => LEFT (q<0 OR q^2<2)  
+q=0  q^2=0  => LEFT (q<0 OR q^2<2)  
+q=0.5  q^2=0.25  => LEFT (q<0 OR q^2<2)  
+q=1  q^2=1  => LEFT (q<0 OR q^2<2)  
+q=1.3  q^2=1.6900000000000002  => LEFT (q<0 OR q^2<2)  
+q=1.4  q^2=1.9599999999999997  => LEFT (q<0 OR q^2<2)  
+q=1.41  q^2=1.9880999999999998  => LEFT (q<0 OR q^2<2)  
+q=1.414  q^2=1.9993959999999997  => LEFT (q<0 OR q^2<2)  
+q=1.4142  q^2=1.9999616399999998  => LEFT (q<0 OR q^2<2)  
+q=1.4143  q^2=2.0002444899999996  => RIGHT (q>=0 AND q^2>=2)  
+q=1.42  q^2=2.0164  => RIGHT (q>=0 AND q^2>=2)  
+q=1.5  q^2=2.25  => RIGHT (q>=0 AND q^2>=2)  
+q=2  q^2=4  => RIGHT (q>=0 AND q^2>=2)  
+successor: from -2 to -1   (s^2=1)  
+successor: from -1 to -0.5   (s^2=0.25)  
+successor: from -0.5 to -0.25   (s^2=0.0625)  
+successor: from -0.1 to -0.05   (s^2=0.0025000000000000005)  
+successor: from 0 to 1   (s^2=1)  
+successor: from 0.5 to 1.2   (s^2=1.44)  
+successor: from 1 to 1.3333333333333333   (s^2=1.7777777777777777)  
+successor: from 1.3 to 1.393939393939394   (s^2=1.9430670339761251)  
+successor: from 1.4 to 1.411764705882353   (s^2=1.9930795847750868)  
+successor: from 1.41 to 1.4134897360703813   (s^2=1.9979532339763162)  
+successor: from 1.414 to 1.4141769185705917   (s^2=1.9998963570178139)  
+successor: from 1.4142 to 1.4142112354285044   (s^2=1.9999934184122166)  
+Check: cut is proper on the sample (has LEFT and RIGHT witnesses)  
+Check: downward-closed on the sample (finite for-all test)  
+Check: no maximal element witnessed for all LEFT seed members (constructive successors)  

package/examples/output/sudoku.md

@@ -0,0 +1,49 @@
+# sudoku  
+
+## Source files  
+
+- [N3 rules](../sudoku.n3)  
+
+## Answer  
+The puzzle is solved, and the completed grid is the unique valid Sudoku solution.  
+case              : sudoku  
+default puzzle    : classic  
+
+Puzzle  
+1 . . | . . 7 | . 9 .  
+. 3 . | . 2 . | . . 8  
+. . 9 | 6 . . | 5 . .  
+
+. . 5 | 3 . . | 9 . .  
+. 1 . | . 8 . | . . 2  
+6 . . | . . 4 | . . .  
+
+3 . . | . . . | . 1 .  
+. 4 . | . . . | . . 7  
+. . 7 | . . . | 3 . .  
+
+Completed grid  
+1 6 2 | 8 5 7 | 4 9 3  
+5 3 4 | 1 2 9 | 6 7 8  
+7 8 9 | 6 4 3 | 5 2 1  
+
+4 7 5 | 3 1 2 | 9 8 6  
+9 1 3 | 5 8 6 | 7 4 2  
+6 2 8 | 7 9 4 | 1 3 5  
+
+3 5 6 | 4 7 8 | 2 1 9  
+2 4 1 | 9 3 5 | 8 6 7  
+8 9 7 | 2 6 1 | 3 5 4  
+
+## Reason Why  
+The solver starts from 23 clues and fills the remaining 58 cells by combining constraint propagation with depth-first search. At each step it chooses the empty cell with the fewest legal digits, places forced singles immediately, and only guesses when more than one candidate remains. Across the search it made 213 forced placements and tried 22 guesses, visited 23 search nodes overall, and backtracked 12 times before reaching the completed grid. The solver also confirmed that the solution is unique. Early steps: r2c3=4: guess, r5c3=3: forced, r2c1=5: guess, r2c4=1: guess, r2c6=9: forced, r2c7=6: guess, r2c8=7: forced, r1c7=4: guess, … and 50 more placements  
+
+## Check  
+C1 OK - every given clue is preserved in the final grid.  
+C2 OK - the final grid contains only digits 1 through 9, with no blanks left.  
+C3 OK - each row contains every digit exactly once.  
+C4 OK - each column contains every digit exactly once.  
+C5 OK - each 3×3 box contains every digit exactly once.  
+C6 OK - replaying the recorded placements from the original puzzle remains legal at every step.  
+C7 OK - the search statistics and the successful proof path are internally consistent.  
+C8 OK - a second search found no alternative solution, so the solution is unique.