eyeling 1.33.1 → 1.33.3

package/README.md

@@ -631,6 +631,13 @@ Use the CLI option when running `.pl` programs:
 eyeling --engine eyelang examples/eyelang/ancestor.pl
 ```
 
+A paired example shows the same vulnerability-impact scenario in both engines:
+
+```bash
+eyeling examples/vulnerability-impact.n3
+eyeling --engine eyelang examples/eyelang/vulnerability-impact.pl
+```
+
 Use the CommonJS convenience API when the rest of your application already imports `eyeling`:
 
 ```js
@@ -1171,6 +1178,7 @@ The repository contains more than two hundred N3 examples under `examples/`, plu
 | `examples/age.n3` | Literal propagation. |
 | `examples/family-cousins.n3` | Multi-hop relational inference. |
 | `examples/dijkstra.n3` | Graph/path reasoning. |
+| `examples/vulnerability-impact.n3` and `examples/eyelang/vulnerability-impact.pl` | Paired N3 and eyelang dependency-risk example. |
 | `examples/list-map.n3` | List processing. |
 | `examples/string-builtins-tests.n3` | String built-ins. |
 | `examples/math-builtins-tests.n3` | Numeric built-ins. |

package/bin/eyeling.cjs

@@ -37,7 +37,7 @@ function normalizeEngineName(value) {
 }
 
 async function runEyelangCli(argv) {
-  const cliUrl = pathToFileURL(path.join(__dirname, '..', 'lib', 'eyelang', 'cli.mjs')).href;
+  const cliUrl = pathToFileURL(path.join(__dirname, '..', 'lib', 'eyelang', 'cli.js')).href;
   const cli = await import(cliUrl);
   await cli.main(argv);
 }

package/dist/browser/eyeling.browser.js

@@ -6483,7 +6483,7 @@ async function main() {
       `Options:\n` +
       `  -a, --ast                    Print parsed AST as JSON and exit.\n` +
       `      --builtin <module.js>    Load a custom builtin module (repeatable).\n` +
-      `      --engine <n3|eyelang>    Select the N3 engine (default) or eyelang engine.\n` +
+      `      --engine <n3|eyelang>   Select the N3 engine (default) or eyelang engine.\n` +
       `  -d, --deterministic-skolem   Make log:skolem stable across reasoning runs.\n` +
       `  -e, --enforce-https          Rewrite http:// IRIs to https:// for log dereferencing builtins.\n` +
       `  -h, --help                   Show this help and exit.\n` +

package/examples/eyelang/INTEGRATION.md

@@ -6,6 +6,13 @@ This directory contains eyelang examples that can be exercised through Eyeling's
 eyeling --engine eyelang examples/eyelang/ancestor.pl
 ```
 
+For a paired example, compare the N3 and eyelang versions of the same dependency-risk scenario:
+
+```bash
+eyeling examples/vulnerability-impact.n3
+eyeling --engine eyelang examples/eyelang/vulnerability-impact.pl
+```
+
 The eyelang conformance corpus is kept under `test/eyelang/` and can be run with:
 
 ```bash

package/examples/eyelang/README.md

@@ -1,5 +1,8 @@
 # eyelang
 
+[![npm version](https://img.shields.io/npm/v/eyelang.svg)](https://www.npmjs.com/package/eyelang)
+[![DOI](https://img.shields.io/badge/DOI-10.5281%2Fzenodo.1242549108-blue.svg)](https://doi.org/10.5281/zenodo.20342331)
+
 eyelang is a small rule engine for Prolog-style Horn clauses over ordinary terms, lists, arithmetic, strings, and finite search. The command-line executable is `eyelang`.
 
 Programs write relations directly, for example `ancestor(pat, emma)` or `status(case1, accepted)`. eyelang output is ordinary eyelang syntax: by default, the CLI materializes selected answer facts and prints those facts only. Pass `--proof` (or `-p`) when you also want each answer followed by a `why/2` explanation fact that records the proof. Programs may add `materialize(Name, Arity).` declarations to focus output on selected predicates.
@@ -17,13 +20,12 @@ For the normative language definition, including lexical syntax, terms, clauses,
 4. [Writing programs](#writing-programs)
 5. [Aggregation helpers](#aggregation-helpers)
 6. [Formula data](#formula-data)
-7. [RDF 1.2 and Notation3 compatibility](#rdf-12-and-notation3-compatibility)
-8. [Example catalog](#example-catalog)
-9. [Golden outputs, tests, and conformance](#golden-outputs-tests-and-conformance)
-10. [Development and release](#development-and-release)
-11. [Relationship to Eyeling](#relationship-to-eyeling)
-12. [Performance notes](#performance-notes)
-13. [Implementation limits](#implementation-limits)
+7. [Example catalog](#example-catalog)
+8. [Golden outputs, tests, and conformance](#golden-outputs-tests-and-conformance)
+9. [Development and release](#development-and-release)
+10. [Relationship to Eyeling](#relationship-to-eyeling)
+11. [Performance notes](#performance-notes)
+12. [Implementation limits](#implementation-limits)
 
 ## Quick start
 
@@ -313,69 +315,9 @@ formula_binary((name(alice, "Alice"), knows(alice, bob)), S, P, O).
 This can yield `S = alice`, `P = name`, `O = "Alice"` and `S = alice`, `P = knows`, `O = bob`. The utility is useful for quoted formula data, but it does not make those formula members true in the ambient program.
 
 
-## RDF 1.2 and Notation3 compatibility
-
-The core eyelang syntax remains Prolog-like, but `src/rdf.js` adds a compatibility layer for RDF 1.2 Turtle/N-Triples style data and a practical Notation3 rule subset. Use it from the CLI with `--rdf`, `--rdf12`, `--n3`, or `--input-format FORMAT`; file inputs ending in `.ttl`, `.nt`, or `.n3` are recognized when the CLI uses its default `auto` format.
-
-```sh
-bin/eyelang --rdf data.ttl rules.n3
-printf '@prefix : <http://example.com/> .
-{ ?x :parent ?y . } => { ?x :related ?y . } .
-:alice :parent :bob .
-' | bin/eyelang --n3 -
-```
-
-RDF triples are lowered to ordinary `rdf/3` goals:
-
-```prolog
-rdf(Subject, Predicate, Object).
-```
-
-RDF terms are explicit eyelang compound terms:
-
-```prolog
-iri("http://example.com/alice")
-bnode("b0")
-literal("Alice", iri("http://www.w3.org/2001/XMLSchema#string"), "", "")
-triple(Subject, Predicate, Object)
-```
-
-The layer supports `PREFIX`/`@prefix`, `BASE`/`@base`, `VERSION`/`@version`, IRIs, prefixed names, blank nodes, strings, numeric and boolean literals, language-tagged and RDF 1.2 directional language-tagged strings, RDF collections, blank-node property lists, RDF 1.2 triple terms `<<( ... )>>`, reified triple sugar `<< ... >>`, annotation blocks `{| ... |}`, N3 rules of the form `{ antecedent } => { consequent } .`, reverse rules of the form `{ consequent } <= { antecedent } .`, and N3 equality `=` as `owl:sameAs`. Reified triples and annotations are expanded through `rdf:reifies`, so this Turtle fragment:
-
-```turtle
-VERSION "1.2"
-PREFIX : <http://example.com/>
-:alice :name "Alice" ~ :t {| :statedBy :bob |} .
-```
-
-is made available as eyelang facts like:
-
-```prolog
-rdf(iri("http://example.com/alice"), iri("http://example.com/name"), literal("Alice", iri("http://www.w3.org/2001/XMLSchema#string"), "", "")).
-rdf(iri("http://example.com/t"), iri("http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies"), triple(iri("http://example.com/alice"), iri("http://example.com/name"), literal("Alice", iri("http://www.w3.org/2001/XMLSchema#string"), "", ""))).
-rdf(iri("http://example.com/t"), iri("http://example.com/statedBy"), iri("http://example.com/bob")).
-```
-
-From JavaScript, use `parseRdfClauses(source, options)` when you want clause objects, or `rdfToEyelang(source, options)` when you want the lowered eyelang source text.
-
-N3 body triples whose predicates are in the common SWAP namespaces are lowered to eyelang built-ins instead of `rdf/3` goals. The practical bridge covers math comparisons and arithmetic such as `math:sum`, `math:difference`, `math:product`, `math:quotient`, `math:rounded`, and trigonometric functions, with exact BigInt-backed integer paths for large N3 arithmetic examples; string predicates such as `string:contains`, `string:startsWith`, `string:concatenation`, `string:length`, `string:replace`, and `string:scrape`; list predicates such as `list:member`, `list:append`, `list:first`, `list:rest`, `list:length`, `list:reverse`, and `list:sort`; `crypto:sha`, `crypto:md5`, `crypto:sha256`, `crypto:sha512`; simple `time:*` component extraction; and selected `log:*` helpers such as `log:equalTo`, `log:notEqualTo`, `log:uri`, `log:dtlit`, and `log:rawType`. This follows the builtin families used by eyeling while keeping eyelang's execution model small.
-
-RDF/N3 examples now live directly in [`examples/`](examples/), with golden outputs in [`examples/output/`](examples/output/), matching the existing example layout. They include eyeling-inspired `socrates.n3`, `family-cousins.n3`, and `annotation-rdf12.ttl` examples; focused RDF 1.2 triple-term and directional-language examples; `n3-builtins.n3`; and a larger `eyeling-*.n3` set adapted from the eyeling example directory. The added eyeling-style examples cover backward rules, recursive `<=`, equality, collection/list handling, Ackermann-style hyperoperations, Fibonacci numbers, dog-license, witch, Cat Koko, family/cousin, alignment, BMI, and SWAP math/string/list/crypto/time builtins. Run them with auto format detection or force the reader explicitly:
-
-```sh
-bin/eyelang examples/socrates.n3
-bin/eyelang --rdf12 examples/annotation-rdf12.ttl
-bin/eyelang --n3 examples/n3-builtins.n3
-bin/eyelang --n3 examples/eyeling-backward-recursion.n3
-bin/eyelang --n3 examples/eyeling-ackermann.n3
-bin/eyelang --n3 examples/eyeling-fibonacci.n3
-```
-
-This is a compatibility layer, not a validating W3C conformance parser. It intentionally covers the graph-oriented syntax, common RDF 1.2 constructs, and the N3 Horn-rule/builtin patterns that map cleanly to eyelang; it does not implement RDF/XML, full TriG datasets, SPARQL, scoped N3 formula built-ins such as full `log:semantics`, or every Notation3 construct.
-
 ## Example catalog
 
-The repository includes examples for recursion, graph reachability, finite search, arithmetic, list processing, optimization, policies, puzzles, N3-inspired rule chains, and applied scientific calculations. Bundled examples use relation-style output.
+The repository includes examples for recursion, graph reachability, finite search, arithmetic, list processing, optimization, policies, puzzles, and applied scientific calculations. Bundled examples use relation-style output.
 
 | Input | Short description | Output |
 | --- | --- | --- |
@@ -388,7 +330,6 @@ The repository includes examples for recursion, graph reachability, finite searc
 | [`ancestor.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/ancestor.pl) | Derives ancestors from parent facts. | [`output/ancestor.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/ancestor.pl) |
 | [`animal.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/animal.pl) | Classifies animals from traits. | [`output/animal.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/animal.pl) |
 | [`annotation.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/annotation.pl) | Derives facts from quoted annotation data. | [`output/annotation.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/annotation.pl) |
-| [`annotation-rdf12.ttl`](https://github.com/eyereasoner/eyelang/blob/main/examples/annotation-rdf12.ttl) | Demonstrates RDF 1.2 annotation syntax lowered through `rdf:reifies`. | [`output/annotation-rdf12.ttl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/annotation-rdf12.ttl) |
 | [`auroracare.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/auroracare.pl) | Evaluates purpose-based medical data access scenarios. | [`output/auroracare.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/auroracare.pl) |
 | [`backward.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/backward.pl) | Shows a backward-rule pattern as a goal-directed numeric rule. | [`output/backward.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/backward.pl) |
 | [`basic-monadic.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/basic-monadic.pl) | Runs a monadic benchmark over generated inputs. | [`output/basic-monadic.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/basic-monadic.pl) |
@@ -512,21 +453,19 @@ The repository includes examples for recursion, graph reachability, finite searc
 | [`traveling-salesman.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/traveling-salesman.pl) | Finds an optimal traveling-salesman tour. | [`output/traveling-salesman.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/traveling-salesman.pl) |
 | [`turing.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/turing.pl) | Simulates a binary-increment Turing machine. | [`output/turing.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/turing.pl) |
 | [`vector-similarity.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/vector-similarity.pl) | Computes dot product, norm, and cosine similarity. | [`output/vector-similarity.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/vector-similarity.pl) |
-| [`witch.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/witch.pl) | Derives the classic “burn the witch” N3 rule chain. | [`output/witch.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/witch.pl) |
+| [`vulnerability-impact.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/vulnerability-impact.pl) | Analyzes vulnerable transitive dependencies and urgent patch impact. | [`output/vulnerability-impact.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/vulnerability-impact.pl) |
+| [`witch.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/witch.pl) | Derives the classic “burn the witch” rule chain. | [`output/witch.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/witch.pl) |
 | [`wolf-goat-cabbage.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/wolf-goat-cabbage.pl) | Solves the wolf-goat-cabbage river crossing. | [`output/wolf-goat-cabbage.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/wolf-goat-cabbage.pl) |
 | [`zebra.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/zebra.pl) | Solves the zebra logic puzzle. | [`output/zebra.pl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/zebra.pl) |
 
 
-| [`directional-language.ttl`](https://github.com/eyereasoner/eyelang/blob/main/examples/directional-language.ttl) | Demonstrates RDF 1.2 directional language-tagged strings. | [`output/directional-language.ttl`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/directional-language.ttl) |
-| [`n3-builtins.n3`](https://github.com/eyereasoner/eyelang/blob/main/examples/n3-builtins.n3) | Uses N3 `<=` plus `math:`, `string:`, and `list:` builtins. | [`output/n3-builtins.n3`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/n3-builtins.n3) |
-| [`triple-term.n3`](https://github.com/eyereasoner/eyelang/blob/main/examples/triple-term.n3) | Demonstrates RDF 1.2 triple terms in N3 data and rules. | [`output/triple-term.n3`](https://github.com/eyereasoner/eyelang/blob/main/examples/output/triple-term.n3) |
 
 ## Golden outputs, tests, and conformance
 
-Golden answer outputs live in [`examples/output`](examples/output). `npm run test:examples` covers every top-level runnable example with extension `.pl`, `.n3`, `.ttl`, or `.nt`. A curated proof-output suite for `.pl` examples lives in [`examples/proof`](examples/proof). Example tests pin `local_time/1` to `2026-05-30` so date-dependent examples stay deterministic. Regenerate them after an intentional output or explanation change:
+Golden answer outputs live in [`examples/output`](examples/output). `npm run test:examples` covers every top-level runnable `.pl` example. A curated proof-output suite for `.pl` examples lives in [`examples/proof`](examples/proof). Example tests pin `local_time/1` to `2026-05-30` so date-dependent examples stay deterministic. Regenerate them after an intentional output or explanation change:
 
 ```sh
-for f in examples/*.pl examples/*.n3 examples/*.ttl examples/*.nt; do
+for f in examples/*.pl; do
   [ -e "$f" ] || continue
   b=$(basename "$f")
   EYELANG_LOCAL_TIME=2026-05-30 bin/eyelang "$f" > "examples/output/$b"
@@ -625,4 +564,4 @@ For large programs, keep helper predicates selective, bind arguments early, and
 
 ## Implementation limits
 
-eyelang is intentionally smaller than ISO Prolog. It has no operators, cut, modules, dynamic database updates, DCGs, or complete ISO library. Negation is negation-as-failure through `not/1`. Search is goal-directed and expected to be finite for the selected output goals. Output explanations are non-normative proof printouts and do not change answer semantics. The RDF 1.2 / Notation3 reader is an implementation compatibility layer over `rdf/3`, not a normative RDF conformance profile.
+eyelang is intentionally smaller than ISO Prolog. It has no operators, cut, modules, dynamic database updates, DCGs, or complete ISO library. Negation is negation-as-failure through `not/1`. Search is goal-directed and expected to be finite for the selected output goals. Output explanations are non-normative proof printouts and do not change answer semantics. 

package/examples/eyelang/SPEC.md

@@ -470,7 +470,7 @@ An extension built-in SHOULD obey the same surface-language discipline as standa
 - it SHOULD document its intended modes, especially which arguments must be ground before it runs deterministically;
 - it MUST NOT change the meaning of ordinary facts, rules, unification, or standard built-ins.
 
-For example, an implementation may include extension modules for Sudoku solving, portfolio selection, number-theory algorithms, graph search, matrix operations, alphametic puzzles, or a non-normative RDF/Notation3 reader that lowers RDF triples to ordinary eyelang predicates such as `rdf/3` and lowers selected Notation3 built-in predicates to extension built-ins such as `n3_math_sum/2` or `n3_string_contains/2`. Those modules may be valuable and may make example programs much faster, but their predicate names, arities, algorithms, syntax accepted by non-eyelang readers, and modes are implementation-defined unless they are separately standardized.
+For example, an implementation may include extension modules for Sudoku solving, portfolio selection, number-theory algorithms, graph search, matrix operations, or alphametic puzzles. Those modules may be valuable and may make example programs much faster, but their predicate names, arities, algorithms, and modes are implementation-defined unless they are separately standardized.
 
 An implementation that provides explanation output SHOULD make extension built-ins explainable at least as opaque successful or failed built-in calls, so that proof traces do not incorrectly report "no clauses" for a host-provided relation.
 
@@ -681,4 +681,3 @@ URL input uses host networking support when available. Hosts SHOULD treat downlo
 
 Programs SHOULD be written with finite search in mind. Broad default materialization can be expensive for helper predicates; use `materialize/2` declarations and concise output predicates when needed.
 
-Compatibility readers for external syntaxes such as RDF 1.2 Turtle, N-Triples, or Notation3 SHOULD be treated as front-end translations into eyelang clauses. Such readers may support N3 implication syntaxes such as `=>` and `<=`, empty `true` rule bodies, N3 equality as `owl:sameAs`, and common N3/SWAP built-in namespaces mapped to host extension built-ins, including exact integer arithmetic where the host provides it. Unless a host explicitly claims a separate RDF or N3 conformance profile, such readers are not part of core eyelang conformance and may accept only the subset that maps cleanly to finite Horn-clause reasoning.

package/examples/eyelang/output/vulnerability-impact.pl

@@ -0,0 +1,20 @@
+uses(webapp, api).
+uses(worker, queue).
+uses(frontend, ui).
+uses(webapp, auth).
+uses(worker, openssl).
+uses(frontend, css).
+uses(webapp, openssl).
+impacted_by(webapp, api).
+impacted_by(worker, queue).
+impacted_by(frontend, ui).
+impacted_by(webapp, auth).
+impacted_by(worker, openssl).
+impacted_by(frontend, css).
+impacted_by(webapp, openssl).
+risk(worker, high).
+risk(webapp, high).
+mitigate(worker, cve_2026_0001).
+mitigate(webapp, cve_2026_0001).
+urgent_patch(webapp, openssl_3_0_14).
+urgent_patch(worker, openssl_3_0_14).

package/examples/eyelang/vulnerability-impact.pl

@@ -0,0 +1,70 @@
+% Vulnerability impact analysis over a transitive dependency graph.
+%
+% This mirrors examples/vulnerability-impact.n3 using eyelang rules.
+
+% Output declarations: materialize/2 selects the relations written to this example's golden output.
+materialize(uses, 2).
+materialize(impacted_by, 2).
+materialize(risk, 2).
+materialize(mitigate, 2).
+materialize(urgent_patch, 2).
+
+% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
+service(webapp).
+service(worker).
+service(frontend).
+
+critical(webapp).
+critical(worker).
+
+depends_on(webapp, api).
+depends_on(worker, queue).
+depends_on(frontend, ui).
+depends_on(api, auth).
+depends_on(auth, openssl).
+depends_on(queue, openssl).
+depends_on(ui, css).
+
+vulnerability(openssl, cve_2026_0001).
+cvss(cve_2026_0001, 9.8).
+fixed_by(cve_2026_0001, openssl_3_0_14).
+
+vulnerability(css, cve_2026_0002).
+cvss(cve_2026_0002, 5.4).
+fixed_by(cve_2026_0002, css_2_1_1).
+
+% Derivation rules: each rule below contributes one logical step toward the displayed results.
+uses(Service, Dependency) :-
+  service(Service),
+  depends_on(Service, Dependency).
+
+uses(Service, Dependency) :-
+  service(Service),
+  depends_on(Service, Intermediate),
+  depends_on(Intermediate, Dependency).
+
+uses(Service, Dependency) :-
+  service(Service),
+  depends_on(Service, Intermediate),
+  depends_on(Intermediate, Next),
+  depends_on(Next, Dependency).
+
+impacted_by(Service, Dependency) :-
+  uses(Service, Dependency).
+
+exposed_to(Service, Vulnerability) :-
+  uses(Service, Package),
+  vulnerability(Package, Vulnerability),
+  cvss(Vulnerability, Score),
+  gt(Score, 7.0).
+
+risk(Service, high) :-
+  exposed_to(Service, _Vulnerability).
+
+mitigate(Service, Vulnerability) :-
+  exposed_to(Service, Vulnerability).
+
+urgent_patch(Service, Patch) :-
+  critical(Service),
+  exposed_to(Service, Vulnerability),
+  fixed_by(Vulnerability, Patch).

package/examples/output/vulnerability-impact.n3

@@ -0,0 +1,22 @@
+@prefix : <https://example.org/vulnerability-impact#> .
+
+:webapp :uses :api .
+:worker :uses :queue .
+:frontend :uses :ui .
+:webapp :uses :auth .
+:worker :uses :openssl .
+:frontend :uses :css .
+:webapp :uses :openssl .
+:worker :risk :high .
+:worker :mitigate :CVE_2026_0001 .
+:webapp :risk :high .
+:webapp :mitigate :CVE_2026_0001 .
+:webapp :urgentPatch :openssl_3_0_14 .
+:worker :urgentPatch :openssl_3_0_14 .
+:webapp :impactedBy :api .
+:worker :impactedBy :queue .
+:frontend :impactedBy :ui .
+:webapp :impactedBy :auth .
+:worker :impactedBy :openssl .
+:frontend :impactedBy :css .
+:webapp :impactedBy :openssl .

package/examples/vulnerability-impact.n3

@@ -0,0 +1,80 @@
+# ===========================================================
+# Vulnerability impact analysis over a transitive dependency graph
+# ===========================================================
+
+@prefix math: <http://www.w3.org/2000/10/swap/math#>.
+@prefix : <https://example.org/vulnerability-impact#>.
+
+# Services.
+:webapp a :Service; :critical true; :dependsOn :api.
+:worker a :Service; :critical true; :dependsOn :queue.
+:frontend a :Service; :dependsOn :ui.
+
+# Component dependencies.
+:api :dependsOn :auth.
+:auth :dependsOn :openssl.
+:queue :dependsOn :openssl.
+:ui :dependsOn :css.
+
+# Vulnerability data.
+:openssl :vulnerability :CVE_2026_0001.
+:CVE_2026_0001 :cvss 9.8; :fixedBy :openssl_3_0_14.
+
+:css :vulnerability :CVE_2026_0002.
+:CVE_2026_0002 :cvss 5.4; :fixedBy :css_2_1_1.
+
+# A service uses its direct dependencies and the components they pull in.
+{
+    ?S a :Service.
+    ?S :dependsOn ?D.
+} => {
+    ?S :uses ?D.
+}.
+
+{
+    ?S a :Service.
+    ?S :dependsOn ?M.
+    ?M :dependsOn ?D.
+} => {
+    ?S :uses ?D.
+}.
+
+{
+    ?S a :Service.
+    ?S :dependsOn ?M.
+    ?M :dependsOn ?N.
+    ?N :dependsOn ?D.
+} => {
+    ?S :uses ?D.
+}.
+
+# Materialize the dependency closure for impact review.
+{
+    ?S :uses ?D.
+} => {
+    ?S :impactedBy ?D.
+}.
+
+# A service is high risk when any reachable component has a severe vulnerability.
+{
+    ?S :uses ?Pkg.
+    ?Pkg :vulnerability ?V.
+    ?V :cvss ?Score.
+    ?Score math:greaterThan 7.0.
+} => {
+    ?S :risk :high.
+    ?S :mitigate ?V.
+}.
+
+# Critical services with a severe reachable vulnerability get the available patch first.
+{
+    ?S a :Service.
+    ?S :critical true.
+    ?S :uses ?Pkg.
+    ?Pkg :vulnerability ?V.
+    ?V :cvss ?Score.
+    ?Score math:greaterThan 7.0.
+    ?V :fixedBy ?Patch.
+} => {
+    ?S :urgentPatch ?Patch.
+}.

package/eyelang.d.ts

@@ -6,7 +6,6 @@ export interface EyelangRunOptions {
   proof?: boolean;
   why?: boolean;
   explain?: boolean;
-  inputFormat?: 'auto' | 'eyelang' | 'rdf' | 'rdf12' | 'turtle' | 'ttl' | 'nt' | 'n3' | string;
   [key: string]: unknown;
 }
 
@@ -32,14 +31,6 @@ export class Program {
 export function makeProgram(clauses?: unknown[], options?: EyelangRunOptions): Program;
 export function parseClauses(source: string, options?: EyelangRunOptions): unknown[];
 export function parseProgramText(source: string, options?: EyelangRunOptions): unknown[];
-export function parseRdfClauses(source: string, options?: EyelangRunOptions): unknown[];
-export function rdfToEyelang(source: string, options?: EyelangRunOptions): string;
-export function clausesToEyelang(clauses: unknown[]): string;
-export function rdfIri(value: string): unknown;
-export function rdfBlank(value: string): unknown;
-export function rdfLiteral(value: string, datatype?: string, language?: string): unknown;
-export function rdfTripleTerm(subject: unknown, predicate: unknown, object: unknown): unknown;
-export function rdfGoal(subject: unknown, predicate: unknown, object: unknown): unknown;
 
 export class Env {
   constructor(parent?: Env | null);
@@ -79,9 +70,6 @@ declare const eyelang: {
   makeProgram: typeof makeProgram;
   parseClauses: typeof parseClauses;
   parseProgramText: typeof parseProgramText;
-  parseRdfClauses: typeof parseRdfClauses;
-  rdfToEyelang: typeof rdfToEyelang;
-  clausesToEyelang: typeof clausesToEyelang;
   Solver: typeof Solver;
   Env: typeof Env;
   BuiltinRegistry: typeof BuiltinRegistry;

package/eyeling.js

@@ -6483,7 +6483,7 @@ async function main() {
       `Options:\n` +
       `  -a, --ast                    Print parsed AST as JSON and exit.\n` +
       `      --builtin <module.js>    Load a custom builtin module (repeatable).\n` +
-      `      --engine <n3|eyelang>    Select the N3 engine (default) or eyelang engine.\n` +
+      `      --engine <n3|eyelang>   Select the N3 engine (default) or eyelang engine.\n` +
       `  -d, --deterministic-skolem   Make log:skolem stable across reasoning runs.\n` +
       `  -e, --enforce-https          Rewrite http:// IRIs to https:// for log dereferencing builtins.\n` +
       `  -h, --help                   Show this help and exit.\n` +

package/index.d.ts

@@ -98,10 +98,6 @@ export interface EyelangRunOptions {
   why?: boolean;
   explain?: boolean;
   stats?: boolean;
-  rdf?: boolean;
-  rdf12?: boolean;
-  n3?: boolean;
-  inputFormat?: 'auto' | 'eyelang' | 'rdf' | 'rdf12' | 'turtle' | 'ttl' | 'nt' | 'n3' | string;
   args?: string[];
   maxBuffer?: number;
   [key: string]: unknown;

package/index.js

@@ -27,8 +27,7 @@ function normalizeEyelangSourceForTempFile(source) {
       typeof source.eyelang === 'string' ? source.eyelang
         : typeof source.prolog === 'string' ? source.prolog
           : typeof source.text === 'string' ? source.text
-            : typeof source.n3 === 'string' ? source.n3
-              : null;
+            : null;
     if (text !== null) return text;
   }
   throw new TypeError('reason({ engine: "eyelang" }, input): each source must be a string or an object with an eyelang/prolog/text field');
@@ -49,9 +48,6 @@ function reasonEyelangSync(opt = {}, input = '') {
 
   if (opt.proof || opt.why || opt.explain) args.push('--proof');
   if (opt.stats) args.push('--stats');
-  if (opt.rdf || opt.rdf12) args.push('--rdf');
-  if (opt.n3) args.push('--n3');
-  if (typeof opt.inputFormat === 'string' && opt.inputFormat) args.push('--input-format', opt.inputFormat);
   if (Array.isArray(opt.args)) args.push(...opt.args);
 
   const maxBuffer = Number.isFinite(opt.maxBuffer) ? opt.maxBuffer : 50 * 1024 * 1024;
@@ -85,7 +81,7 @@ function reasonEyelangSync(opt = {}, input = '') {
 }
 
 async function loadEyelangModule() {
-  return import(pathToFileURL(path.join(__dirname, 'lib', 'eyelang', 'index.mjs')).href);
+  return import(pathToFileURL(path.join(__dirname, 'lib', 'eyelang', 'index.js')).href);
 }
 
 async function runEyelang(input = '', opt = {}) {

package/lib/cli.js

@@ -805,7 +805,7 @@ async function main() {
       `Options:\n` +
       `  -a, --ast                    Print parsed AST as JSON and exit.\n` +
       `      --builtin <module.js>    Load a custom builtin module (repeatable).\n` +
-      `      --engine <n3|eyelang>    Select the N3 engine (default) or eyelang engine.\n` +
+      `      --engine <n3|eyelang>   Select the N3 engine (default) or eyelang engine.\n` +
       `  -d, --deterministic-skolem   Make log:skolem stable across reasoning runs.\n` +
       `  -e, --enforce-https          Rewrite http:// IRIs to https:// for log dereferencing builtins.\n` +
       `  -h, --help                   Show this help and exit.\n` +

package/lib/eyelang/bin.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 'use strict';
 
-import('./cli.mjs').then(({ main }) => main(process.argv.slice(2))).catch((error) => {
+import('./cli.js').then(({ main }) => main(process.argv.slice(2))).catch((error) => {
   console.error(`eyelang: ${error && error.message ? error.message : String(error)}`);
   process.exit(1);
 });

package/lib/eyelang/builtins/{aggregation.mjs → aggregation.js}

@@ -1,6 +1,6 @@
 // Aggregation builtins that run a inner goal and collect, count, sum, or select the best answers.
 // Each handler clones the solver so the inner goal can enumerate independently of the outer goal.
-import { compareTerms, copyResolved, isDecimalInteger, lexicalValue, listFromItems, numberTerm, numberTextFromDouble, parseFiniteNumber, unify } from '../term.mjs';
+import { compareTerms, copyResolved, isDecimalInteger, lexicalValue, listFromItems, numberTerm, numberTextFromDouble, parseFiniteNumber, unify } from '../term.js';
 
 export const aggregationBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{alphametic.mjs → alphametic.js}

@@ -2,7 +2,7 @@
 // It evaluates column constraints right-to-left, so examples such as
 // SEND+MORE=MONEY and DONALD+GERALD=ROBERT do not need to express digit search
 // with many relational select/3 and arithmetic goals.
-import { atom, deref, listFromItems, numberTerm, properListItems, unify } from '../term.mjs';
+import { atom, deref, listFromItems, numberTerm, properListItems, unify } from '../term.js';
 
 export const alphameticBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{arithmetic.mjs → arithmetic.js}

@@ -1,6 +1,6 @@
 // Numeric builtins for integer-preserving arithmetic, floating point functions, comparisons, and ranges.
 // The code keeps BigInt paths where possible so large eyelang integers remain exact.
-import { compareIntegerText, deref, isDecimalInteger, lexicalValue, numberTerm, numberTextFromDouble, parseFiniteNumber, unify } from '../term.mjs';
+import { compareIntegerText, deref, isDecimalInteger, lexicalValue, numberTerm, numberTextFromDouble, parseFiniteNumber, unify } from '../term.js';
 
 const unaryNames = ['neg', 'abs', 'sin', 'cos', 'asin', 'acos', 'rounded', 'log'];
 const binaryNames = ['add', 'sub', 'mul', 'div', 'mod', 'max', 'min', 'pow'];

package/lib/eyelang/builtins/{core.mjs → core.js}

@@ -1,6 +1,6 @@
 // Core relational builtins that do not naturally belong to arithmetic, strings, lists, or aggregation.
 // They are deterministic filters/projections and should avoid enumerating additional answers.
-import { stringTerm, lexicalValue, unify } from '../term.mjs';
+import { stringTerm, lexicalValue, unify } from '../term.js';
 
 function* ok(env) { yield env; }
 

package/lib/eyelang/builtins/{formula.mjs → formula.js}

@@ -1,6 +1,6 @@
 // Formula builtins that treat conjunctions as first-class data terms.
 // These are used by examples that construct or inspect rule bodies programmatically.
-import { atom, deref, isConjunction, unify } from '../term.mjs';
+import { atom, deref, isConjunction, unify } from '../term.js';
 
 export const formulaBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{lists.mjs → lists.js}

@@ -1,6 +1,6 @@
 // List builtins for proper lists, selection, membership, sorting, and indexing.
 // Several predicates support both checking and generation, so the argument modes are handled explicitly.
-import { compareTerms, copyResolved, deref, isCons, lexicalValue, listFromItems, numberTerm, properListItems, unify } from '../term.mjs';
+import { compareTerms, copyResolved, deref, isCons, lexicalValue, listFromItems, numberTerm, properListItems, unify } from '../term.js';
 
 export const listBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{matrix.mjs → matrix.js}

@@ -1,7 +1,7 @@
 // Small dense-matrix arithmetic builtins.
 // These are reusable numeric kernels for ground matrices; when arguments are not
 // ground proper numeric lists, user-defined matrix predicates remain available.
-import { deref, isDecimalInteger, listFromItems, numberTerm, numberTextFromDouble, parseFiniteNumber, properListItems, unify } from '../term.mjs';
+import { deref, isDecimalInteger, listFromItems, numberTerm, numberTextFromDouble, parseFiniteNumber, properListItems, unify } from '../term.js';
 
 export const matrixBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{number-theory.mjs → number-theory.js}

@@ -2,7 +2,7 @@
 // arithmetic algorithms with many small recursive rule calls.
 // The predicates are intentionally general: extended GCD, Collatz trajectories,
 // Kaprekar iteration counts, and Goldbach pair generation.
-import { deref, listFromItems, numberTerm, unify } from '../term.mjs';
+import { deref, listFromItems, numberTerm, unify } from '../term.js';
 
 export const numberTheoryBuiltins = {
   register(registry) {

package/lib/eyelang/builtins/{portfolio.mjs → portfolio.js}

@@ -1,7 +1,7 @@
 // Reusable bounded-subset optimizer for finite knapsack-style examples.
 // Items are p(Name, Value, Cost, Risk) terms; the builtin enumerates every
 // subset whose total cost/risk stays within the supplied caps.
-import { deref, listFromItems, numberTerm, properListItems, unify } from '../term.mjs';
+import { deref, listFromItems, numberTerm, properListItems, unify } from '../term.js';
 
 export const portfolioBuiltins = {
   register(registry) {