Architecture

How Domino works

Domino is a team of agents that use FalkorDB as their only source of truth. They decide which graph queries to run, act by writing findings, tasks and notes back into the graph, remember what the care team decided and did, learn how to route their work, and show the path behind every answer. Each clinic is its own graph: Riverside Family Health and Lakeview Geriatric Clinic in this demo.

Detective

Walks the graph to find cascades, loops and combined harm, then records findings.

read get_patient_context
read recall_memory
read find_cascades
read check_harms
write record_findings

Pharmacist

Checks the evidence, other reasons, safer options and the what-if for each root.

read recall_memory
read check_harms
read explain_link
read find_safer_alternatives
read simulate_untangle
read population_signal
read find_chokepoints
read trace_route
read resolve_drug

Scribe

Turns the findings into review tasks and draft notes for humans to approve.

write propose_task
write draft_note

Track 1 · Agents that act on connected data

Decide with the graph, act on the graph

Multi-hop reasoning. Variable-length paths over CAUSES and TREATED_BY, constrained to the patient’s own medicines; cycles; harm chains.
Graph queries and algorithms as tools. 14 agent tools over the catalog, including betweenness centrality (find_chokepoints, which sets task priority in every review) and allShortestPaths (trace_route), plus sequence symmetry across the population. Every medicine a question names is resolved against the graph first; one it does not know is said to be unchecked.
Tool selection through MCP. Ask Domino and the care-team brain call every tool through Domino’s own MCP server; with a language model they discover the tools there too and the model chooses them. Every result carries the catalog query ids in its metadata, so answers can cite them.
Actions from what the graph shows. Findings, routed tasks and draft notes written back; a prescriber check that stops a documented cascade before it is written; a new prescription re-runs the Detective.
Explainable results. A provenance graph behind every finding: the run, the step, the queries it ran, the evidence, the memory it used, the handoffs that carried it and the tasks it led to.

Track 2 · Agent memory and coordination

Remember, learn, hand off

Episodic. Runs, steps, findings, signed decisions; each run starts with what changed since the last one.
Semantic. Decisions attach to Pattern nodes, so feedback accumulates across patients; the knowledge graph itself.
Procedural. Procedure nodes say who a task goes to and for which tier, learned from decided tasks, versioned with SUPERSEDES and LEARNED_FROM.
Conversation history. Every question and answer is a Message in a Conversation owned by one person; follow-ups resolve against it, days later.
Shared state and handoffs. Signed Handoff nodes, read back and verified, linked to the findings they carry; a lease node so only one review per patient runs across every instance.
Concurrency. Benchmarked: parallel agent runs reading and writing one graph, with the lease and tenant isolation checked under load (docs/BENCHMARK.md).
Per tenant and per user. One FalkorDB graph per clinic; conversations per person.

Track 3 · A care-team brain

How the clinic works

Docs, tickets and chats in one graph. Team notes (protocols, handovers, chats) linked to the drugs, symptoms and patients they name, next to tasks, decisions, findings and conversations, with one full-text search across them.
Who owns what. Prescriber nodes behind every drug; tasks addressed to the prescriber who owns the root drug.
Who knows what. Who has acted on or decided each kind of cascade.
Decisions traced to their source. Task → the procedure it followed → the decided tasks that procedure learned from.
Knowledge kept current. Findings superseded on every run, “what changed” recorded, procedures re-learned on every decision, labels cross-checked against openFDA.
Answers with clear sources. The care-team brain cites every tool call and graph query behind an answer.

The core query

A cascade is a path

MATCH (p:Patient {id: $pid})-[:TAKES]->(m:Drug)
WITH p, collect(m.id) AS meds
MATCH (p)-[:TAKES]->(a:Drug)-[:CAUSES]->(:Effect)-[:TREATED_BY]->(:Drug)<-[:TAKES]-(p)
WITH DISTINCT a, meds
MATCH path = (a)-[:CAUSES|TREATED_BY*2..6]->(z:Drug)
WHERE z <> a AND all(n IN nodes(path) WHERE NOT n:Drug OR n.id IN meds)
RETURN [r IN relationships(path) | [startNode(r).id, type(r), endNode(r).id]] AS hops

MATCH (p:Patient {id: $pid})-[ta:TAKES]->(a:Drug)-[c:CAUSES]->(e:Effect)-[tr:TREATED_BY]->(b:Drug)<-[tb:TAKES]-(p)
WHERE a <> b
OPTIONAL MATCH (a)-[:IN_CLASS]->(:DrugClass)<-[:INDEX]-(pt:Pattern)-[:VIA]->(e),
               (pt)-[:MARKER]->(:DrugClass)<-[:IN_CLASS]-(b)
RETURN a.id AS from, a.name AS fromName, b.id AS to, b.name AS toName, e.id AS effect, e.name AS effectName,
       e.plain AS effectPlain, c.freq AS freq, c.weight AS weight, c.onsetMin AS onsetMin, c.onsetMax AS onsetMax,
       tr.line AS line, ta.start AS fromStart, tb.start AS toStart, tb.indication AS toIndication,
       collect(DISTINCT pt.id) AS patterns

Graph model · knowledge and patients

Graph model · memory, provenance and the care team

Every query Domino runs

The Cypher catalog (105)

There is no other Cypher in the app. User input only reaches FalkorDB as a parameter; reads run as GRAPH.RO_QUERY, so the database itself refuses writes; and the agents can only write through the fixed templates marked write.

readLoad the patientpatientDemographics, diagnoses and the medication timeline.

MATCH (p:Patient {id: $pid})
OPTIONAL MATCH (p)-[h:HAS]->(c:Effect)
WITH p, collect({id: c.id, name: c.name, plain: c.plain, since: h.since}) AS conditions
OPTIONAL MATCH (p)-[t:TAKES]->(d:Drug)-[:IN_CLASS]->(k:DrugClass)
RETURN p.id AS id, p.name AS name, p.age AS age, p.sex AS sex, p.persona AS persona,
       p.headline AS headline, p.story AS story, p.sandbox AS sandbox, p.expiresAt AS expiresAt, conditions,
       collect({id: d.id, name: d.name, cls: k.id, clsName: k.name, acb: d.acb, beers: d.beers,
                start: t.start, dose: t.dose, prescriber: t.prescriber, indication: t.indication, assumedDate: t.assumedDate}) AS meds

readList patientspatient_listEvery patient with medication count and the latest review summary written by the sweep.

MATCH (p:Patient)
WHERE p.sandbox IS NULL
OPTIONAL MATCH (p)-[:TAKES]->(d:Drug)
WITH p, count(d) AS meds
RETURN p.id AS id, p.name AS name, p.age AS age, p.sex AS sex, p.persona AS persona,
       p.headline AS headline, meds, p.likely AS likely, p.possible AS possible,
       p.acb AS acb, p.topScore AS topScore, p.topLink AS topLink, p.topLinkScore AS topLinkScore, p.avoidable AS avoidable, p.reviewedAt AS reviewedAt
ORDER BY p.persona DESC, p.topScore DESC, p.name

readFind one-step cascade linkscascade_linksPairs of the patient’s own drugs where drug A causes an effect that drug B treats, with timing, the recorded indication and any matching documented pattern.

MATCH (p:Patient {id: $pid})-[ta:TAKES]->(a:Drug)-[c:CAUSES]->(e:Effect)-[tr:TREATED_BY]->(b:Drug)<-[tb:TAKES]-(p)
WHERE a <> b
OPTIONAL MATCH (a)-[:IN_CLASS]->(:DrugClass)<-[:INDEX]-(pt:Pattern)-[:VIA]->(e),
               (pt)-[:MARKER]->(:DrugClass)<-[:IN_CLASS]-(b)
RETURN a.id AS from, a.name AS fromName, b.id AS to, b.name AS toName, e.id AS effect, e.name AS effectName,
       e.plain AS effectPlain, c.freq AS freq, c.weight AS weight, c.onsetMin AS onsetMin, c.onsetMax AS onsetMax,
       tr.line AS line, ta.start AS fromStart, tb.start AS toStart, tb.indication AS toIndication,
       collect(DISTINCT pt.id) AS patterns

readTrace multi-hop cascade chainscascade_pathsVariable-length walk over CAUSES and TREATED_BY edges that stays inside the patient’s medication list: drug → effect → drug → effect → drug, up to three drug-to-drug hops. It starts only from drugs with at least one direct link, which cuts the search by about five times.

MATCH (p:Patient {id: $pid})-[:TAKES]->(m:Drug)
WITH p, collect(m.id) AS meds
MATCH (p)-[:TAKES]->(a:Drug)-[:CAUSES]->(:Effect)-[:TREATED_BY]->(:Drug)<-[:TAKES]-(p)
WITH DISTINCT a, meds
MATCH path = (a)-[:CAUSES|TREATED_BY*2..6]->(z:Drug)
WHERE z <> a AND all(n IN nodes(path) WHERE NOT n:Drug OR n.id IN meds)
RETURN [r IN relationships(path) | [startNode(r).id, type(r), endNode(r).id]] AS hops

readFind feedback loopsfeedback_loopsCycles where each drug can cause a problem that another of the patient’s drugs is treating.

MATCH (p:Patient {id: $pid})-[:TAKES]->(m:Drug)
WITH p, collect(m.id) AS meds
MATCH (p)-[:TAKES]->(a:Drug)
MATCH path = (a)-[:CAUSES|TREATED_BY*4..6]->(a)
WHERE all(n IN nodes(path) WHERE NOT n:Drug OR n.id IN meds)
RETURN [r IN relationships(path) | [startNode(r).id, type(r), endNode(r).id]] AS hops

readCheck for other reasonsalternative_reasonsFor each of the patient’s drugs, diagnoses on record that the drug also treats. A second drug with its own diagnosis is less likely to be a cascade.

MATCH (p:Patient {id: $pid})-[:TAKES]->(b:Drug)<-[tr:TREATED_BY]-(c:Effect)<-[h:HAS]-(p)
RETURN b.id AS drug, collect({id: c.id, name: c.name, since: h.since, line: tr.line}) AS reasons

readFind side-effect pile-upspileupsEffects that two or more of the patient’s drugs cause at once.

MATCH (p:Patient {id: $pid})-[:TAKES]->(d:Drug)-[c:CAUSES]->(e:Effect)
WITH e, collect(DISTINCT {id: d.id, name: d.name, freq: c.freq}) AS drugs
WHERE size(drugs) >= 2
RETURN e.id AS id, e.name AS name, e.plain AS plain, e.kind AS kind, drugs
ORDER BY size(drugs) DESC

readTrace drugs to serious harmsharm_pathsDrugs that reach falls, fractures or kidney injury, directly or through up to two RAISES steps (dizziness → falls → fracture).

MATCH (p:Patient {id: $pid})-[:TAKES]->(d:Drug)-[:CAUSES]->(e:Effect)-[:RAISES*0..2]->(h:Effect)
WHERE h.id IN $harms
RETURN h.id AS harm, h.name AS harmName, d.id AS drug, d.name AS drugName, collect(DISTINCT e.name) AS via

readMatch dangerous combinationsdangerous_combosNamed combinations (triple whammy, bleeding stack, sedation stack) completed by the patient’s drug classes.

MATCH (p:Patient {id: $pid})-[:TAKES]->(d:Drug)-[:IN_CLASS]->(:DrugClass)<-[g:GROUP]-(combo:Combo)
WITH combo, g.g AS grp, collect(DISTINCT d.name) AS drugs
WITH combo, collect({grp: grp, drugs: drugs}) AS groups
WHERE size(groups) = combo.groups
MATCH (combo)-[:HARM]->(h:Effect)
RETURN combo.id AS id, combo.title AS title, combo.why AS why, combo.refs AS refs, h.name AS harm, groups

readAnticholinergic burden and Beers flagsburdenAnticholinergic Cognitive Burden points and AGS Beers 2023 notes for each drug.

MATCH (p:Patient {id: $pid})-[:TAKES]->(d:Drug)
WHERE d.acb > 0 OR d.beers IS NOT NULL
RETURN d.id AS id, d.name AS name, d.acb AS acb, d.beers AS beers

readFind safer alternativessafer_alternativesDrugs that treat the same diagnosis as the root drug, do not cause the problem, and are checked against the patient’s conditions, current drugs and class conflicts.

MATCH (p:Patient {id: $pid})-[ta:TAKES]->(a:Drug {id: $drug})
MATCH (a)<-[:TREATED_BY]-(ind:Effect)
WHERE (p)-[:HAS]->(ind) OR ta.indication = ind.id
MATCH (ind)-[tr:TREATED_BY]->(alt:Drug)-[:IN_CLASS]->(ac:DrugClass)
WHERE alt <> a AND NOT (p)-[:TAKES]->(alt) AND NOT (alt)-[:CAUSES]->(:Effect {id: $effect})
OPTIONAL MATCH (p)-[:TAKES]->(cur:Drug)-[:IN_CLASS]->(:DrugClass)-[av:AVOID_WITH]-(ac)
WHERE cur <> a
OPTIONAL MATCH (alt)-[:CAUSES]->(worse:Effect)<-[:HAS]-(p)
OPTIONAL MATCH (alt)-[:CAUSES]->(pile:Effect)<-[:CAUSES]-(other:Drug)<-[:TAKES]-(p)
WHERE other <> a
RETURN alt.id AS id, alt.name AS name, ac.name AS clsName, tr.line AS line, ind.name AS forCondition,
       alt.acb AS acb, alt.beers AS beers, collect(DISTINCT av.why) AS conflicts,
       collect(DISTINCT worse.name) AS worsens, collect(DISTINCT pile.name) AS adds

readCheck a new prescriptionprescriber_checkBefore a new drug is added: is it treating a side effect of something the patient already takes?

MATCH (p:Patient {id: $pid})-[ta:TAKES]->(a:Drug)-[c:CAUSES]->(e:Effect)-[tr:TREATED_BY]->(n:Drug {id: $drug})
WHERE a <> n AND ta.start < $asOf AND NOT a.id IN $exclude
OPTIONAL MATCH (a)-[:IN_CLASS]->(:DrugClass)<-[:INDEX]-(pt:Pattern)-[:VIA]->(e),
               (pt)-[:MARKER]->(:DrugClass)<-[:IN_CLASS]-(n)
OPTIONAL MATCH (p)-[h:HAS]->(e) WHERE h.since <= $asOf
RETURN a.id AS from, a.name AS fromName, e.id AS effect, e.name AS effectName, e.plain AS effectPlain, c.freq AS freq,
       c.weight AS weight, c.onsetMin AS onsetMin, c.onsetMax AS onsetMax, tr.line AS line,
       ta.start AS fromStart, h IS NOT NULL AS diagnosed, collect(DISTINCT pt.id) AS patterns

Use Domino from any MCP client

The same tools run as a stdio MCP server for one clinic (DOMINO_CLINIC): patient tools, the prescriber check, and the care-team brain (search_team_memory, who_knows, care_team_flows, learned_procedures), plus the query catalog and the graph model as MCP resources. Read-only by default; DOMINO_MCP_ALLOW_WRITES=true adds run_review.

{
  "mcpServers": {
    "domino": {
      "command": "npx",
      "args": ["tsx", "scripts/mcp-server.ts"],
      "cwd": "/path/to/domino",
      "env": { "FALKORDB_URL": "redis://localhost:6379", "DOMINO_CLINIC": "riverside" }
    }
  }
}

Clinical safety

Domino raises questions. A guardrail checks everything an agent writes or says (tasks, notes, handoffs, answers) and holds back anything that tells someone to stop, start, switch or change the dose of a medicine.
Deliberate pairings (stomach protection with an NSAID, potassium with a diuretic, B12 with metformin) are recognised and set aside.
The what-if is labelled a simulation and always names other contributors.
Every action is a proposal until a person approves it.
The what-if says which medicines need a gradual taper if changed (benzodiazepines, antidepressants, beta blockers, levodopa and others).
In the prescriber check, a planned companion (a PPI with an NSAID) never raises a cascade stop by itself, and a link the engine scores unlikely raises nothing.
Synthetic data only: no real patient information is ever loaded.

Interoperability

Inside any EHR, over CDS Hooks

EHRs call outside decision support at the moment of prescribing through CDS Hooks 2.0 (HL7). Domino is a CDS service: GET /cds-services lists domino-order-select and domino-order-sign; a call carries the draft MedicationRequest and, as prefetch, the active medicines and conditions. Domino runs the prescriber check on the graph and answers with cards: a summary, a markdown detail, a suggestion that deletes the draft order, and override reasons that mirror its signed decisions.

A patient Domino holds is checked against their record; anyone else from the prefetch, as a temporary check-up patient with no name kept.
Every card is a CdsCard node (ABOUT the patient, CHECKED the drug ordered, CULPRIT the drug whose side effect it treats), and the EHR’s feedback is recorded on it, first answer only.
Medicines match by name through the full-text index, and only when the generic or brand name is really in the text. No RxNorm mapping yet, so an order that matches nothing gets an info card saying Domino did not check it: not in the graph is not the same as safe.
CORS for these routes only; rate-limited; stored cards capped at 2,000; with DOMINO_WRITE_KEY set, outside callers can only check patients Domino holds.
With DOMINO_CDS_ISSUERS set, every call needs the EHR’s signed token (ES384 or RS384, checked against its JWKS, audience, five-minute lifetime, one use). Without it the service runs as an open demo.

Try it in the demo EHR

A card, as the EHR receives it

{
  "summary": "Benztropine may be treating a side effect of
              Risperidone: a possible prescribing cascade",
  "indicator": "warning",
  "detail": "Benztropine treats parkinsonism (EPS), a known
             side effect of Risperidone …",
  "source": { "label": "Domino · prescribing cascade check" },
  "suggestions": [{
    "label": "Hold Benztropine and review Risperidone first",
    "actions": [{ "type": "delete",
                  "resourceId": ["MedicationRequest/draft-1"] }]
  }],
  "selectionBehavior": "at-most-one",
  "overrideReasons": [
    { "code": "intentional" }, { "code": "not-a-cascade" },
    { "code": "will-review" }
  ]
}

Security

OWASP Top 10:2025, LLM Top 10 and Agentic Top 10

A01 Broken Access Control	Each clinic is its own FalkorDB graph, chosen on the server from the session and never from a parameter. A run is bound to one patient; agents cannot pass a patient id. Conversations are scoped to the person. Writes need same-origin requests and, when set, an access key. Only humans write decisions.
A02 Security Misconfiguration	Nonce-based CSP, frame-ancestors none, nosniff, strict referrer policy, no x-powered-by, HSTS in production.
A03 Software Supply Chain	Exact-pinned dependencies, lockfile, zero npm audit findings, no install scripts of our own, ESLint chain dropped to remove a vulnerable transitive dependency.
A04 Cryptographic Failures	HMAC-SHA256 signatures on handoffs, tasks and decisions with timing-safe comparison; secrets only in server env.
A05 Injection	No string-built Cypher anywhere: 105 named, parameterised queries. Free text reaches the full-text index only as plain lower-case words (no search operators). Id lookups use null-prototype maps. LLM output is never executed as code or Cypher, and React escapes all text.
A06 Insecure Design	Human approval on every action, per-run write limits, a wording guardrail that rejects instructions to change medicines.
A07 Authentication Failures	Optional access key exchanged for an httpOnly, SameSite=Strict cookie; constant-time comparison.
A08 Data Integrity Failures	Signed records are verified on read; a forged decision or task is ignored and flagged.
A09 Logging & Alerting	Every agent step is a Step node linked to the catalog queries it ran and to what it wrote: a provenance graph you can query. Server logs omit secrets and patient data.
A10 Exceptional Conditions	Typed errors mapped to safe HTTP responses, timeouts on LLM calls, model fallbacks, a planner when no LLM is set.

LLM01 / ASI01 Prompt injection, goal hijack	Record content is wrapped as data; tools never take free text into Cypher; agent goals are fixed by role prompts and tool subsets.
LLM06 / ASI02 Excessive agency, tool misuse	Least privilege per agent (Detective cannot draft notes, Scribe cannot read other patients), read tools are database-enforced read-only.
ASI06 Memory poisoning	Only people write decisions, every decision is signed (verdict and reason) and verified before an agent uses it. Procedures change only from decided tasks, by a plain rule, and link to the tasks they learned from.
ASI07 Insecure inter-agent communication	Handoffs are stored in FalkorDB, signed, read back and verified; a failed check stops the run.
LLM09 / ASI09 Misinformation, trust exploitation	Every claim carries its graph path and evidence label; the UI shows the Cypher; outputs are questions, not orders.
LLM10 Unbounded consumption	Rate limits per client and bucket, step and token budgets per agent, a bounded conversation history, timeouts, one run per patient at a time across every instance (a graph lease), and a cap on open check-ups.
ASI03 Identity and privilege abuse	Tenant isolation by graph; the clinic-wide brain is read-only and confined to the session’s clinic graph; the MCP server serves one clinic per process.

Data and disclosure

The knowledge graph (116 drugs, 50 effects, 268 CAUSES and 189 TREATED_BY edges, 27 documented patterns, 4 dangerous combinations) was curated by hand from product labelling, the AGS Beers Criteria 2023, the Anticholinergic Cognitive Burden scale, ThinkCascades and published studies, with references stored on each pattern. Patients are synthetic, produced by a seeded generator in this repository. AI coding assistants were used while building Domino; the team reviewed, tested and can explain every part of it.