deriva 0.0.12 → 0.0.14

package/README.md

@@ -1,7 +1,7 @@
 # Deriva
 
 <p align="left">
-  <img src="docs/assets/deriva-logo.png" alt="Deriva logo" width="50">
+  <img src="docs/assets/deriva-logo.png" alt="Deriva logo" width="70">
 </p>
 
 [![npm version](https://img.shields.io/npm/v/deriva.svg)](https://www.npmjs.com/package/deriva)

package/conformance-report.md

@@ -1,4 +1,4 @@
-# Conformance Deriva report
+# Deriva conformance report
 
 This report summarizes the file-based conformance corpus under `test/conformance/`.
 

package/docs/guide.md

@@ -2,6 +2,9 @@
 
 This guide introduces Deriva, a small Horn-clause language and engine whose source syntax is Prolog-like but deliberately its own compact language for facts, rules, goals, answers, and proofs. Deriva works over ordinary terms, lists, arithmetic, strings, and finite search. Run it with the `deriva` CLI, or use `node bin/deriva.js` when working directly from a source checkout.
 
+This documentation uses **Deriva** for the project, language, and engine, and
+`deriva` for the npm package and CLI command.
+
 Programs write relations directly, for example `ancestor(pat, emma)` or `status(case1, accepted)`. Web identifiers can be written as ordinary quoted atoms that include angle brackets, for example `'<https://schema.org/name>'`, when a program needs explicit IRI-shaped names without prefix declarations. Deriva output is ordinary Deriva 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/2` declarations such as `materialize(answer, 2).` to focus output on selected predicates.
 
 Execution is automatically hybrid. Ordinary predicates use indexed
@@ -15,7 +18,7 @@ For the normative language definition, including lexical syntax, terms, clauses,
 ## Contents
 
 1. [Quick start](#quick-start)
-2. [Running deriva](#running-deriva)
+2. [Running the `deriva` CLI](#running-the-deriva-cli)
 3. [Default output](#default-output)
 4. [Writing programs](#writing-programs)
 5. [Aggregation helpers](#aggregation-helpers)
@@ -61,7 +64,7 @@ deriva --version
 
 `npm install -g .` is another local-checkout option if you want npm to install the package globally instead of linking it. Avoid hand-written `/usr/local/bin` symlinks unless you really need one; npm already reads the `bin` entry in `package.json` and creates the correct executable shim.
 
-## Running deriva
+## Running the `deriva` CLI
 
 The commands in this section use `deriva` for readability. In a source checkout where you have not run `npm link` or `npm install -g .`, replace `deriva` with `node bin/deriva.js`, or run the command through `npm exec --yes --package=. -- deriva`.
 
@@ -72,7 +75,7 @@ deriva --version
 deriva -v
 ```
 
-Run a program and let deriva print derived binary facts:
+Run a program and let Deriva print derived binary facts:
 
 ```sh
 deriva examples/ancestor.pl
@@ -85,7 +88,7 @@ deriva --proof examples/ancestor.pl
 deriva -p examples/ancestor.pl
 ```
 
-deriva-readable explanations are opt-in proof output. Each `why/2` fact contains a nested abstract proof term, and a blank line separates consecutive explanations. Using deriva syntax for explanations keeps them in the same language as the answers themselves: they are readable by humans, parseable by deriva, easy to test, and can be transformed or explained further like any other deriva data. For example:
+Deriva-readable explanations are opt-in proof output. Each `why/2` fact contains a nested abstract proof term, and a blank line separates consecutive explanations. Using Deriva syntax for explanations keeps them in the same language as the answers themselves: they are readable by humans, parseable by Deriva, easy to test, and can be transformed or explained further like any other Deriva data. For example:
 
 ```deriva
 type(socrates, mortal).
@@ -106,7 +109,7 @@ why(
 
 ```
 
-The explanation output can itself be read as deriva input; for example, another program can materialize `why/2` facts such as `why(type(socrates, mortal), Proof)`. `--proof` adds only these explanation facts; it does not change the answers found by the solver.
+The explanation output can itself be read as Deriva input; for example, another program can materialize `why/2` facts such as `why(type(socrates, mortal), Proof)`. `--proof` adds only these explanation facts; it does not change the answers found by the solver.
 
 ### Explanation cookbook
 
@@ -181,7 +184,7 @@ ancestor(X, Y) :- parent(X, Y).
 ancestor(X, Z) :- parent(X, Y), ancestor(Y, Z).
 ```
 
-By default, deriva asks for new ground consequences of selected output predicates, suppresses duplicates, excludes source facts, sorts the result, and prints Prolog facts:
+By default, Deriva asks for new ground consequences of selected output predicates, suppresses duplicates, excludes source facts, sorts the result, and prints Prolog facts:
 
 ```deriva
 ancestor(jan, emma).
@@ -213,7 +216,7 @@ answer(case1, accepted).
 
 ## Writing programs
 
-A good deriva program normally has three layers:
+A good Deriva program normally has three layers:
 
 1. source facts;
 2. helper predicates for calculation or search;
@@ -306,7 +309,7 @@ best_cycle(Cycle, Cost) :-
 
 ## Context data
 
-Comma terms can be data as well as conjunctions. deriva provides two context utilities:
+Comma terms can be data as well as conjunctions. Deriva provides two context utilities:
 
 ```deriva
 holds((name(alice, "Alice"), knows(alice, bob)), name(S, O)).
@@ -513,13 +516,13 @@ for f in examples/proof/*.pl; do
 done
 ```
 
-Run the full deriva suite:
+Run the full Deriva suite:
 
 ```sh
 npm run test:deriva
 ```
 
-The deriva corpus runner runs in this order: Conformance, Regression/API/White-box, Examples. Each section prints its own subtotal, followed by a suite-specific grand total. The suite checks the conformance cases derived from the language reference, supplemental regression/API/white-box checks, and every runnable example against its golden output.
+The Deriva corpus runner runs in this order: Conformance, Regression/API/White-box, Examples. Each section prints its own subtotal, followed by a suite-specific grand total. The suite checks the conformance cases derived from the language reference, supplemental regression/API/white-box checks, and every runnable example against its golden output.
 
 Run only one internal suite when you are iterating:
 
@@ -537,7 +540,7 @@ node test/run-conformance-report.mjs
 
 Release preparation runs the same report and writes [`conformance-report.md`](../conformance-report.md), so each published package carries a current conformance summary.
 
-The conformance suite lives in [`test/conformance/`](../test/conformance/) as a file-based deriva corpus. Positive cases pair `cases/<name>.pl` with exact expected stdout under `expected/<name>.pl`; negative cases pair `errors/<name>.pl` with exact expected error text under `expected-errors/<name>.txt`; warning cases pair `warnings/<name>.pl` with exact `--warnings` stdout and stderr files under `expected-warnings/`; proof cases pair `proofs/<name>.pl` with exact `--proof` output under `expected-proofs/`. Cases may be grouped in category directories such as `arithmetic/`, `strings/`, `lists/`, `terms/`, `atoms/`, `variables/`, `negation/`, and `syntax/`, so another implementation can reuse the same corpus as an executable language contract. The suite covers the standard language surface from the language reference, including reusable built-ins, standard errors, standard warnings, and the machine-readable `why/2` proof-output contract. The regression suite lives in [`test/run-regression.mjs`](../test/run-regression.mjs) and covers CLI regressions, the public JavaScript API, and white-box invariants for parser, unification, and indexing behavior.
+The conformance suite lives in [`test/conformance/`](../test/conformance/) as a file-based Deriva corpus. Positive cases pair `cases/<name>.pl` with exact expected stdout under `expected/<name>.pl`; negative cases pair `errors/<name>.pl` with exact expected error text under `expected-errors/<name>.txt`; warning cases pair `warnings/<name>.pl` with exact `--warnings` stdout and stderr files under `expected-warnings/`; proof cases pair `proofs/<name>.pl` with exact `--proof` output under `expected-proofs/`. Cases may be grouped in category directories such as `arithmetic/`, `strings/`, `lists/`, `terms/`, `atoms/`, `variables/`, `negation/`, and `syntax/`, so another implementation can reuse the same corpus as an executable language contract. The suite covers the standard language surface from the language reference, including reusable built-ins, standard errors, standard warnings, and the machine-readable `why/2` proof-output contract. The regression suite lives in [`test/run-regression.mjs`](../test/run-regression.mjs) and covers CLI regressions, the public JavaScript API, and white-box invariants for parser, unification, and indexing behavior.
 
 ## Development and release
 
@@ -570,7 +573,7 @@ The `preversion` script reruns the full test suite and refreshes [`conformance-r
 
 ## Relationship to Eyeling
 
-[Eyeling](https://github.com/eyereasoner/eyeling) and deriva share the same goal of small, inspectable rule-based reasoning in JavaScript, but they make different language and implementation trade-offs.
+[Eyeling](https://github.com/eyereasoner/eyeling) and Deriva share the same goal of small, inspectable rule-based reasoning in JavaScript, but they make different language and implementation trade-offs.
 
 Eyeling is the RDF/Notation3 member of the family. It reads N3-style triples, quoted formulas, forward rules written with `=>`, backward rules written with `<=`, RDF terms, RDF-JS data, and RDF-oriented streams. That makes it the better fit when data interchange with RDF/N3 tools is the main requirement.
 
@@ -581,13 +584,13 @@ A useful rule of thumb:
 | Use case | Prefer | Why |
 | --- | --- | --- |
 | RDF/N3 data, triples, prefixes, graph terms, RDF-JS, RDF message streams | Eyeling | The surface language and APIs are RDF/Notation3-native. |
-| Compact relational rules over ordinary terms, lists, arithmetic, and finite search | deriva | The syntax is shorter for non-RDF relation programs and output is ordinary facts. |
+| Compact relational rules over ordinary terms, lists, arithmetic, and finite search | Deriva | The syntax is shorter for non-RDF relation programs and output is ordinary facts. |
 | Human-auditable derivations | Either | Both can emit proof explanations when requested. |
-| Large generated Horn-clause workloads | deriva | The engine specializes in predicate/arity indexing, scalar argument indexes, fast fact paths, and materialized output goals. |
+| Large generated Horn-clause workloads | Deriva | The engine specializes in predicate/arity indexing, scalar argument indexes, fast fact paths, and materialized output goals. |
 
-On local smoke benchmarks, deriva is substantially faster on large generated Horn-clause and recursion-heavy workloads. These numbers are 5-run medians with stdout redirected to `/dev/null`, using Node.js `v22.16.0`, deriva from this checkout, and Eyeling package version `1.34.6` with its default output mode. The ratio is `Eyeling median / deriva median`, so larger numbers mean deriva was faster.
+On local smoke benchmarks, Deriva is substantially faster on large generated Horn-clause and recursion-heavy workloads. These numbers are 5-run medians with stdout redirected to `/dev/null`, using Node.js `v22.16.0`, Deriva from this checkout, and Eyeling package version `1.34.6` with its default output mode. The ratio is `Eyeling median / Deriva median`, so larger numbers mean Deriva was faster.
 
-| Example | deriva median | Eyeling median | Ratio |
+| Example | Deriva median | Eyeling median | Ratio |
 | --- | ---: | ---: | ---: |
 | `fundamental-theorem-arithmetic` | `0.16 sec` | `2.00 sec` | `12.66x` |
 | `deep-taxonomy-100000` | `1.69 sec` | `4.72 sec` | `2.79x` |
@@ -597,13 +600,13 @@ On local smoke benchmarks, deriva is substantially faster on large generated Hor
 
 Treat these as smoke comparisons rather than a formal benchmark: hardware, Node.js version, package version, CLI startup, and output mode all matter.
 
-The projects are therefore complementary rather than replacements for each other: Eyeling optimizes for Semantic Web interoperability and N3 expressiveness; deriva optimizes for a small standard-looking relational rule language and fast finite goal-directed execution.
+The projects are therefore complementary rather than replacements for each other: Eyeling optimizes for Semantic Web interoperability and N3 expressiveness; Deriva optimizes for a small standard-looking relational rule language and fast finite goal-directed execution.
 
 ## Performance notes
 
 Use `-s` or `--stats` for a quick sanity check while optimizing solver changes. It prints counters such as `solve_goals_calls`, `unify_calls`, `deterministic_rule_expansions`, `candidate_lists_selected`, `clause_candidates_considered`, `clauses_tried`, `max_depth`, and `max_solver_call_depth` to stderr, leaving normal output stable for golden-file tests. The `max_solver_call_depth` counter is especially useful for browser regressions, where the VM call stack can be tighter than a command-line run. Use `-w` or `--warnings` separately when you want portability diagnostics without enabling stricter parsing.
 
-deriva hashes predicate groups by name and arity, then indexes clauses by scalar argument values. It also builds two-argument composite indexes for scalar pairs and probes those composite indexes without per-lookup heap allocation. This helps both large generated programs with many predicates and selective queries such as:
+Deriva hashes predicate groups by name and arity, then indexes clauses by scalar argument values. It also builds two-argument composite indexes for scalar pairs and probes those composite indexes without per-lookup heap allocation. This helps both large generated programs with many predicates and selective queries such as:
 
 ```deriva
 edge(g1, a, X).
@@ -611,7 +614,7 @@ path(a, Y).
 status(Case, accepted).
 ```
 
-Ground facts use a fast path that avoids freshening and copying a rule body. Recursive-predicate detection uses an explicit work stack, which keeps large predicate chains safer in the browser. deriva automatically tables positive recursive groups, including dependencies reached through supported meta-goals and directly materialized relations. Cyclic calls iterate to an answer fixed point before replay. Recursive components containing a negative dependency retain guarded ordinary resolution because positive fixed-point tabling is not a semantics for unstratified negation. The engine also infers common structurally decreasing input positions; calls with an unbound structural input and fully open calls retain ordinary resolution rather than trying to materialize a potentially infinite relation. Authors do not need a search-control declaration.
+Ground facts use a fast path that avoids freshening and copying a rule body. Recursive-predicate detection uses an explicit work stack, which keeps large predicate chains safer in the browser. Deriva automatically tables positive recursive groups, including dependencies reached through supported meta-goals and directly materialized relations. Cyclic calls iterate to an answer fixed point before replay. Recursive components containing a negative dependency retain guarded ordinary resolution because positive fixed-point tabling is not a semantics for unstratified negation. The engine also infers common structurally decreasing input positions; calls with an unbound structural input and fully open calls retain ordinary resolution rather than trying to materialize a potentially infinite relation. Authors do not need a search-control declaration.
 
 Predicates can also carry advisory mode and determinism declarations for documentation and host tooling:
 

package/docs/language-reference.md

@@ -29,11 +29,12 @@
   - [7.2 Failure](#72-failure)
   - [7.3 Finite search expectation](#73-finite-search-expectation)
 - [8. Logical reading: Herbrand semantics](#8-logical-reading-herbrand-semantics)
-  - [8.1 Variables and quantification](#81-variables-and-quantification)
-  - [8.2 Equality, identity, and unification](#82-equality-identity-and-unification)
-  - [8.3 Goal-directed execution versus model-theoretic meaning](#83-goal-directed-execution-versus-model-theoretic-meaning)
-  - [8.4 Built-ins and operational extensions](#84-built-ins-and-operational-extensions)
-  - [8.5 Stratified negation](#85-stratified-negation)
+  - [8.1 Why use a Herbrand interpretation?](#81-why-use-a-herbrand-interpretation)
+  - [8.2 Variables and quantification](#82-variables-and-quantification)
+  - [8.3 Equality, identity, and unification](#83-equality-identity-and-unification)
+  - [8.4 Goal-directed execution versus model-theoretic meaning](#84-goal-directed-execution-versus-model-theoretic-meaning)
+  - [8.5 Built-ins and operational extensions](#85-built-ins-and-operational-extensions)
+  - [8.6 Stratified negation](#86-stratified-negation)
 - [9. Standard built-in predicates](#9-standard-built-in-predicates)
   - [9.1 Equality and unification](#91-equality-and-unification)
   - [9.2 Arithmetic](#92-arithmetic)
@@ -50,7 +51,7 @@
   - [11.1 Automatic hybrid reasoning](#111-automatic-hybrid-reasoning)
   - [11.2 Default-output materialization](#112-default-output-materialization)
   - [11.3 Advisory modes and determinism](#113-advisory-modes-and-determinism)
-- [12. deriva Sockets](#12-deriva-sockets)
+- [12. Deriva Sockets](#12-deriva-sockets)
   - [12.1 Socket vocabulary](#121-socket-vocabulary)
   - [12.2 Socket example](#122-socket-example)
   - [12.3 Sockets and AI agents](#123-sockets-and-ai-agents)
@@ -67,7 +68,7 @@
 
 ## Abstract
 
-Deriva is a compact definite-clause language whose surface syntax is Prolog-like term and clause syntax with deliberate deriva choices for rule-based programs over ordinary terms, lists, arithmetic, strings, and finite search. A Deriva program is a finite sequence of facts and Horn clauses. The underlying declarative semantics of the pure language is **Herbrand semantics**: constants, compound terms, and lists denote themselves, and predicates denote sets of ground atomic formulas over those terms. Evaluation is goal-directed: goals are solved by unification against facts, rules, and a fixed set of built-in predicates.
+Deriva is a compact definite-clause language whose surface syntax is Prolog-like term and clause syntax with deliberate Deriva choices for rule-based programs over ordinary terms, lists, arithmetic, strings, and finite search. A Deriva program is a finite sequence of facts and Horn clauses. The underlying declarative semantics of the pure language is **Herbrand semantics**: constants, compound terms, and lists denote themselves, and predicates denote sets of ground atomic formulas over those terms. Evaluation is goal-directed: goals are solved by unification against facts, rules, and a fixed set of built-in predicates.
 
 Deriva is intentionally smaller than ISO Prolog. It supports compact Horn-clause reasoning, list processing, arithmetic examples, finite search, and context data, without operators, cut, modules, dynamic predicates, DCGs, zero-arity compound syntax, or a complete ISO standard library.
 
@@ -89,7 +90,7 @@ A **goal** is an atomic formula, a built-in call, or a comma conjunction.
 
 A **source fact** is a fact written directly in the input program. A **new derivation** is a ground consequence found through at least one rule and not merely repeated from the source facts.
 
-The **Herbrand universe** of a program is the set of all ground deriva terms constructible from the constants and functors in the program, together with the built-in list constructors `[]` and `./2` where lists are used. The **Herbrand base** is the set of all ground atomic formulas whose predicate symbols occur in the program and whose arguments are terms from the Herbrand universe.
+The **Herbrand universe** of a program is the set of all ground Deriva terms constructible from the constants and functors in the program, together with the built-in list constructors `[]` and `./2` where lists are used. The **Herbrand base** is the set of all ground atomic formulas whose predicate symbols occur in the program and whose arguments are terms from the Herbrand universe.
 
 ## 2. Design goals
 
@@ -329,7 +330,7 @@ pair(3, nested(atom, [x, y]))
 
 The same concrete syntax is used for atomic formulas when the compound appears as a fact, rule head, or goal. In `parent(pat, jan).`, `parent/2` is a predicate symbol and the whole expression is an atomic formula. In `value(x, parent(pat, jan)).`, the inner `parent(pat, jan)` is ordinary compound data.
 
-The functor or predicate name is fixed syntactically and is written as an atom constant. deriva does not support variables in predicate or functor position.
+The functor or predicate name is fixed syntactically and is written as an atom constant. Deriva does not support variables in predicate or functor position.
 
 ### 5.4 Lists
 
@@ -375,7 +376,7 @@ Clauses with the same predicate name and arity define one predicate group. Predi
 
 ## 7. Goals and proof search
 
-Goals are solved left-to-right. For a user-defined atomic-formula goal, deriva selects candidate clauses by predicate name, arity, and available indexes. A candidate clause is freshened, its head is unified with the goal, and then its body is solved.
+Goals are solved left-to-right. For a user-defined atomic-formula goal, Deriva selects candidate clauses by predicate name, arity, and available indexes. A candidate clause is freshened, its head is unified with the goal, and then its body is solved.
 
 A conjunction goal succeeds when all conjunct goals succeed in order. An answer is printed as the resolved answer term followed by a period.
 
@@ -385,11 +386,11 @@ Unification follows the ordinary first-order term structure used by the language
 
 ### 7.2 Failure
 
-A goal fails when no built-in case or user clause can prove it. deriva has no exception term language; parse errors and resource failures are implementation errors reported to the host.
+A goal fails when no built-in case or user clause can prove it. Deriva has no exception term language; parse errors and resource failures are implementation errors reported to the host.
 
 ### 7.3 Finite search expectation
 
-Programs and selected output goals SHOULD be written so the relevant search space is finite. deriva includes recursion guards and tabling support, but it is not required to terminate for arbitrary recursive logic programs.
+Programs and selected output goals SHOULD be written so the relevant search space is finite. Deriva includes recursion guards and tabling support, but it is not required to terminate for arbitrary recursive logic programs.
 
 ## 8. Logical reading: Herbrand semantics
 
@@ -413,11 +414,58 @@ is read universally over Herbrand terms: for every substitution of `X`, `Y`, and
 
 Equivalently, the least Herbrand model is obtained by repeatedly applying the immediate-consequence operation: start with the source facts, add every ground rule head whose ground body is already true, and continue to the least fixed point. This definition is mathematical; an implementation does not have to compute the model bottom-up.
 
-### 8.1 Variables and quantification
+### 8.1 Why use a Herbrand interpretation?
 
-Variables do not range over external objects, records, pointers, or host-language values. In the logical reading, variables range over Herbrand terms. A rule is implicitly universally quantified over its variables. A selected goal is existential in the usual logic-programming sense: deriva searches for substitutions of its variables by Herbrand terms that make the goal true with respect to the program.
+Herbrand semantics is not an alternative to model theory: a Herbrand
+interpretation is a particular kind of Tarskian structure. Deriva chooses this
+restricted structure because programs manipulate symbolic terms directly and
+need their identity to be predictable without a separate set of domain axioms.
 
-deriva has no blank nodes and no existential variables in rule heads. Existential-style consequences SHOULD be represented by explicit Herbrand witness terms written directly in rule heads:
+Consider this program:
+
+```deriva
+materialize(different, 2).
+
+different(alice, bob) :-
+  neq(alice, bob).
+
+different(ticket(alice), ticket(bob)) :-
+  neq(ticket(alice), ticket(bob)).
+```
+
+It produces:
+
+```deriva
+different(alice, bob).
+different(ticket(alice), ticket(bob)).
+```
+
+In an unrestricted Tarskian interpretation, the constants `alice` and `bob`
+may denote the same domain element unless a distinctness axiom says otherwise.
+Even if they denote different elements, the function denoted by `ticket` need
+not be injective, so `ticket(alice)` and `ticket(bob)` may still denote the same
+element. A conventional first-order theory must add unique-name and free-
+constructor axioms to rule out those interpretations.
+
+In the Herbrand universe, `alice` and `bob` are different because they are
+different ground terms. Compound terms are free constructors, so
+`ticket(alice)` and `ticket(bob)` are also different. This makes unification,
+read-back, generated witness terms, and proof explanations agree on identity by
+construction. The program can therefore treat syntax as inspectable data
+without first defining an external domain and an interpretation function.
+
+This choice does not claim that differently named terms must denote different
+entities in every application. When two names refer to the same real-world
+entity, a Deriva program should represent that relationship explicitly, for
+example with `same_as/2`, or normalize both names to one canonical term. The
+Herbrand layer keeps the representation unambiguous; application rules state
+the intended real-world equivalences.
+
+### 8.2 Variables and quantification
+
+Variables do not range over external objects, records, pointers, or host-language values. In the logical reading, variables range over Herbrand terms. A rule is implicitly universally quantified over its variables. A selected goal is existential in the usual logic-programming sense: Deriva searches for substitutions of its variables by Herbrand terms that make the goal true with respect to the program.
+
+Deriva has no blank nodes and no existential variables in rule heads. Existential-style consequences SHOULD be represented by explicit Herbrand witness terms written directly in rule heads:
 
 ```deriva
 has_parent(Child, parent_of(Child)) :-
@@ -429,27 +477,27 @@ registration(Student, Course, registration_of(Student, Course)) :-
 
 These rules may derive `parent_of(alice)` or `registration_of(alice, logic)` as ordinary visible Herbrand terms. The witness is deterministic: the same functor and inputs produce the same term, while different inputs produce different terms by normal syntactic identity. This is the practical executable form of existential-style consequences in Deriva; it does not introduce hidden blank nodes or special quantifier syntax.
 
-### 8.2 Equality, identity, and unification
+### 8.3 Equality, identity, and unification
 
 Because the domain is Herbrand, equality in the pure language is syntactic identity of terms after substitution. Two distinct atom constants are distinct. Two compound terms are equal only when they have the same functor, the same arity, and pairwise equal arguments. Lists follow the same rule through their `[]` and `./2` representation.
 
-Operationally, deriva uses first-order unification to find substitutions. The implementation does not perform an occurs check, so cyclic terms are not part of the portable Herbrand reading even if a particular implementation can temporarily construct recursive bindings internally. Portable programs SHOULD avoid relying on occurs-check-sensitive cases such as `eq(X, f(X))`.
+Operationally, Deriva uses first-order unification to find substitutions. The implementation does not perform an occurs check, so cyclic terms are not part of the portable Herbrand reading even if a particular implementation can temporarily construct recursive bindings internally. Portable programs SHOULD avoid relying on occurs-check-sensitive cases such as `eq(X, f(X))`.
 
-### 8.3 Goal-directed execution versus model-theoretic meaning
+### 8.4 Goal-directed execution versus model-theoretic meaning
 
-deriva's CLI and library evaluator are goal-directed. They try to prove requested goals by resolving them against facts, rules, and built-ins, using clause order, goal order, indexing, tabling, and deterministic built-in execution. This operational strategy is intended to enumerate answers that are true in the least Herbrand model for the pure Horn-clause fragment, but it is not a complete bottom-up model enumerator. Non-terminating recursion or infinite generators can prevent an answer from being found even when the answer belongs to the least Herbrand model.
+Deriva's CLI and library evaluator are goal-directed. They try to prove requested goals by resolving them against facts, rules, and built-ins, using clause order, goal order, indexing, tabling, and deterministic built-in execution. This operational strategy is intended to enumerate answers that are true in the least Herbrand model for the pure Horn-clause fragment, but it is not a complete bottom-up model enumerator. Non-terminating recursion or infinite generators can prevent an answer from being found even when the answer belongs to the least Herbrand model.
 
 Default CLI output is also a host behavior, not a separate semantics. It asks broad materialization goals, suppresses duplicates, excludes source facts, keeps ground answers, and prints selected consequences. Embedders can still access the goal-directed solver directly through the implementation API.
 
-### 8.4 Built-ins and operational extensions
+### 8.5 Built-ins and operational extensions
 
 Built-ins are specified relations or operations added to the Herbrand core. A built-in call in a goal has the syntax of an atomic formula, but its success relation is specified procedurally here rather than by source clauses. Some built-ins, such as `eq/2`, `append/3`, `member/2`, and `length/2`, can be understood as relations over Herbrand terms. Others, such as arithmetic, string matching, date/time predicates, aggregation, `once/1`, and negation-as-failure, are operational extensions whose behavior is defined by this specification rather than by pure least-Herbrand-model semantics alone.
 
-Arithmetic and string built-ins do not introduce a separate semantic universe. They inspect the lexical values of already represented Herbrand constants and, when they succeed, bind output arguments to deriva terms such as numbers, strings, or atom constants. For example, `add(2, 3, X)` may bind `X` to the number term `5`; it does not mean that variables range over host-language numbers outside the Herbrand universe.
+Arithmetic and string built-ins do not introduce a separate semantic universe. They inspect the lexical values of already represented Herbrand constants and, when they succeed, bind output arguments to Deriva terms such as numbers, strings, or atom constants. For example, `add(2, 3, X)` may bind `X` to the number term `5`; it does not mean that variables range over host-language numbers outside the Herbrand universe.
 
 Negation-as-failure `not(Goal)` is especially operational: it succeeds when the current goal-directed search finds no solution for `Goal`. It is not classical negation and should not be read as adding negative facts to the Herbrand model. Programs using negation SHOULD keep the negated goal sufficiently ground and finite.
 
-### 8.5 Stratified negation
+### 8.6 Stratified negation
 
 Portable programs using user-defined predicates under `not/1` SHOULD be **stratified**. A program is stratified when no predicate depends negatively on itself, either directly or through a cycle of other predicate dependencies. In a stratified program, predicates can be assigned strata so that positive dependencies stay in the same or a lower stratum and negative dependencies point strictly to a lower stratum.
 
@@ -544,7 +592,7 @@ Comparisons interpret numeric-looking terms numerically. Other scalar terms are
 | `lowercase(Text, Out)`, `uppercase(Text, Out)`, `trim(Text, Out)` | Text normalization helpers. |
 | `number_string(Number, String)` | Converts a number to a string or parses a numeric string into a number. |
 | `atom_string(Atom, String)` | Converts between atom constants and strings. |
-| `term_string(Term, String)` | Renders a ground term as its deriva source string. |
+| `term_string(Term, String)` | Renders a ground term as its Deriva source string. |
 
 ### 9.7 Lists
 
@@ -616,15 +664,15 @@ The first goal can yield `holds((name(alice, "Alice"), knows(alice, bob)), name(
 
 ## 10. Implementation-specific built-ins
 
-Implementations MAY provide additional built-ins beyond the standard predicates listed above. Such built-ins are **implementation-specific built-ins**. They are useful for embedding deriva in particular host environments, exposing efficient finite-domain solvers, or providing domain-specific relations for applications.
+Implementations MAY provide additional built-ins beyond the standard predicates listed above. Such built-ins are **implementation-specific built-ins**. They are useful for embedding Deriva in particular host environments, exposing efficient finite-domain solvers, or providing domain-specific relations for applications.
 
-Implementation-specific built-ins are not required for conformance to this specification. A portable deriva program SHOULD NOT depend on one unless the target implementation explicitly documents it.
+Implementation-specific built-ins are not required for conformance to this specification. A portable Deriva program SHOULD NOT depend on one unless the target implementation explicitly documents it.
 
 An implementation-specific built-in SHOULD obey the same surface-language discipline as standard built-ins:
 
 - it is called using ordinary atomic-formula syntax, for example `some_extension(A, B)`;
-- its arguments and results are deriva terms from the Herbrand universe;
-- it succeeds, fails, and binds variables as a relation over deriva terms;
+- its arguments and results are Deriva terms from the Herbrand universe;
+- it succeeds, fails, and binds variables as a relation over Deriva terms;
 - 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.
 
@@ -638,7 +686,7 @@ Declarations are written as ordinary facts, but the host treats them specially.
 
 ### 11.1 Automatic hybrid reasoning
 
-deriva automatically combines ordinary goal-directed resolution with tabled
+Deriva automatically combines ordinary goal-directed resolution with tabled
 resolution. Predicate dependency cycles are detected when a program is loaded,
 including dependencies inside conjunctions, negation, `once/1`, `forall/2`, and
 aggregation goals. Positive recursive predicate groups, including directly
@@ -702,9 +750,9 @@ The example documents the common checking/generation mode where the list is supp
 
 ## 12. Deriva Sockets
 
-A **deriva Socket** is a declared semantic opening in a deriva program where facts, rules, tools, datasets, or agents can plug in knowledge through an explicit contract while preserving deriva-readable reasoning and explanations.
+A **Deriva Socket** is a declared semantic opening in a Deriva program where facts, rules, tools, datasets, or agents can plug in knowledge through an explicit contract while preserving Deriva-readable reasoning and explanations.
 
-The term follows the ordinary socket pattern: a socket defines a place where a matching provider can connect. In deriva, the matching part is knowledge. A socket identifies what shape of knowledge a program expects; a plug identifies which provider supplies it. This separates reasoning logic from knowledge providers and makes composition boundaries visible as deriva data.
+The term follows the ordinary socket pattern: a socket defines a place where a matching provider can connect. In Deriva, the matching part is knowledge. A socket identifies what shape of knowledge a program expects; a plug identifies which provider supplies it. This separates reasoning logic from knowledge providers and makes composition boundaries visible as Deriva data.
 
 In this specification, sockets are a portable **programming pattern** expressed with ordinary facts. The core solver does not give `socket/2`, `plug/2`, `provides/1`, or `requires/1` special proof-search behavior unless a host explicitly documents such an extension. Because they are ordinary facts, socket declarations remain readable, inspectable, explainable, and safe to ignore by hosts that do not validate them.
 
@@ -719,7 +767,7 @@ provides(Signature).
 requires(Signature).
 ```
 
-`Name` and `Provider` are ordinary deriva terms, usually atom constants. `Contract` is an ordinary deriva term that describes the expected or offered knowledge. A portable signature form is:
+`Name` and `Provider` are ordinary Deriva terms, usually atom constants. `Contract` is an ordinary Deriva term that describes the expected or offered knowledge. A portable signature form is:
 
 ```deriva
 predicate(Predicatename, Arity)
@@ -755,21 +803,21 @@ ancestor(X, Z) :-
     ancestor(Y, Z).
 ```
 
-The `ancestor/2` rules do not depend on a particular storage mechanism for `parent/2`. In a small test, the provider may be the same file. In an embedded host, it may be a database adapter, a document extractor, a remote service, or another deriva module. The socket facts make that boundary explicit without changing the logical meaning of the rules.
+The `ancestor/2` rules do not depend on a particular storage mechanism for `parent/2`. In a small test, the provider may be the same file. In an embedded host, it may be a database adapter, a document extractor, a remote service, or another Deriva module. The socket facts make that boundary explicit without changing the logical meaning of the rules.
 
-When deriva derives `ancestor(pat, emma)`, the answer explanation can still refer to the source clauses that were actually used, for example facts for `parent/2` and rules for `ancestor/2`. The socket facts add an inspectable description of where such knowledge is intended to enter.
+When Deriva derives `ancestor(pat, emma)`, the answer explanation can still refer to the source clauses that were actually used, for example facts for `parent/2` and rules for `ancestor/2`. The socket facts add an inspectable description of where such knowledge is intended to enter.
 
 ### 12.3 Sockets and AI agents
 
-deriva Sockets are especially useful for AI-facing systems. An AI agent can extract or propose candidate claims, but those claims should enter a reasoning program as explicit deriva facts or rules through a declared socket rather than as opaque text. deriva can then check the claims against other facts and rules, derive consequences, and optionally return ordinary `why/2` explanations.
+Deriva Sockets are especially useful for AI-facing systems. An AI agent can extract or propose candidate claims, but those claims should enter a reasoning program as explicit Deriva facts or rules through a declared socket rather than as opaque text. Deriva can then check the claims against other facts and rules, derive consequences, and optionally return ordinary `why/2` explanations.
 
-This gives a clear division of labor: AI can help generate, translate, and connect knowledge; deriva can represent, check, and explain the reasoning; sockets define the boundary between them.
+This gives a clear division of labor: AI can help generate, translate, and connect knowledge; Deriva can represent, check, and explain the reasoning; sockets define the boundary between them.
 
 ## 13. Output and read-back profile
 
 Normal answer output prints one resolved answer term followed by a period. Strings are double-quoted; atom constants are quoted when needed; lists use list syntax; compound terms use functor notation. Host interfaces MAY provide an option such as `--proof` to add `why/2` explanation facts; this option MUST NOT change the answers found. Host interfaces MAY also provide a non-fatal warning option such as `--warnings` for portability diagnostics such as unstratified negation; this option MUST NOT change the answers found.
 
-Output SHOULD be accepted as deriva input when it contains only supported term syntax. Explanations are ordinary deriva facts, so answer output can be read back and processed by deriva.
+Output SHOULD be accepted as Deriva input when it contains only supported term syntax. Explanations are ordinary Deriva facts, so answer output can be read back and processed by Deriva.
 
 Default host output behavior is:
 
@@ -783,11 +831,11 @@ Default host output behavior is:
 
 ### 13.1 Explanation output
 
-When proof output is enabled, each answer SHOULD be followed by a machine-readable `why/2` fact. Explanation output is ordinary deriva syntax whose second argument is a nested abstract proof term such as `proof(goal(G), by(Method), bindings(Bindings), uses(Proofs))`; implementations SHOULD print `goal(...)` and `by(...)` on separate lines for readability. A proof term preserves the answer goal, derivation method, relevant bindings, and nested uses while omitting proof IDs. User clauses SHOULD be referenced explicitly as `fact(Filename, clause(N))` or `rule(Filename, clause(N))`, where `N` is the 1-based clause number within that source. Built-ins SHOULD be referenced as `builtin(Name, Arity)` because they do not come from source clauses. Explanation output is outside the logical semantics of the input program and MUST NOT change the set of answers.
+When proof output is enabled, each answer SHOULD be followed by a machine-readable `why/2` fact. Explanation output is ordinary Deriva syntax whose second argument is a nested abstract proof term such as `proof(goal(G), by(Method), bindings(Bindings), uses(Proofs))`; implementations SHOULD print `goal(...)` and `by(...)` on separate lines for readability. A proof term preserves the answer goal, derivation method, relevant bindings, and nested uses while omitting proof IDs. User clauses SHOULD be referenced explicitly as `fact(Filename, clause(N))` or `rule(Filename, clause(N))`, where `N` is the 1-based clause number within that source. Built-ins SHOULD be referenced as `builtin(Name, Arity)` because they do not come from source clauses. Explanation output is outside the logical semantics of the input program and MUST NOT change the set of answers.
 
 ## 14. Conformance
 
-A conforming deriva implementation supports the standard language described above as one conformance surface rather than as separate core and extension profiles. This includes:
+A conforming Deriva implementation supports the standard language described above as one conformance surface rather than as separate core and extension profiles. This includes:
 
 - lexical syntax described above;
 - facts and definite clauses;
@@ -804,11 +852,11 @@ A conforming deriva implementation supports the standard language described abov
 
 Browser execution, package layout, CLI URL loading, and any implementation-specific built-ins described in host documentation are outside this conformance surface unless separately standardized.
 
-Conformance cases live in the repository under `test/conformance/`. They are run by `npm test` before the example suite, and can be run alone with `node test/run-conformance.mjs`. Positive cases have input programs under `test/conformance/cases/` and exact expected standard-output files under `test/conformance/expected/`; both use `.pl` so expected output remains deriva-readable. Expected-error cases live under `test/conformance/errors/` with exact messages under `test/conformance/expected-errors/`. Expected-warning cases live under `test/conformance/warnings/` with exact `--warnings` stdout and stderr files under `test/conformance/expected-warnings/`. Proof cases live under `test/conformance/proofs/` with exact explanation output under `test/conformance/expected-proofs/`. The corpus is grouped by language area, including arithmetic, strings, lists, terms, atoms, variables, negation, declarations, materialization, rules, syntax, and errors.
+Conformance cases live in the repository under `test/conformance/`. They are run by `npm test` before the example suite, and can be run alone with `node test/run-conformance.mjs`. Positive cases have input programs under `test/conformance/cases/` and exact expected standard-output files under `test/conformance/expected/`; both use `.pl` so expected output remains Deriva-readable. Expected-error cases live under `test/conformance/errors/` with exact messages under `test/conformance/expected-errors/`. Expected-warning cases live under `test/conformance/warnings/` with exact `--warnings` stdout and stderr files under `test/conformance/expected-warnings/`. Proof cases live under `test/conformance/proofs/` with exact explanation output under `test/conformance/expected-proofs/`. The corpus is grouped by language area, including arithmetic, strings, lists, terms, atoms, variables, negation, declarations, materialization, rules, syntax, and errors.
 
 ## 15. Relationship to ISO Prolog
 
-deriva source is intended to be familiar to Prolog readers and uses ISO Prolog-compatible variable and quoted-atom spelling, but deriva is not ISO Prolog. Notable differences include:
+Deriva source is intended to be familiar to Prolog readers and uses ISO Prolog-compatible variable and quoted-atom spelling, but Deriva is not ISO Prolog. Notable differences include:
 - no operators or operator declarations;
 - no zero-arity compound syntax such as `nil()`;
 - no cut;
@@ -819,7 +867,7 @@ deriva source is intended to be familiar to Prolog readers and uses ISO Prolog-c
 - no variables in functor or predicate position;
 - no occurs check in unification.
 
-Programs intended to be portable to deriva SHOULD use uppercase or underscore variables, avoid ISO-specific features that deriva does not implement, and keep terms explicit. Atom names that are not plain lowercase-starting names or graphic atom tokens SHOULD be written as quoted atoms, for example `'a-b'` or `'<abc>'`.
+Programs intended to be portable to Deriva SHOULD use uppercase or underscore variables, avoid ISO-specific features that Deriva does not implement, and keep terms explicit. Atom names that are not plain lowercase-starting names or graphic atom tokens SHOULD be written as quoted atoms, for example `'a-b'` or `'<abc>'`.
 
 ## 16. Examples
 

package/package.json

@@ -3,7 +3,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "0.0.12",
+  "version": "0.0.14",
   "description": "Deriva turns facts and rules into answers and proofs.",
   "type": "module",
   "main": "./index.js",

package/src/builtins/arithmetic.js

@@ -1,5 +1,5 @@
 // Numeric builtins for integer-preserving arithmetic, floating point functions, comparisons, and ranges.
-// The code keeps BigInt paths where possible so large deriva integers remain exact.
+// The code keeps BigInt paths where possible so large Deriva integers remain exact.
 import { compareIntegerText, deref, isDecimalInteger, lexicalValue, numberTerm, numberTextFromDouble, parseFiniteNumber, unify } from '../term.js';
 
 const unaryNames = ['neg', 'abs', 'sin', 'cos', 'tan', 'asin', 'acos', 'sqrt', 'floor', 'ceiling', 'trunc', 'rounded', 'exp', 'log'];
@@ -200,7 +200,7 @@ function nextDown(value) {
 function logCompat(input) {
   const value = Math.log(input);
   // V8 and glibc libm differ by one ulp for a few values reached by the
-  // Newton-Raphson example. Align this pure-JS port with the native deriva
+  // Newton-Raphson example. Align this pure-JS port with the native Deriva
   // reference while leaving ordinary log(1), log(2), log(10), and log(e) alone.
   if (input > 2.5 && input < 2.7182818 && value > 0.95 && value < 1.0) return nextUp(value);
   if (input > 2.7182818 && input < 2.718281828459 && value > 0.999999999999 && value < 1.0) return nextDown(value);

package/src/builtins/terms.js

@@ -1,4 +1,4 @@
-// Term-inspection builtins for reusable meta-programming over deriva terms.
+// Term-inspection builtins for reusable meta-programming over Deriva terms.
 import { atom, compound, deref, listFromItems, lexicalValue, numberTerm, properListItems, stringTerm, unify } from '../term.js';
 
 export const termBuiltins = {

package/src/cli.js

@@ -1,4 +1,4 @@
-// Command-line interface for deriva.
+// Command-line interface for Deriva.
 // It loads programs from files, URLs, or stdin, then materializes derived output predicates.
 import fs from 'node:fs/promises';
 import path from 'node:path';

package/src/explain.js

@@ -1,6 +1,6 @@
-// deriva proof output helpers.
+// Deriva proof output helpers.
 // The explanation printer replays a successful goal against the program and emits
-// ordinary deriva facts with nested proof terms.  Explanations are therefore both
+// ordinary Deriva facts with nested proof terms.  Explanations are therefore both
 // human-readable and machine-readable.
 import { COMPOUND, Env, Term, VAR, deref, flattenConjunction, freshTerm, termToString, unify, variantTerms } from './term.js';
 import { selectClauseCandidates } from './program.js';

package/src/parser.js

@@ -1,4 +1,4 @@
-// Tokenizer and recursive-descent parser for the deriva source language.
+// Tokenizer and recursive-descent parser for the Deriva source language.
 // It preserves the compact Prolog-like syntax while producing Term objects for the solver.
 import { atom, compound, cons, emptyList, numberTerm, stringTerm, variable } from './term.js';
 

package/src/solver.js

@@ -1,4 +1,4 @@
-// Depth-first deriva solver with builtin dispatch, memoization, and guarded recursion handling.
+// Depth-first Deriva solver with builtin dispatch, memoization, and guarded recursion handling.
 // Most semantic decisions still flow through unification; optimizations only select candidates earlier.
 import { COMPOUND, Env, compound, copyResolved, flattenConjunction, freshTerm, termIsGround, termToString, unify, variantTerms } from './term.js';
 import { createDefaultRegistry } from './builtins/registry.js';
@@ -113,7 +113,7 @@ export class Solver {
           continue;
         }
 
-        // deriva normally solves left-to-right, but ready deterministic builtins can
+        // Deriva normally solves left-to-right, but ready deterministic builtins can
         // be run early as pure filters. Stop at internal sentinels so rule-body
         // active guards are released before the caller's remaining goals are seen.
         const selectedIndex = selectReadyDeterministicBuiltin(goals, env, this.registry);

package/test/conformance/README.md

@@ -9,7 +9,7 @@ All conformance files live under topic directories such as `arithmetic/`, `lists
 A normal positive case consists of:
 
 - `conformance/cases/<name>.pl` — input program;
-- `conformance/expected/<name>.pl` — exact expected standard output, stored as deriva-readable facts.
+- `conformance/expected/<name>.pl` — exact expected standard output, stored as Deriva-readable facts.
 
 Expected-error cases consist of:
 
@@ -63,9 +63,9 @@ The runner executes normal materialized programs in-process through the public J
 
 ## Scope
 
-The conformance corpus is a single deriva suite. It covers the standard language described by the language reference: lexical syntax, facts, definite clauses, first-order terms, lists, conjunction, structured unification, left-to-right goal-directed proof search, materialized output, read-back printing, standard built-ins, declarations, warnings, errors, proof output, and standard host behavior.
+The conformance corpus is a single Deriva suite. It covers the standard language described by the language reference: lexical syntax, facts, definite clauses, first-order terms, lists, conjunction, structured unification, left-to-right goal-directed proof search, materialized output, read-back printing, standard built-ins, declarations, warnings, errors, proof output, and standard host behavior.
 
-The suite deliberately does not separate `core` and `extension` profiles. Reusable built-ins such as arithmetic, strings, lists, aggregation, context terms, term inspection, and search control are part of the standard deriva conformance surface. Implementation-specific built-ins may still exist in downstream hosts, but they should have their own tests outside this corpus unless they are standardized.
+The suite deliberately does not separate `core` and `extension` profiles. Reusable built-ins such as arithmetic, strings, lists, aggregation, context terms, term inspection, and search control are part of the standard Deriva conformance surface. Implementation-specific built-ins may still exist in downstream hosts, but they should have their own tests outside this corpus unless they are standardized.
 
 ## Updating expected output
 

package/test/run-conformance-report.mjs

@@ -56,7 +56,7 @@ export function buildConformanceReport() {
 
 export function formatConformanceReport(report = buildConformanceReport()) {
   const lines = [
-    '# Conformance Deriva report',
+    '# Deriva conformance report',
     '',
     'This report summarizes the file-based conformance corpus under `test/conformance/`.',
     '',

package/test/run-regression.mjs

@@ -358,7 +358,7 @@ function documentationSyncCases() {
       run: () => assertArrayEqual(findBrokenDocLinks(), [], 'broken documentation links'),
     },
     {
-      name: 'documentation uses deriva source style',
+      name: 'documentation uses Deriva source style',
       run: () => assertArrayEqual(documentationSourceStyleIssues(), [], 'documentation source style'),
     },
     {