Loom is a Rust serving node for a published ontology generation. It provides bounded retrieval, read-only SPARQL, an agent tool interface and an OpenAI-compatible completion route. The model backend is configured by URL, independently of the corpus. A request can receive selected context, a canonical verbatim response, or a passthrough model response according to configuration and per-request options.

Use it to ground an assistant in a curated vocabulary, inspect relationships without a model, compare serving policies, or give a tool-using agent access to the same published generation. Formal checks concern the producer's supported logical profile; they do not establish that the corpus's assertions or a generated answer are factually correct.

Clone the repository and inspect its build requirements before compiling. The workspace declares Rust 1.89; the task runner defines the feature-plane and dependency checks. Some adapters use sibling source dependencies: consult Cargo.toml and the build architecture rather than treating this as a self-contained cargo install package.

git clone https://github.com/DreamLab-AI/loom.git
cd loom
just --list
just build
just test

just ci additionally runs formatting, strict Clippy and dependency-policy checks. These commands are the verification procedure, not a claim that this README refresh reran the whole workspace.

A useful server needs a complete corpus bundle, not just a reachable model. Follow published-generation reload and the publishing decision to build, promote and verify the intended generation. The compose profiles mount repository-root data/ read-only at /app/data.

deploy/compose.profile-a.yml describes a model-colocated deployment on port 8084; deploy/compose.profile-b.yml describes a GPU-free sidecar on visionclaw_network, port 8080. The sidecar delegates to a separately configured model service. Run Docker builds and bind-mounted deployments on the deployment host: bind paths resolve there, not inside an agent container.

The retained app/mirror.sh writes its four-file mirror to app/data/, which neither compose profile mounts as its corpus directory. It is also insufficient for the newer strict reload path, which requires six artefacts and the corresponding marker, digests and semantic-generation metadata. Copying four files into root data/ is not a complete promotion procedure.

Use the current promotion/reload runbook. Inspect the loaded generation and index readiness after activation. A 200 response from /health can coexist with missing corpus data; liveness alone does not establish usable grounding. Keep the prior verified generation for rollback.

Assuming the port-8084 profile is configured and has loaded a corpus:

# Retrieval only: no model call.
curl -fsS http://localhost:8084/loom/scaffold \
  -H 'Content-Type: application/json' \
  -d '{"prompt":"what is a rollup?","budget_tokens":700}'

# Retrieve, then delegate to the configured backend.
curl -fsS http://localhost:8084/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"what is a rollup?"}],"max_tokens":1536}'

# For a subject outside this corpus: explicit model passthrough.
curl -fsS http://localhost:8084/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"Explain this code review."}],"max_tokens":1536,"loom_options":{"scaffold":false}}'

The last example supplies no review content; add the material you want the backend to consider. Passthrough deliberately performs no corpus retrieval and reports corpus_backed: false. A model response through the Loom URL is therefore not automatically a grounded response.

An attestation entry and a rehashed ledger are not proof that a model answer is true or that the whole estate's governance loop is complete. Read the route and signer contract before integrating that optional surface.

flowchart TB
    NOTES["Upstream Markdown corpus"] --> BUILD["Pinned Ontomark build"]
    BUILD --> BUNDLE["Identified public bundle"]
    BUNDLE --> PROMOTE["Verify, promote and reload"]
    PROMOTE --> INDEX["Lexical and optional semantic indexes"]
    PROMOTE --> GRAPH["Oxigraph: asserted and inferred RDF"]
    INDEX --> POLICY["Retrieval and serving policy"]
    GRAPH --> POLICY
    CLIENT["Client or agent"] --> FACADE["Loom routes"]
    FACADE --> POLICY
    POLICY --> CONTEXT["Selected context and generation metadata"]
    CONTEXT --> BACKEND["Configured model URL"]
    BACKEND --> ANSWER["Answer and serving metadata"]
    CONTEXT -->|"Optional verbatim mode"| ANSWER

Shared producer contracts give readers compatible scaffold/prose structures without making Loom an ontology compiler. Runtime stores and indexes are rebuildable serving projections. The crate architecture separates domain types, adapters, scaffold policy, façade and benchmark tooling. The current workspace also includes loom-bench; the older eight-crate badge is no longer a complete census.

Retrieval confidence is a score-derived policy signal, not a calibrated probability of truth. Scores are comparable only within the reported scale. The grounding block records whether selection was full, scaled, skipped, verbatim or passthrough and exposes the relevant budget/seed information.

• LOOM_CONFIDENCE_INJECTION enables score-based selective injection. Strong and minimum-match thresholds and the minimum budget fraction are configured independently. Inspect the selected compose profile and /health; defaults and deployed values differ.
• LOOM_VERBATIM_MODE can return a canonical block without calling the backend.
• Exposure telemetry reports what was delivered or dropped; LOOM_EXPOSURE_APPEND optionally adds a coverage line.
• LOOM_BACKEND_NO_THINK and thinking-token controls affect delegated generation on their configured paths.
• loom_options.verbatim=false declines verbatim serving while retaining scaffold processing. loom_options.scaffold=false bypasses retrieval, injection, verbatim and associated thinking controls for that request.

See confidence surfacing, scaffold opt-out and the benchmark protocol. Backend compatibility and available models still need checking when the configured URL changes.

An optional System One step (Choice / Score / Noul over POST /v1/systemone) beside the chat path. With it off, or unavailable for any reason, the forwarded request and the response are byte-identical to the pre-change ones (asserted against a Jev-off baseline in crates/loom-facade/tests/jev_option.rs). Status: proposed research candidate; no measured uplift — wiring and fallback tests do not show uplift.

Stages (each also switchable: LOOM_JEV_GATE, LOOM_JEV_RANK, LOOM_JEV_SUPPORT, on once LOOM_JEV=1):

• Gate (LM-01-S1-01): Choice over grounded_lookup | mixed_request | ordinary_passthrough | insufficient_evidence plus a Noul "answerable". It can only withhold an already-engaged scaffold, and only when LOOM_JEV_GATE_MIN_CONFIDENCE is set (unset ⇒ the verdict is recorded in jev.gate, never acted on). It runs after retrieval, the generation guard and loom_options.scaffold=false, all of which keep precedence.
• Rank (LM-02-S1-01): one Score per candidate record; the candidates are reordered and re-assembled through the same gate (LexicalIndex::assemble). Kept only if the granted budget, injection decision and generation are unchanged; retrieval and the budget stay deterministic. LOOM_JEV_RANK_MIN_CONFIDENCE (default 0, untuned).
• Support (LM-02-S1-01): one Noul after generation, annotation only (jev.support: supported_probability, flagged_unsupported below LOOM_JEV_SUPPORT_THRESHOLD=0.5, source_ids). The answer is never altered. Verbatim-served answers are not checked.

Endpoint resolution (first match wins): LOOM_JEV_ENDPOINT (+ LOOM_JEV_MODEL, LOOM_JEV_KEY_ENV = name of the env var holding a bearer token) → the agentbox loopback proxy (AGENTBOX_SYSTEM_ONE_PROXY=1, AGENTBOX_SYSTEM_ONE_ENDPOINT/_MODEL, no Authorization header) → https://api.typesafe.ai/v1/systemone with TYPESAFE_API_KEY. Loom serves private corpus content, so a non-local endpoint is refused (loopback, private, .local and single-label hosts count as local; LOOM_JEV_LOCAL=1 declares an explicit endpoint local; the proxy needs AGENTBOX_SYSTEM_ONE_BACKEND_LOCAL=1) unless LOOM_JEV_ALLOW_CLOUD=1. The public endpoint always needs LOOM_JEV_ALLOW_CLOUD=1.

Fallback (one log line with the reason only, never request content): flag-off, no-endpoint, non-local-refused, timeout (hard deadline LOOM_JEV_TIMEOUT_MS, default 4000, no retries), transport, http-<code> (429/529 are not retried), malformed (bad body, missing answer IDs, Choice key outside the offered set), low-confidence, invariant-broken (rank only). Question sets are versioned (loom.lm-01-s1-01.v1, loom.lm-02-s1-01.rank.v1, loom.lm-02-s1-01.support.v1). See crates/loom-facade/src/jev.rs.

Loom's experiments measure retrieval and answer behaviour on identified corpus snapshots. They support faithful delivery of curated facts under the tested policies; a headline recall gain does not by itself establish reasoning, precision, attribution accuracy or transfer to another corpus.

The research index identifies the current manuscript and superseded versions. Its copy-control analysis distinguishes facts already exposed in context from recovered answers. Preserve that control when quoting the older approximately 0.94 grounded-recall figures; they are not a guarantee for arbitrary models or queries.

The 13 October pilot compared two arms on 40 preregistered questions using one generation. Lookup recall was similar, with substantially higher token and latency costs for tools. The path stratum favoured tools, but its gold came from the path tool and the injection arm often hit its output cap. The pooled confidence interval included zero. This pilot does not establish a general routing rule or universal tool-use advantage.

The preregistration, raw results and scoring record make the limits inspectable. loom-bench is the new evaluation component since the previous README update; its existence is not a new production-grounding guarantee.

Source reviewed 21 October 2026 at e2e4273. The source includes lexical retrieval, native SPARQL, the serving routes, the MCP plane and strict generation-reload tooling. Optional semantic fallback remains gated in the reference configurations. Activation is deployment-specific.

The ADR-142 receipt records a first served Ontomark bundle on 12 October 2026, generation visionGraph@45976a8c…, with verified identity and health observations. That replaces the earlier claim that first promotion was still pending. It is dated evidence, not a probe of today's server. deploy/ontomark-release.env remains a separate, older publishing CLI pin and must not be read as the version embedded by every consumer.

No live deployment, fresh full workspace test, recall benchmark or model-to-model parity run was performed for this README refresh. A new backend, corpus or profile requires its own acceptance evidence. The node serves the public generation; private working notes and ontology promotion belong to their owning systems.

Loom assembles context. It does not grant an agent permission to change the ontology or sign a human decision, and it does not own every consumer's deployment.

Docs hub · Reload runbook · Research evidence · Architecture · Remote clients

Code is MIT OR Apache-2.0: MIT, Apache. Corpus/data and third-party terms are separate; consult the producer's notices. Maintained by DreamLab AI and John O'Hare.