Deployment and documentation

What stays, what moves, and what we can honestly say about it

Documentation status

withdrawn

The previous site’s Getting started and API reference documented a pip package, a Docker image, a Python SDK, a REST API and a configuration file that do not exist; packaging and a documented API are unchecked roadmap items.2 Those pages were removed rather than corrected, because no command in them works.3

What to read instead:

Documentation that will exist when the roadmap items are done: a quick-start and a documented memory-graph API, both planned.3

Retired URLs redirect here; the withdrawal is recorded in the corrections log.

  • /docs/index.html
  • /docs/getting-started.html
  • /docs/api-reference.html

What stays, what moves

D12 Stays / moves: what stays on a holder, what may leave it after policy, and what never moves A dashed enclosure labelled holder and marked as a failure domain contains four solid boxes: raw memory graph, embeddings, transcripts and per-node storage, with the note “stays on the holder by design”. A solid policy gate sits on the enclosure’s lower edge with the note “before propagation”. Below the gate, three teal threads labelled “evidence out” run outward to three artifact boxes: claim envelope, retrieval trace and evidence export. One gold thread labelled “question in” runs inward from a fourth box, question, into the gate. A bracket under the four boxes reads “each carries owner, scope, temporal validity, lineage and authorization”. Lower, outside the enclosure, two struck-through grey boxes read raw graph read (never moves) and global merged store (does not exist). At the bottom a hatched box labelled open-domain fallback retriever carries the tag configuration and the note “reaches outside local memory when enabled; must be off for local-only operation”. holder failure domain raw memory graph embeddings transcripts per-node storage stays on the holder by design policy gate · before propagation evidence out question in claim envelope retrieval trace evidence export question each carries owner, scope, temporal validity, lineage and authorization raw graph read never moves global merged store does not exist open-domain fallback retriever configuration reaches outside local memory when enabled; must be off for local-only operation
  • solid: stays on the holder
  • teal thread: evidence artifact, out after policy
  • gold thread: question, in after policy
  • struck: never moves / does not exist
  • hatched: configuration
D12 Stays / moves. The dashed enclosure is one holder and one failure domain; the raw memory graph, embeddings, transcripts and per-node storage inside it stay there. The policy gate on its edge runs before anything propagates. Claim envelopes, retrieval traces and evidence exports leave along teal threads; a bounded question arrives along a gold thread; every one of them carries owner, scope, temporal validity, lineage and authorization. Raw graph reads never move and there is no global merged store. The open-domain fallback retriever is drawn hatched because it is configuration, not a control. Sources: NeuralGraph/state.md ll.19-30, 43-71; NeuralGraph/NeuralGraph/external_retriever.py l.249.
Stays on the holder
The raw memory graph, embeddings, transcripts and per-node storage.4
Moves, and only after policy
Typed, validated artifacts (claim envelopes, retrieval traces, evidence exports) and bounded questions, each carrying owner, scope, temporal validity, lineage and authorization.5
Never moves
Raw graph reads; and there is no global merged store.4

Mechanisms, where they live, and their evidence status

Each mechanism, what it does, where it is implemented and its status. Rows drawn hatched are not implemented or exist only as design. Sources are given by number in the last column.
Mechanism What it does Where implemented Status Source
No raw cross-graph edges holders never read each other’s graphs coordinator boundary validation (adapters) implemented and tested 6
Typed artifacts only ClaimEnvelope, RetrievalTrace, EvidenceExport are the entire trust boundary coordination/contracts.py frozen dataclasses implemented and tested 7
Policy before propagation a policy filter runs before any artifact leaves coordinator policy filter implemented and tested 4
Lineage roots on every claim lineage_root_ids and claim_roots in output coordinator lineage analyser implemented and tested 8
Trace log a TraceEvent stream per coordinated retrieval coordinator TraceLogger implemented and tested 8
Reversible, payload-free failure injection inject and undo failures without moving data coordinator failure injector implemented and tested 4
Lineage-aware repair route to an independently rooted holder after a root fails coordinator repair planner; Class B fixture demonstrated in fixture 9
Per-stage retrieval attribution candidate counts, latency, score components, evidence per stage engine attribution implemented 10
DLP: no text leaves a device devices emit structured observations only benchmark simulator benchmark simulator 11
k-anonymity suppression cells with fewer than k contributors are suppressed benchmark simulator benchmark simulator 11
Canary tokens planted tokens measure leakage exactly benchmark simulator benchmark simulator 12
HMAC-signed claims and content-hash dedup forged or duplicated claims are detected benchmark simulator benchmark simulator 13
Independent-support discount copies and same-source evidence count less benchmark simulator benchmark simulator 14
Quarantine and supersession claim status in {proposed, accepted, quarantined, superseded, unresolved}; withdrawal on re-test benchmark simulator benchmark simulator 15
Local model endpoints the engine calls whatever base URL is configured; localhost is the documented case engine llm_backend configuration not a control 16
Open-domain fallback retriever reaches outside local memory when enabled engine external_retriever configuration must be off for local-only operation 17
Session isolation indexes partitioned by session key engine storage implemented data scoping, not a security boundary 18
Per-source-memory authorization authorization at the granularity of a single memory none not implemented 19
Network transport between holders durable, causally ordered transport none design only no deployed transport exists 7

What we can assert and what we cannot

Can

  • The coordinator’s boundary validation rejects raw graph access; policy runs before propagation; failure injection is reversible and payload-free.4
  • Every coordinated claim carries lineage roots and every coordinated retrieval carries a trace.8
  • The engine’s network endpoints are the model server you point it at and, only if you enable it, the open-domain fallback retriever.20
  • The engine records per-stage retrieval attribution.10

Cannot, yet

  • An independent security audit; a formal proof of non-leakage.
  • Per-source-memory authorization (not implemented).19
  • A telemetry statement: we make none until the code path has been reviewed independently.
  • Enterprise-readiness, certification or compliance claims; SLAs.21
  • Fair-baseline, Pareto, scale or generalisation evidence for the coordinator (Gates 2 to 6 not started).22

Known fail-closed behaviour: a REDACTED policy status resolves to DENIED.19 Session isolation in the engine is data scoping, not a security boundary.18

Lineage and audit trail

What exists

  • lineage threads forming a derivation DAG;
  • lineage root ids on every coordinated claim;
  • a trace-event stream;
  • per-stage retrieval attribution;
  • in the benchmark, LineageRecords with hashed root worker ids, paths and derivation operators, and HMAC-signed claims.23

What does not exist

  • a user-facing export or purge-on-demand feature (the previous site’s claim is withdrawn);
  • retention is governed by the engine’s automatic consolidation cycle unless configured.24

Threat models studied so far

In the deterministic fixture
node failure, memory deletion, lineage-root failure, authorization revoke, route removal, edge corruption, staleness, partition, worst single domain.25
In the benchmark design
eleven poisoning attack types and seven detectors, canary tokens for exact leakage measurement, k-anonymity suppression.26
In symbolic simulation only
a white-box attacker that knows each policy’s placement and greedily removes independent support (a lower bound on an optimal adversary); origin-source corruption; coordinated corruption; whole-domain, organisation and region loss; two- and four-way partitions.27
In symbolic simulation only
further threat models studied in symbolic simulation are described in the manuscript under review and are held back here until it is cleared.

None of these is a penetration test of running software.

Air-gapped operation

configuration, not a feature

Running the engine with a local model server on a network with no outbound route is consistent with design principle 5, “the system should run locally when possible”, and with the local-model backend; it is not a delivered or tested scenario.28 For it to hold, the optional open-domain fallback retriever must be switched off and the model base URL must point inside the network.29 The previous site’s “air-gapped deployments” claim is restated here as a configuration, not a feature.30

Hardware and models

The engine runs with local models through an OpenAI-compatible server such as LM Studio or through Ollama.31 We publish no minimum or recommended hardware because none has been measured; the only compute figures in the programme are simulator costs (benchmark tiers at 0.35 to 3.4 GB on a 4-vCPU container without a GPU; a symbolic 100,000-agent run in 97 CPU-minutes; and a symbolic-simulation cost reported in the manuscript under review), which say nothing about the engine’s requirements.3233 The previous site’s RAM, storage and CPU tables are withdrawn.34

How an evaluation runs

  1. Scoping call

    Your local model server (Ollama or OpenAI-compatible), the kind of memory you need, your constraints (air-gapped, policy).35

  2. Metrics agreed before anything runs

    Metrics, judge, prompt strictness and dataset slice are agreed in writing before anything runs, because identical answers score between 13.5% and 64.9% depending only on the grader.36

  3. Written statement of status

    A written statement of what is implemented, demonstrated and proposed for your scenario, using the ledger on the architecture page.

  4. Local install and harness run

    A local install on your hardware with your models; a LoCoMo-style harness run whose numbers name their judge.37

  5. Read-out

    A read-out including negative findings.38

No SLA and no price list; commercial terms are discussed directly. Commercial terms

For your security review

What an evaluation can include today

  • A code walkthrough of the coordination contracts and boundary validation.7
  • Running the 109 coordination tests and the benchmark’s no-cheating tests in your environment.39
  • A DLP, k-anonymity and canary demonstration in the benchmark simulator.40
  • A written data-flow description for your configuration (endpoints contacted, artifacts that can leave a holder, what the trace log records).

What it cannot include

  • Certification.
  • A third-party audit report.
  • An SLA.

Questions to ask us (we answer each with file-and-line references)

What this website does

Static HTML, CSS and JavaScript. No cookies, no accounts, no first-party analytics, no server-side code. Fonts are loaded from one third-party host and can be blocked without loss of content. The theme preference is stored only in your browser. Contact is a mailto link; no form posts anywhere.

The previous site’s login, dashboard and authentication server were removed: they collected credentials into a users.json file on a server that exposed its own path, and no account or plan existed behind them.41

Request an evaluation or a security walkthrough

Contact

Sources

Paths are relative to the root of the NeuralGraph repository, which is public to read at github.com/anovruzov/NeuralGraph with no licence selected (all rights reserved); they are given as text, with line numbers checked against main on 2026-09-17, and files under mycelic-org-benchmark/ are on branch claude/mycelic-org-benchmark-9cnf35, not yet merged into main. “Manuscript” is the Mycelic research manuscript under review, cited by section and printed margin line number; entries marked gated are stripped from the deployed page until the authors clear publication. “website/” is the previous site, cited only for withdrawn claims and removed pages.

  1. Manuscript — §6.1, l.242
  2. website/docs/getting-started.html; website/docs/api-reference.html (removed pages); NeuralGraph/README.md — Roadmap, ll.131-139
  3. NeuralGraph/README.md — Roadmap, ll.131-139
  4. NeuralGraph/state.md — Non-negotiable invariants, ll.19-30
  5. NeuralGraph/state.md — contracts.py, ll.43-71; NeuralGraph/mycelic-org-benchmark/DESIGN.md — §4, ll.160-192
  6. NeuralGraph/state.md — ll.19-30, 43-71
  7. NeuralGraph/state.md — contracts.py, ll.43-71
  8. NeuralGraph/state.md — Gate 1, ll.195-197
  9. NeuralGraph/docs/BENCHMARKS.md — ll.16-62
  10. NeuralGraph/README.md — ll.49-50
  11. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §3.6, ll.145-153
  12. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §5, ll.199-202
  13. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §4, ll.160-192; NeuralGraph/mycelic-org-benchmark/README.md — l.141
  14. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §6 step 3, ll.238-242
  15. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §4, ll.160-192; NeuralGraph/mycelic-org-benchmark/README.md — ll.155-157
  16. NeuralGraph/NeuralGraph/llm_backend.py — ll.1-24
  17. NeuralGraph/NeuralGraph/external_retriever.py — l.249; NeuralGraph/README.md — ll.39-47
  18. NeuralGraph/NeuralGraph_System_Architecture.md — §4.3
  19. NeuralGraph/state.md — Known Issues item 4, ll.270-278
  20. NeuralGraph/NeuralGraph/llm_backend.py — ll.1-24; NeuralGraph/NeuralGraph/external_retriever.py — l.249
  21. website/about.html — l.72 (withdrawn “Enterprise Ready”)
  22. NeuralGraph/state.md — ll.210-228
  23. NeuralGraph/state.md — ll.195-197; NeuralGraph/README.md — ll.49-50; NeuralGraph/mycelic-org-benchmark/DESIGN.md — §4, ll.160-192
  24. website/index.html — l.148 (withdrawn claim); NeuralGraph/NeuralGraph_System_Architecture.md — §3.4.3
  25. NeuralGraph/docs/BENCHMARKS.md — ll.27-36
  26. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §3.6, ll.145-153; §5, ll.199-202; §10, ll.370-394
  27. Manuscript — ll.138-142; §6.1, l.237 (gated)
  28. NeuralGraph/README.md — Design Principles, ll.118-125; NeuralGraph/NeuralGraph/llm_backend.py — ll.1-14
  29. NeuralGraph/README.md — ll.39-47; NeuralGraph/NeuralGraph/external_retriever.py — l.249; NeuralGraph/NeuralGraph/llm_backend.py — ll.22-24
  30. website/index.html — “air-gapped deployments” (withdrawn wording)
  31. NeuralGraph/NeuralGraph/llm_backend.py — ll.1-14
  32. NeuralGraph/mycelic-org-benchmark/docs/EXPERIMENT_PLAN.md — ll.3-14
  33. Manuscript — ll.133-137 (gated)
  34. website/index.html — ll.234-241 (withdrawn hardware tables)
  35. NeuralGraph/README.md — ll.90-116
  36. NeuralGraph/docs/BENCHMARKS.md — Judge sensitivity, ll.121-131
  37. NeuralGraph/docs/BENCHMARKS.md — ll.70-72
  38. NeuralGraph/docs/BENCHMARKS.md — All 18 experiments, ll.101-119
  39. NeuralGraph/state.md — Test Status, ll.145-154; NeuralGraph/mycelic-org-benchmark/README.md — Honesty rules, ll.286-294
  40. NeuralGraph/mycelic-org-benchmark/DESIGN.md — §3.6, ll.145-153; §5, ll.199-202
  41. website/server/server.js — l.12; website/dashboard.html; website/login.html (removed)

Source ledger for this page: NeuralGraph/state.md; NeuralGraph/README.md; NeuralGraph/NeuralGraph/llm_backend.py, external_retriever.py; NeuralGraph/NeuralGraph_System_Architecture.md; NeuralGraph/docs/BENCHMARKS.md; NeuralGraph/mycelic-org-benchmark/DESIGN.md, README.md, docs/EXPERIMENT_PLAN.md; website/index.html, about.html, docs/*.html, login.html, dashboard.html, server/server.js (withdrawn); manuscript (gated).