The situation
The platform holds a separate database per program, each with a different shape. Medical and commercial users have questions the interface has no screen for, and no way to ask them.
A generic text-to-query tool was not an option. Anything that can write a query against a live clinical estate is a governance problem, not a feature.
How we made it safe to ship
- Read-only by policy. The pipeline can only issue read operations against MongoDB. This is enforced in the query layer, not left to prompt instructions.
- No implicit database. There is no server-side default. Every query and every conversation call must name its database, so a misrouted request fails rather than silently answering from the wrong program.
- Schema inferred and cached. Collections are profiled once and reused, so the model reasons over a known shape instead of guessing, and cost stays predictable.
- A conversational fast path. Questions that are not data questions never touch the database, which removes both a latency cost and an attack surface.
- Rate limiting and cost tracking. Per-client limits on the query endpoints and a per-run cost record, so spend is attributable before the invoice arrives.
- Streaming with persistence. Answers stream as they are produced over server-sent events, and every conversation is stored in the same database it queried, keeping tenancy intact.
One service, many programs
Each program keeps its own database. The service holds no default and no hard-coded shape, so onboarding a new program requires no code change. Follow-up questions resolve against what was already asked, so a user can narrow a result the way they would with a colleague. Answers are generated with Anthropic Claude.
What it changed
Questions that previously required a ticket to a data team, a query written by hand and a wait measured in days are now answered in the flow of work, with the generated query available for anyone who wants to check it.
Just as importantly, the read-only guarantee is a property of the system rather than a promise in a document, which is what made it approvable in a regulated environment.
Documentation as a deliverable
The system shipped with a written architecture covering the request lifecycle, the module map, the streaming event contract, the environment variable surface, the read-only policy and the front-end integration guide. A team that did not build it can run it.
How the read-only guarantee works in practice: Read-only by policy: making text-to-query safe in a regulated data estate.