The decision database for AI systems.

Every AI decision should answer three questions:

  1. Why did the system decide that?
  2. What did the system know when it made it?
  3. Can we prove it?

InvariantDB records every decision, everything the system knew at the time, and the complete chain of evidence — so months later you can explain each one with confidence, instead of guessing.

“What did our system know at that time?” Drag the sliders. Watch the same query return different answers at different points in time — the audit chain doesn't move.

This is what “what did the system know?” looks like as a query. belief-99 was revised on 2026-06-01. Ask what it knew before the revision → HIGH_RISK 0.70. Ask what it knew afterLOW_RISK 0.95. Both are true. Both are provable.

The stack.

Give your AI a reason for every answer.

The advantage: every decision your AI makes comes with its own proof. Every fact it saw at the time, every step in the chain of evidence — queryable in one Cypher call. Months later, during an incident, or under audit.

01 · Provenance

Why did the system decide that?

Every belief carries its lineage. Ask any decision “how did you get here?” and the chain of derivations, evidence, and prior beliefs comes back with hashes attached.

CALL db.beliefLineage("belief-99") YIELD beliefId, claim, confidence, createdAt, depth RETURN claim, confidence, createdAt ORDER BY createdAt;
episode belief action action
02 · Bitemporal

What did the system know?

Two clocks on every value — valid time (when it was true) and recorded time (when you learned it). AT VALID and AT RECORDED are Cypher keywords, not conventions.

MATCH (m:Memory) AT RECORDED '2026-06-01T00:00:00Z' WHERE m.salience > 0.5 RETURN m ORDER BY m.salience DESC LIMIT 20;
valid time recorded v1 v2 · corrected
See the lattice Deadline valid = recorded Backdated → VALID TIME → RECORDED TIME → Jan Apr Jul Dec Jan Apr Oct Dec
03 · Crypto-shred

Can we prove it?

Prove it without leaking the subject. Per-subject encryption keys mean GDPR Article 17 erasure = destroy the key: the ciphertext becomes noise, but the audit chain survives to verify every prior decision.

CALL db.destroySubjectKey("user-42") YIELD subjectId, destroyedAtNanos RETURN subjectId, destroyedAtNanos;
subject:42 key: 0x9a... enc: ok shred subject:42 key: void enc: noise
For agents — humans + machines

Connect your AI in 30 seconds.

InvariantDB ships a Model Context Protocol server with 14 tools: Cypher query, fulltext + vector search, agent-memory primitives (record episodes, revise beliefs, replay), per-property provenance, audit replay. Wire it once; every Claude, Cursor, or Continue session sees the graph.

MCP endpoint
https://invariantdb.com/mcp

JSON-RPC 2.0 over HTTPS. Auth via Authorization: Bearer gq_.... Stdio mode also supported (npx gq-mcp).

Get an API key →  ·  Full tool catalog →

Claude Desktop config
// claude_desktop_config.json
{
  "mcpServers": {
    "invariantdb": {
      "command": "npx",
      "args": [
        "-y", "gq-mcp",
        "--remote",
        "https://invariantdb.com/mcp"
      ],
      "env": {
        "GQ_API_KEY": "gq_..."
      }
    }
  }
}
14 tools the agent gets, the moment it connects
Reads · cypher_query, get_node_by_str, get_edge_by_str
Search · search_fulltext, search_vector
Introspection · engine_info
Agent memory · record_episode, replay_episodes, belief_lineage
Compliance · subject_export, destroy_subject_key, acl_events
Provenance · property_provenance, derived_from

Defense-in-depth: the MCP server refuses mutations by default (a misbehaving agent can read, search, and audit; never CREATE / DELETE / SET unless you flip the explicit allow-mutate flag). Every tool call lands in the audit chain.

This is your data

Relationships you can see. History you can replay.

Every record, every approver, every counterparty — connected. And every edge is stamped with when we knew it. The three amber nodes? Those were filed after the policy lapse, backdated to before. Click-and-drag a node. This is live Cytoscape, the same renderer you get in the InvariantDB console.

Backdated claims Claims on record Adjusters Lines of business Policy lapse event
Live · backdating detection
Nodes 42
Edges 58
At lapse claims: 197
Now claims: 200
Compliance-native

Built for the regulations you actually answer to.

Every primitive maps to a specific control. Auditors see the receipts. Regulators see the chain. Your customers see the confidence.

GDPR Art. 17 + 20
Right to erasure & data portability
Erase the subject. Preserve the audit chain.
db.destroySubjectKey erases the subject's key; db.subjectExport returns the portable record.
HIPAA §164.312(c)(1)
Integrity
Every fact carries a hash chain. Tampering breaks verification.
db.verifyAclChain returns the break point.
SOX §404
Internal controls over financial reporting
Reproduce the state of any record at the exact moment a control was exercised.
Tamper-evident history + bitemporal replay (AT VALID / AT RECORDED).
NYDFS §500.06
72-hour incident reconstruction
Replay the exact state the system had when the incident occurred. No log reassembly.
AT RECORDED '<incident-time>'
DORA Art. 17
ICT incident record retention
Immutable snapshot chain, cryptographically anchored.
Retention configurable per graph.
PCI DSS Req 10
Audit trail integrity
Every read and every mutation lands in the audit chain.
db.proveErasure returns a receipt with the anchor hash.
Receipts

Audit-grade, and fast.

"Compliance-friendly" usually means "slow." Not here. 536,000 nodes. 810,000 edges. A $30/month ARM instance. Here's what a single query costs.

MATCH ... RETURN count(*)
1-hop count, 131K edges
Previous
1,813 ms
InvariantDB
97 ms
18.7× faster
MATCH (a)-[:T]->(b)-[:T]->(c)
2-hop traversal, 20K rows
Previous
3,852 ms
InvariantDB
586 ms
6.6× faster
MATCH ...-[:T*3]->...
3-hop traversal, 400K rows
Previous
7,581 ms
InvariantDB
1,392 ms
5.5× faster
// t3.medium ARM · 89 MB resident · bitemporal enabled · no warm cache
// Receipts Tested &
shipped.
2,000+ Tests across the engine
37 Bitemporal correctness cases
23 Hash-chain integrity cases
29 Crash-recovery cases
4 Layers of backup & DR
For developers

Record the episode. Replay the state. Ship the fix.

Every prompt, tool call, and belief revision lands as a first-class node with two clocks. When an agent misfires in prod, you replay the exact context it saw — not a summarized log — and prove whether the model reasoned correctly on stale data or drifted on its own.

Cypher reference · procedures index →
1
Sev1 replay in one query. MATCH the session AT RECORDED at incident-time; the answer changes, the audit chain doesn't.
2
Vector + graph in one hop. gds.semanticMatchExpand seeds by cosine, expands by edge type. No two-store round-trip.
3
One binary, aarch64. Runs on a $30/mo Graviton box for 536k nodes with sub-100 ms bitemporal counts.
agent-episode-and-recall.cypher
// A tool call misfired at 09:15 — replay the exact state.

CALL db.recordEpisode("conv-42", "tool_call", "ran cypher_query against Account graph",
                     '{"args":{"q":"MATCH (a:Account {id:99})-[:TRANSACTED]->(t) RETURN t LIMIT 50"}}')
  YIELD eventId, ts RETURN eventId, ts;

// Replay what the agent saw as of yesterday morning.
MATCH (s:Session {id: "conv-42"}) AT RECORDED '2026-07-05T09:15:00Z'
CALL db.replayEpisodes("conv-42", 100) YIELD eventId, kind, ts, text
RETURN kind, text, ts ORDER BY ts;

// Vector-seeded graph expansion — find similar prior sessions and
// walk the 2-hop neighborhood. No round-trip to Pinecone.
CALL gds.semanticMatchExpand("Document", "embedding",
                              [0.12, 0.44, 0.71, /* … 1536-dim … */],
                              2, 5)
  YIELD nodeId, hops, score
RETURN nodeId, hops, score
ORDER BY hops, score DESC LIMIT 50;