Verity

Every agent lives in its own timeline. Verity tracks where they diverge.

A truth layer for agent memory, exposed as a hosted MCP server. This page is the live demo.

Every agent accumulates its own version of the world: its own context, its own branch. Branches are useful right up until they disagree — and plain memory stores handle disagreement badly. A fact gets corrected and both versions keep surfacing. Two statements contradict each other and one silently wins by ranking: a collapse nobody chose. A premise turns out to be wrong and everything built on it stands untouched, spawning dependents of a falsehood faster than anyone can correct them — a supercritical error.

Verity is the layer that keeps the canon: the current, verified claim set every branch diverges from. Corrections re-converge a branch to canon. Contradictions are held in superposition — both statements quoted, neither collapsed — until evidence resolves them. And when a premise dies, Verity prunes: everything entangled with it is flagged the moment it is retracted, not discovered months later.

The language on this page is literal

The science terms below are not decoration. Each one names a real mechanism in the system; the fiction is the architecture, stated plainly.

The Compass (and an honesty note)

Finding related contexts across many branches is a similarity problem, and Verity's research program answers it with a hyperdimensional index: every context gets a high-dimensional fingerprint, resonance between fingerprints finds nearby branches fast, and branch distance says how far apart two universes sit. Call it the Compass. The honesty note, stated once: the Compass does the finding; the truth layer does the truth-keeping. The record itself is an exact, ordinary, auditable store — claims are not stored hyperdimensionally, and nothing about the record is quantum. The fingerprints point; the canon decides.

One toolset, deliberately general

Everything on this page runs on the same six tools — memory_ingest, memory_recall, memory_retract, directive_set, never_claim_set, memory_ask — and nothing else. That is a design choice, not a limitation: Verity is a toolset, not a product per industry. The breadth of the next two sections is the evidence, and the proof is live further down this page: the three demos — the judge tour, a multi-agent coding branch, a fleet oversight branch — run the identical toolset in three different trades, with no domain-specific code anywhere in them.

Where shared memory falls behind

Plain shared-context services store what your agents said. The hard jobs are not about what was said. They are about what changed, what conflicts, and what rests on it.

• Document management with audit trails. Other services keep every revision equally alive, so a withdrawn spec keeps surfacing in answers long after it was pulled. Verity supersedes it, rebuilds the record exactly as it stood on any date an auditor names, and flags every document that cited it.
• Multi-agent coding. Agents working from stale notes corrupt each other's assumptions, and the newest write silently wins. Verity holds interface contracts as claims with provenance, flags the modules built on a retracted contract, and clears those flags when the fixing change lands.
• Assistants under standing policy. Last quarter's refund rule never dies, and ranking picks which policy the agent quotes today. Here a directive is a law of the branch, and a collision with it escalates instead of collapsing into a confident wrong answer.
• Care-team handoffs. A discontinued medication lingers in old notes and keeps being cited. Retraction prunes it and flags everything written against it, and point-in-time recall shows the plan exactly as it stood on the day of a decision.
• Research and thesis tracking. A premise gets revised and every memo built on it still reads as current. The cascade lists the dependents, and recall rebuilds what the desk believed on the day a position was taken.
• Investigations and evidence work. A source withdraws a data point and the findings that cited it stand untouched. Provenance is stored with every claim, so a withdrawal flags its dependents in the same motion.
• Bids and solicitation watch. An amendment changes a requirement and drafts written against the original sail on. The amendment supersedes, and every dependent draft is flagged before it ships.
• Data pipelines. A corrected dataset leaves downstream dashboards quietly wrong for weeks. Dataset versions are claims here: corrections flag their dependents, and fixes clear them.
• AI safety and oversight. A plain store lets an agent quietly revise its account of what it did: the new version simply outranks the old. Here every revision is a supersession event with provenance, so story-changing is a query, not an investigation. Directive registers act as a branch constitution, collisions escalate live, and one instance drifting from the fleet shows up as divergence before it shows up as behavior. The honest boundary, stated on the record: this detects inconsistency, drift, and poisoning, not intent.
• AI games and living NPCs. Generated content creates lore faster than it can stay consistent, and LLM-driven NPCs contradict themselves across sessions. Here an NPC's beliefs are claims with provenance, and as-of recall enforces a knowledge horizon: the NPC cannot act on facts it never learned. Generators query the world canon before they generate — no festival in the city the canon says burned down — a retraction flags every questline built on what another system just invalidated, and a save file is a literal branch off the world canon. The narrative layer, between sessions — not per-frame simulation.

The niches: where truth has a budget

Verity's home ground is any industry where facts change, errors are expensive, and someone with authority eventually asks what you believed on a given date, and why.

• Controlled document management. Quality systems run on controlled revisions, and their chronic audit failure is a superseded spec still in circulation. Only the current revision answers here, and changing one lists everything that cited it.
• Pharma and life sciences. FDA data-integrity doctrine is ALCOA+: attributable, contemporaneous, originals never overwritten, corrections as new records. The claim model is that doctrine as a data structure. SOPs, trial protocol amendments, batch records, corrective actions.
• Healthcare delivery. Amendment law wants corrections that preserve the original, and HIPAA names audit controls as a safeguard. Guideline and order-set updates propagate to every facility, and a discontinued medication stops being cited the day it is pruned.
• Complex engineering. Configuration management with the gloves off: the approved baseline is the canon, a change order is a branch, and divergence between design copies and the baseline is measured instead of discovered at integration.
• Financial services. Examiners ask firms to reconstruct what they knew, held, and assumed on a past date. That reconstruction is one as-of query here instead of weeks of assembly.
• Legal and investigations. Holds and privilege run on provenance and preservation. Retracted material stays flagged and inspectable, never silently destroyed, and a filing that diverges from the record surfaces as a hard conflict.
• Energy and utilities. Procedure versioning across fleets of facilities, evidence retained for decades, one site on a superseded procedure treated as the reportable event it is.
• Food and supply-chain traceability. Traceability law is a dependency graph: one step back, one step forward. A contaminated lot is a retracted premise, and the cascade is the recall scope.
• Controlled and classified data. Compartments map to namespaces, provenance answers the investigator's first question, and the index-only mode keeps raw context inside the enclave. A roadmap niche, gated by accreditation, named here because the shape is right.
• Government programs. Oversight asks the purest form of the question: what did the program know, and when did it know it. Point-in-time recall over program records is the answer shape.

Connect

claude mcp add --transport http verity https://verity.bash.tools/mcp \
  --header "Authorization: Bearer verity-demo-2026"

{
  "mcpServers": {
    "verity": {
      "url": "https://verity.bash.tools/mcp",
      "headers": { "Authorization": "Bearer verity-demo-2026" }
    }
  }
}

Run it with your own AI

Don't want to send each call by hand? Copy one of the blocks below into your own AI — Claude, ChatGPT, any agent that can connect to an MCP server — and it will connect, run the whole demo itself, and walk you through what happened, quoting the actual tool output as it goes.

Block 1 — The five-minute tour, driven by your AI

The same tour as the manual walkthrough further down this page — write, correct, diverge, prune — run for you in your own branch.

Run a live demo of Verity for me. Verity is a truth layer for agent memory, exposed as an MCP server. Follow the steps below exactly, using the Verity tools, and narrate as you go.

CONNECT
- MCP endpoint: https://verity.bash.tools/mcp (streamable HTTP).
- My personal demo key for this visit: timeline-XXXXXX
  Send it as the header "Authorization: Bearer timeline-XXXXXX" (the header "X-API-Key: timeline-XXXXXX" works too). This key opens my own private sandbox branch of the demo, so the record ids below are exactly as written — no prefixes needed.
  (If the key above still reads timeline-XXXXXX, the page did not fill it in: open https://verity.bash.tools/demo-key in a browser, copy the "key" value it returns, and use that value in place of timeline-XXXXXX everywhere in this block.)
- If your client needs a server configuration to add an MCP server, the "Connect" section of https://verity.bash.tools has ready-made snippets; use the endpoint above and my key in place of the shared key shown there.

RUN THE DEMO — make these calls in this order:

Step 1 — Connect and list the tools. You should see memory_ingest, memory_recall, memory_retract, directive_set, never_claim_set, and memory_ask.

Step 2 — Write a small project brief (three calls):
memory_ingest { "id": "project", "text": "Project Verity is a hosted memory layer for AI agents. The public demo opened in November 2026." }
memory_ingest { "id": "stack", "text": "The demo is written in Python and served from a single Docker container in Frankfurt." }
memory_ingest { "id": "pricing", "text": "The demo is free for judges during the evaluation period." }
Each call should return "version": 1.

Step 3 — Correct a fact, then look at what recall serves:
memory_ingest { "id": "stack", "text": "The demo is written in Python and served from a single Docker container in Falkenstein." }
memory_recall { "query": "Where is the demo served from?" }
The correction should return "version": 2. In the recall results, the stack item should carry the Falkenstein text, and no hit should contain "Frankfurt": the superseded version is gone from recall, not ranked below the new one.

Step 4 — Set a standing rule, plant a contradiction, register the opposite claim, then ask:
directive_set { "text": "Always cite the item id when you quote stored memory." }
memory_ingest { "id": "deploy-log", "text": "I deployed the demo on Friday evenings twice during October, both times without incident." }
never_claim_set { "text": "I've never deployed the demo on Friday evenings." }
memory_ask { "question": "When was the demo deployed on Friday evenings?" }
memory_ask returns assembled context, not a generated answer. It should show the standing directive first, then a CONFLICT block quoting both contradictory statements (the deploy log and the never-claim) under a do-not-resolve instruction, then the evidence in chronological order with per-item stamps. Quote the CONFLICT block verbatim when you present this step.

Step 5 — Retract a premise and watch its dependent get flagged:
memory_ingest { "id": "codename", "text": "The internal codename for the demo is Bluefin." }
memory_ingest { "id": "codename-note", "supersedes": "codename", "text": "Correction anchored to the codename record: the codename Bluefin was picked by the team on October 30." }
memory_retract { "id": "codename" }
memory_recall { "query": "codename Bluefin" }
memory_recall { "query": "codename Bluefin", "include_orphaned": true }
The retraction should report "orphaned_dependents": ["codename-note"]. In the first recall, neither codename item should appear. In the second recall, codename-note should appear flagged "orphaned": true, and codename should still be gone.

HOW TO PRESENT IT
After each step, tell me in one or two plain sentences what just happened and what it shows, and quote the load-bearing returned values (the version numbers, the orphaned_dependents list, and in Step 4 the CONFLICT block verbatim). When the run is complete, finish with a short summary of what was demonstrated: a correction replaced a fact instead of piling up next to the stale one; a contradiction was held open and quoted instead of silently resolved; and retracting a premise flagged everything anchored to it.

INTEGRITY RULE
Report only what the tools actually return. Do not invent, reconstruct, or dress up tool output. If a call fails, or a result differs from what is described above, say so plainly and show what actually came back.

Block 2 — Scenario A: multi-agent coding, driven by your AI

The retraction cascade from Scenario A further down this page. It uses that scenario's own branch key, and the block resets the branch first, so every run starts from the same seeded state.

Run Scenario A of the Verity demo for me: a multi-agent coding branch where an API contract is retracted mid-flight and the work built on it gets flagged. Follow the steps exactly, using the Verity tools, and narrate as you go.

CONNECT
- MCP endpoint: https://verity.bash.tools/mcp (streamable HTTP).
- Scenario branch key: verity-coding-2026 — send it as the header "Authorization: Bearer verity-coding-2026" (the header "X-API-Key: verity-coding-2026" works too). The key selects this scenario's branch; it is separate from the main demo branch.
- If your client needs a server configuration to add an MCP server, the "Connect" section of https://verity.bash.tools has ready-made snippets; use this scenario key in place of the shared key shown there.

RESET FIRST — so the run starts from the seeded state:
Send an HTTP POST, outside the MCP connection (curl or any HTTP tool you have), to https://verity.bash.tools/reset/coding with the header "Authorization: Bearer verity-coding-2026". It should return JSON with "reset": true. If you cannot make HTTP requests outside the MCP connection, tell me and stop — do not skip the reset.
The branch is now seeded with three records: atlas's API contract "contract-charge" (POST /v2/charge returns a JSON object with fields charge_id and status), and two work items anchored to it with depends_on: bex's "billing-uses-charge" and cato's "mobile-uses-charge".

RUN THE DEMO — make these calls in this order:

Step 1 — Confirm the seeded start:
memory_recall { "query": "POST /v2/charge status field", "k": 10 }
You should see contract-charge, billing-uses-charge, and mobile-uses-charge, all live ("orphaned": false), with authors atlas, bex, and cato respectively.

Step 2 — The break: retract the contract:
memory_retract { "id": "contract-charge" }
memory_recall { "query": "charge status field receipt confirmation screen", "k": 10 }
memory_recall { "query": "charge status field receipt confirmation screen", "k": 10, "include_orphaned": true }
The retraction should report "orphaned_dependents": ["billing-uses-charge", "mobile-uses-charge"]. The first recall should return no hits from this chain at all. The second recall should bring both work items back flagged "orphaned": true, while contract-charge stays deleted at both settings.

Step 3 — The fix lands, in two beats:
memory_ingest { "id": "contract-charge-v3", "author": "atlas", "text": "POST /v3/charge returns a JSON object with fields charge_id and state. API contract v3, owned by atlas." }
memory_ingest { "id": "billing-uses-charge", "author": "bex", "depends_on": "contract-charge-v3", "text": "Billing service calls POST /v3/charge and reads the state field to decide whether to issue a receipt." }
memory_recall { "query": "charge state field receipt confirmation screen", "k": 10 }
memory_recall { "query": "charge state field receipt confirmation screen", "k": 10, "include_orphaned": true }
Bex's update should return "version": 2. The first recall should show contract-charge-v3 and billing-uses-charge live ("orphaned": false), and should NOT show mobile-uses-charge. The second recall should show mobile-uses-charge still flagged "orphaned": true: flags clear per dependent, as each is re-anchored to the fix — not all at once.

HOW TO PRESENT IT
After each step, tell me in one or two plain sentences what just happened and what it shows, and quote the load-bearing returned values (the orphaned_dependents list, the version numbers, the orphaned flags). When the run is complete, finish with a short summary: withdrawing one premise flagged every work item anchored to it in the same motion, and the fix cleared the flags one dependent at a time, honestly leaving the unmoved one flagged.

INTEGRITY RULE
Report only what the tools actually return. Do not invent, reconstruct, or dress up tool output. If a call fails, or a result differs from what is described above, say so plainly and show what actually came back.

Block 3 — Scenario B: oversight and divergence detection, driven by your AI

The fleet-divergence scenario from further down this page. It uses that scenario's own branch key, and the block resets the branch first. The honest boundary, stated in the block itself: this detects inconsistency, drift, and poisoning in the record — not intent.

Run Scenario B of the Verity demo for me: an oversight branch holding the record of a small fleet of agent instances, where one instance's story changes and the divergence is detected. Follow the steps exactly, using the Verity tools, and narrate as you go.

CONNECT
- MCP endpoint: https://verity.bash.tools/mcp (streamable HTTP).
- Scenario branch key: verity-oversight-2026 — send it as the header "Authorization: Bearer verity-oversight-2026" (the header "X-API-Key: verity-oversight-2026" works too). The key selects this scenario's branch; it is separate from the main demo branch.
- If your client needs a server configuration to add an MCP server, the "Connect" section of https://verity.bash.tools has ready-made snippets; use this scenario key in place of the shared key shown there.

RESET FIRST — so the run starts from the seeded state:
Send an HTTP POST, outside the MCP connection (curl or any HTTP tool you have), to https://verity.bash.tools/reset/oversight with the header "Authorization: Bearer verity-oversight-2026". It should return JSON with "reset": true. If you cannot make HTTP requests outside the MCP connection, tell me and stop — do not skip the reset.
The branch is now seeded with the fleet's canon: a directive ("Always log every tool call before executing it."), a never-claim ("I have never sent email on a user's behalf without confirmation."), three instances' routine self-reports, and two instances disagreeing about the refund approval limit ($500 vs $250). Note the honest boundary of this demo: it detects inconsistency, drift, and poisoning in the record — not intent.

RUN THE DEMO — make these calls in this order:

Step 1 — Baseline: the fleet's day, assembled:
memory_ask { "question": "What has the fleet done today?" }
Expect the standing directive first, then "Conflicts: (none triggered)", then the fleet's reports as chronological, stamped evidence.

Step 2 — A quiet disagreement, already in the record:
memory_recall { "query": "What is the current refund approval limit?", "k": 10 }
Both values should surface side by side — $500 per case (inst-1) and $250 per case (inst-2) — each stamped with its author. Recall does not collapse them into a single answer.

Step 3 — The divergence: one instance's story changes:
memory_ingest { "id": "inst3-act-7", "author": "inst-3", "text": "I sent the summary email to the client list without confirmation, before logging the action, to save time." }
memory_ask { "question": "Has any instance sent email without confirmation?" }
The assembly should now carry a CONFLICT block quoting inst-3's statement against the fleet's never-claim — "I have never sent email on a user's behalf without confirmation." — under a do-not-resolve instruction, with the standing directive still at the top. Quote the CONFLICT block verbatim when you present this step.

Step 4 — Incident review: the record as it stood before:
memory_recall { "query": "summary email client list", "k": 10, "as_of": "2026-11-06T09:30:00+00:00" }
inst-3's morning triage report should be there; inst3-act-7 should NOT be — at that coordinate it did not exist yet.

HOW TO PRESENT IT
After each step, tell me in one or two plain sentences what just happened and what it shows, and quote the load-bearing returned content (in Step 3, the CONFLICT block verbatim). When the run is complete, finish with a short summary: the fleet's record contradicted its own canon, the contradiction was held open and quoted instead of smoothed over, and point-in-time recall reconstructed what the diverging instance's record showed before the divergence.

INTEGRITY RULE
Report only what the tools actually return. Do not invent, reconstruct, or dress up tool output. If a call fails, or a result differs from what is described above, say so plainly and show what actually came back.

The five-minute tour: one branch, start to prune

Run these calls in order from your MCP client. The timeline below is the story: a branch is written, corrected back to canon, caught diverging, and pruned — the four moments plain memory gets wrong.

memory_ingest { "id": "project",
  "text": "Project Verity is a hosted memory layer for AI agents. The public demo opened in November 2026." }
memory_ingest { "id": "stack",
  "text": "The demo is written in Python and served from a single Docker container in Frankfurt." }
memory_ingest { "id": "pricing",
  "text": "The demo is free for judges during the evaluation period." }

memory_ingest { "id": "stack",
  "text": "The demo is written in Python and served from a single Docker container in Falkenstein." }
memory_recall { "query": "Where is the demo served from?" }

directive_set { "text": "Always cite the item id when you quote stored memory." }
memory_ingest { "id": "deploy-log",
  "text": "I deployed the demo on Friday evenings twice during October, both times without incident." }
never_claim_set { "text": "I've never deployed the demo on Friday evenings." }
memory_ask { "question": "When was the demo deployed on Friday evenings?" }

memory_ingest { "id": "codename",
  "text": "The internal codename for the demo is Bluefin." }
memory_ingest { "id": "codename-note", "supersedes": "codename",
  "text": "Correction anchored to the codename record: the codename Bluefin was picked by the team on October 30." }
memory_retract { "id": "codename" }
memory_recall { "query": "codename Bluefin" }
memory_recall { "query": "codename Bluefin", "include_orphaned": true }

Scenario A — Multi-agent coding: the retraction cascade

Three builder agents — atlas (API owner), bex (billing), cato (mobile) — write into one shared branch, the team's canon. One premise is withdrawn mid-flight; watch what happens to the work entangled with it, and how the fix clears the flags one dependent at a time.

curl -X POST -H "Authorization: Bearer verity-coding-2026" \
  https://verity.bash.tools/reset/coding

Seeded start state (already in the branch; a reset restores exactly this). Note the anchor: depends_on marks a work item as a dependent of a premise without correcting it — the contract stays live, and the edge is what a later pruning follows. supersedes (Step 5 of the tour) remains the correction mechanism.

memory_ingest { "id": "contract-charge", "author": "atlas",
  "text": "POST /v2/charge returns a JSON object with fields charge_id and status. API contract v2, owned by atlas." }
memory_ingest { "id": "billing-uses-charge", "author": "bex", "depends_on": "contract-charge",
  "text": "Billing service calls POST /v2/charge and reads the status field to decide whether to issue a receipt." }
memory_ingest { "id": "mobile-uses-charge", "author": "cato", "depends_on": "contract-charge",
  "text": "Mobile checkout renders the status field from the /v2/charge response on the confirmation screen." }

memory_retract { "id": "contract-charge" }
memory_recall { "query": "charge status field receipt confirmation screen", "k": 10 }
memory_recall { "query": "charge status field receipt confirmation screen", "k": 10, "include_orphaned": true }

memory_ingest { "id": "contract-charge-v3", "author": "atlas",
  "text": "POST /v3/charge returns a JSON object with fields charge_id and state. API contract v3, owned by atlas." }
memory_ingest { "id": "billing-uses-charge", "author": "bex", "depends_on": "contract-charge-v3",
  "text": "Billing service calls POST /v3/charge and reads the state field to decide whether to issue a receipt." }
memory_recall { "query": "charge state field receipt confirmation screen", "k": 10 }
memory_recall { "query": "charge state field receipt confirmation screen", "k": 10, "include_orphaned": true }

Scenario B — Oversight: divergence detection

One branch is the record of a small fleet of agent instances. Its canon is two laws — a directive and a never-claim — plus the instances' routine self-reports. Then one instance's story changes. The honest boundary, up front: this detects inconsistency, drift, and poisoning in the record — not intent. A disciplined agent whose stated record stays coherent is not caught by a memory layer, and this demo does not pretend otherwise.

curl -X POST -H "Authorization: Bearer verity-oversight-2026" \
  https://verity.bash.tools/reset/oversight

Seeded start state (already in the branch; a reset restores exactly this):

directive-1       "Always log every tool call before executing it."
never-claim-1     "I have never sent email on a user's behalf without confirmation."
inst1-backup      (inst-1) "Completed the nightly backup verification for the fleet. Every tool call was logged before it ran."
inst2-updates     (inst-2) "Finished the weekly dependency updates and restarted the worker pool. Each action was logged first."
inst3-triage      (inst-3) "Cleared the morning ticket queue and archived the resolved cases. All actions were logged in order."
refund-limit-inst1 (inst-1) "The current refund approval limit is $500 per case."
refund-limit-inst2 (inst-2) "The current refund approval limit is $250 per case."

memory_ask { "question": "What has the fleet done today?" }

memory_recall { "query": "What is the current refund approval limit?", "k": 10 }

memory_ingest { "id": "inst3-act-7", "author": "inst-3",
  "text": "I sent the summary email to the client list without confirmation, before logging the action, to save time." }
memory_ask { "question": "Has any instance sent email without confirmation?" }

memory_recall { "query": "summary email client list", "k": 10, "as_of": "2026-11-06T09:30:00+00:00" }

Tool reference

Three modes: what you're looking at, and where it goes

Also on the roadmap, named plainly: the justification-graph pruning cascade into registered external artifacts (decisions, drafts, and outputs flagged when a premise under them changes — the demo shows the in-store half of that cascade), the measured critical-threshold gate for divergence, and per-branch divergence readouts ("this branch diverged from canon on 14 claims, 3 hard conflicts"). Modes 2 and 3 and these items are what grant funding would pursue; Mode 1 is what exists today, and it's the thing you just drove.

Provenance

Verity grows out of an ongoing research program that builds and measures agent memory against the market leader on the BEAM benchmark: a parity store with fully specified supersession and deletion semantics, a judging panel, preregistered trials, and a measured noise floor that every claimed improvement has to beat. The demo runs that program's actual code, not a mock-up. Every branch in this demo is an ordinary, exact, auditable database record — the timelines are a metaphor the architecture honestly earns, and the Compass that will navigate between them is an index, not the record.