What we’re building — stage by stage, in the open.
bonfireDB is pre-launch. We’re building it in public, in order, and we mark what’s in progress vs what’s ahead unmistakably. This is the real sequence — the same plan we use internally — so you can see exactly what each stage is and what it unlocks. A backend you trust starts with a roadmap you can trust.
What bonfireDB actually is
You own one Postgres database. You write typed clinical functions (clinical.observations.record()) instead of raw FHIR. Common reads are kept fresh inside the write transaction and pushed to your UI reactively. FHIR R4 is the canonical record underneath for export and interop — we are not a FHIR server you program against; we’re the app backend above one. And the part that’s the moat: a clinical context compiler that lets an LLM read — and safely aggregate — the record without ever crossing a patient’s boundary. Everything below is how we get there, in order.
How to read the status: Building now = in active development. Next / Then = sequenced, designed, not yet built. Research track = measured in public before it becomes product. Later = committed direction, undated. If a stage isn’t marked “Building now,” assume it isn’t shipped.
Foundations: one Postgres, and the safety gate
The base everything sits on — and the single hardest, riskiest piece, built first because the whole agent layer depends on it being airtight.
What we’re building
- One canonical Postgres store — FHIR R4 as JSONB — with typed read models on top
- Committed read models maintained inside the write transaction → fresh on commit
- The deterministic query-and-compartment gate (a sandbox is one way to enforce it, not the headline): an agent can read/aggregate only inside the patient, tenant, consent, and purpose boundaries it was granted
What it proves
- Reads are current the instant a write returns — no cache, no cron, no second store
- Cross-patient leakage stays blocked under adversarial/property tests — the gate the rest of the agent layer ships behind
- (In parallel) benchmark data access requested, so the open eval isn’t blocked later
The one gate + the typed SDK
Make authorization, consent, and audit a single unbypassable path — not something each handler has to remember.
What we’re building
- ABAC (rules for who can see which patient) + consent enforced on every read and write, through one choke point
- Automatic audit + provenance as a side effect of access — including denials
- The typed clinical.* SDK: primitives with end-to-end types
What you can build
- Clinical CRUD without hand-rolling an authz layer or a HIPAA audit log
- A consent grant that closes access the moment it’s withdrawn — across every path
Reactive reads
Your UI reflects the database without you wiring up invalidation.
useClinicalQuery
Subscribe to a read model; when a write commits, the change is pushed to the client in commit order.
Postgres-native transport
LISTEN/NOTIFY for low latency + a write-ahead-log backstop for ordered, durable catch-up after a disconnect. No Redis, no separate broker.
The freshness object
Every write tells you which views are fresh and which heavy indexes are still pending — so nothing silently rots.
SMART-on-FHIR + FHIR underneath
Be a real SMART app and a clean interop citizen — without running a FHIR server.
What we’re building
- Standalone SMART App Launch (OAuth2 + PKCE, patient-scoped) so your app launches as a SMART-on-FHIR app
- FHIR R4 generated on demand — a clean Bundle for export, migration, or sharing
What it proves
- An external SMART client / Inferno (the ONC conformance suite) reads your generated FHIR — interop demonstrated, not asserted
- Leaving is a function call, not a migration — no lock-in
The clinical context compiler
Bonfire is not a prompt pack, a set of skills, or one canned MCP server. It is the governed clinical data layer underneath the agent: query-aware evidence packets, scoped MCP tools, deterministic reducers, source citations, and policy enforcement before context ever reaches a model. Agent context tools →
What we’re building
- Query-aware evidence packets: resource intent, patient scope, date window, first/latest preservation, freshness, citations, and denial reasons as structured data
- The MCP compiler: every typed function can become a scoped, schema’d MCP tool — one definition, three surfaces
- Clean, reference-resolved, code-resolved clinical context — not multi-million-token JSON dumps
- Structured operators for the recurring hard parts: typed query planning, Observation/code normalization, deterministic counts/extrema, and citation verification
- Optional compute/sandbox paths only where they beat the governed in-context read layer; not assumed as the requirement
Safe by default
- Patient/tenant scope enforced on every call
- Writes are propose-only — the agent drafts, a human commits
- Every result cited to its source record; every read audited
Safe aggregation, open evals, and gated skills
The second badge, with receipts. The leading benchmark excludes cohort questions over raw FHIR. We make aggregation answerable under policy, then test the agent interface with separate arms for the data layer, skills, MCP tools, and structured clinical operators.
ABAC-enforced aggregation
Ask “how many of my patients scored ≥10 on PHQ-9 this month” — answered over the same projections, scoped to your compartment and consent, with small-cell suppression so a cohort can’t leak an identity. App-scale, never cross-org.
The open benchmark
Planned product benchmark: synthetic Synthea, deterministic DB/FHIR state grading, and a required cross-tenant leak rate of zero. It has not produced a Bonfire result. The separate research track now spans 15 experiments; the headline entries:
- A6a — question-aware selection, measured twice: +9.5pp, then +8.3pp in the assumption-fixed replication.
- QT-4 — fixed microbiology vocabulary promoted on its 44 registered holdout questions (+34.1pp).
- A11 — bounded traversal recovered terminal evidence on 96/96 answerable constructed path questions; event grouping was not promoted.
- QT-1..3 — three packet-structure nulls; W1a/W2a — exploratory join tests; A11b — withdrawn after forensic review.
This supports a frozen retrieval mechanism, not Bonfire or graph-native storage. All 15 experiments → · See the eval →
Honest status on the research evidence: the separate MIMIC-IV-on-FHIR comparison ran; the open Bonfire product benchmark has not. On that secondary external comparison (MIMIC-IV-on-FHIR, a FHIR-AgentBench fork; 409 paired questions, trustworthy multi-judge grading, red-teamed), the levers engineers reach for were nulls once the chart fit in context — typed tools null (+0.08, p=0.69), payload shaping ~0, more thinking 0/30 judged-label flips. The one thing that moved accuracy was getting the right, bounded slice of the record into context; blunt projection recovered only about a third, so the lever the evidence points to is query-aware clinical context. Skills are interesting research, especially when paired with MCP/tools, but they are not the product by themselves: the load-bearing layer is governed retrieval, deterministic selection, citations, policy, and audit.
Research track: skills + MCP/tools. We will test separable questions instead of bundling them into one claim: raw generic FHIR tool, generic FHIR tool + skill, governed read tools alone, and governed read tools + skill. If skills help, they become a thin task-playbook layer over Bonfire. If they do not, the roadmap stays data-layer first — and that is still the central thesis.
Hybrid memory, real MCP, hardening & scale
Committed direction, sequenced by what design partners actually need — undated.
- Hybrid clinical memory for notes and longer text — BM25 + vector + rerank after hard patient/date/code/permission filters
- Real governed MCP read contract with versioned schemas, source-ID manifests, and principal-aware capability projection — the tool surface an agent sees depends on who it acts for, not just a server-wide capability list
- Policy-aware FHIR reference and temporal projection: deterministic source-path edges, bounded traversal, and path-level citations. Start as a rebuildable Postgres projection; consider native graph storage only after byte-equivalent packets pass latency, cost, correction/deletion, and authorization-leakage gates
- EHR-launch SMART (in-context), beyond standalone launch
- Offline & local-first sync — optimistic local writes, durable queue, versioned reconciliation (post-launch)
- File & attachment storage in your own S3 — wired to FHIR DocumentReference / Media / Binary, same ABAC and audit
- Standard coding everywhere — LOINC / SNOMED CT / RxNorm with version-pinned validation
- Field-level envelope encryption + time-bound break-glass
- Differential-privacy budgets for adaptive aggregate queries
- The full multi-model benchmark sweep + regression-gated clinical playbooks for agents
- SOC 2 / HITRUST — earned, not claimed
We dogfood the whole stack on our own app
We’re rebuilding TicVision — our Tourette’s symptom tracker, currently a React Native app on a custom DynamoDB backend — on Bonfire as a SMART-on-FHIR app. Each stage must replace part of TicVision’s hand-built database, CRUD, or HIPAA audit log. If it cannot carry our own app, it is not done. The TicVision rebuild →
The bet
Land as the agent-native operational store, then become the backend the next generation of AI-native health apps are built and run on — agents that read and aggregate the record safely inside the customer boundary. We don’t claim a moat we haven’t built; at this stage, our honesty is the product. We earn it one app, one agent, one audited read at a time. Read the vision →
You build the app. Bonfire is the clinical data layer underneath.
bonfireDB is in early access, built in the open. Join the waitlist and follow along — or come build a stage with us as a design partner.