Orvana
Reports drafted by AI, released only after a licensed clinician signs them.
- AI engineering
- Full-stack engineering
- AI engineering
- Product design
- Health
Overview
Orvana is a consumer oral microbiome test kit built for Southeast Asia, starting in Singapore. A customer orders a kit, swabs at home, and sends the sample back. A partner lab sequences it, our pipeline processes the results, and an AI engine drafts a report of oral microbiome insights. A licensed clinician reviews and signs every report before a customer can see it.
I joined in August 2026 as Head of Engineering. I design and build the report engine and the platform around it: the customer portal, the ops dashboard, the sequencing pipeline, and the clinician review tooling. The product is in testing and has not launched.
This page is about the techniques behind the engine, at pattern level. The interesting work was not getting a model to write. It was building the machinery that makes the writing safe to release.
Ops that run from a pocket
The Problem
Putting generated text inside a health product is easy to do badly. A language model will write something plausible about any input you hand it, and plausible is not a standard a clinician can put their name under.
Three things made this harder than a normal AI feature. The output reads like advice, so the wording carries real responsibility. The evidence base shifts, because microbiome literature moves and yesterday's retrieval is not today's. And health data is regulated, so where bytes live and who can see them is a design input, not an afterthought.
So the real problem was never the drafting. It was making the output checkable: every claim traceable to evidence we chose on purpose, every release owned by a named person, every result reproducible months later.
Constraints
| Constraint | What it forced |
|---|---|
| Personal data under Singapore's PDPA | Data stays in its region; the lab only ever sees pseudonymous sample IDs |
| A clinician answers for every report | A hard gate in the release path, and tooling shaped around clinician hours |
| Careful claim language | Reports give oral microbiome insights, not a diagnosis; wording is reviewed like code |
| A small team running a physical product | Few moving parts, boring infrastructure, ops flows a two-person crew can actually run |
Architecture
The system is a straight line with one gate. Kits come back as sequencing results through a lab intake that works on pseudonymous IDs. Results process in an asynchronous job pipeline: batch-shaped runs with resumable stages, because a multi-hour run should never start over for a failure in its last step. The report engine drafts against a pinned release of a curated knowledge base. Drafts queue for clinician review. Only signed reports reach the customer portal.
Techniques
Reports cite a curated knowledge base, nothing else. At drafting time the engine retrieves evidence only from a knowledge base our team curates, approves by hand, and publishes as versioned releases. There is no live literature search anywhere in the release path. Every report pins the exact release it drafted against, so a released report can be re-derived exactly, long after the literature has moved on.
A sign-off gate, not a review culture. A report moves through draft, under review, signed, released, and cannot skip a state. The clinician can send a draft back, and the send-back is recorded with a reason. We sized the system around clinician hours as the throughput ceiling, because in a product like this, that is what the ceiling is.
Region-resident data. Region is a property of the customer from day one. Personal data never crosses a region boundary, and nothing joins personal data across regions. Expanding to a second country means standing up a parallel data plane, not untangling a global one.
The model is a guest, not a tenant. The language model sits behind a swappable provider interface, and every payload is minimized before it leaves: coarse demographics, questionnaire categories, and abundance data under an opaque one-time ID. No names, no contact details, no sample identifiers. If a regulator or a partner ever requires in-region inference, swapping providers is configuration, not a rewrite.
Sequencing results process asynchronously. One lab delivery becomes one pipeline run, executed as a batch job with per-stage checkpoints. Each run records the versions of everything it used, which turns results into reproducible artifacts instead of one-off outputs.
Drafting changes pass evals first. An evals workspace replays the drafting step against fixed inputs, so a prompt or model change shows its effect before it gets near the release path.
Outcome
Orvana is in testing and has not launched, so the honest outcome list is short. On 23 September 2026 the staging environment passed an end-to-end human test: customer sign-in, checkout against a payment sandbox, the questionnaire, and ops access, run by people rather than scripts. Synthetic lab data has travelled the full path from intake to a signed, released report. There are no user numbers because there are no users yet.
What I can already say is the part I care about: nothing a customer will ever read goes out unsigned, and any report we release can be reproduced exactly. That is the property the engine was designed around, and it held up under test.
Every batch, one audit trail
