Engineering evidence
Two production products with patients on the other end. This is the page to read if you want to know whether we can build the thing, rather than describe it.
Both are here as proof of engineering practice. They run their own sites and their own roadmaps.
Being straight about it
Our published case studies are automation and language-processing work from 2018 onward. Our current-generation model work is in our own products. So this page carries the evidence for anything we say about AI.
We would rather be explicit about that than let a reader assume a client engagement behind every capability claim. If a named enterprise AI reference is a hard requirement for you, say so early and we will tell you honestly where we stand.
Product one
A patient-facing tool that finds prescription medications compatible with a person’s excipient allergies, by matching their sensitivities against public drug labeling data. It turns a manual ingredient-list review into a straight answer.
The engineering problem is data integration and normalization at scale. Authoritative labeling data is public, but it is structured for regulators rather than for a patient trying to find out whether a specific generic contains a specific dye. Reconciling excipient nomenclature against manufacturer labeling across thousands of formulations is the hard part, and it is the same class of problem as reconciling payor policy language against a claim.
Visit Drug Search ↗Product two
A production application built on a commercial large language model API, with a de-identification pipeline in front of it. It is our only current-generation model system with clinical data behind it, which makes it the load-bearing evidence for the way we handle AI and patient data.
BookCover runs its own site and its own marketing. It is here as proof of what we can build.
De-identification that preserves meaning
Clinical text can be stripped of identifiers before it reaches a model without losing the clinical sense the model needs. Getting that balance wrong in either direction is the usual failure.
The mapping stays inside the boundary
Re-identification happens on our side of the line, never the model provider’s. That is the design decision a security reviewer actually cares about.
Logging and evaluation built in
Request logging and output evaluation were part of the first version rather than bolted on after someone asked for an audit trail.
Built for ourselves first
Every capability below is something we built for ourselves first and now implement for clients. That is the whole argument of this page.
Questions we get
Can we buy these products?
No. Both are patient-facing products with their own sites and their own roadmaps. They are here as engineering evidence of what we can build for clients.
Why does it matter that you build your own?
It is the difference between having implemented a pattern and having operated one. Every hard decision in a production model system: what to do when the model is uncertain, how to de-identify without destroying clinical meaning, what to log. We have had to make for real, with users on the other end.
What is the actual stack?
A commercial language model API under enterprise terms, a custom de-identification pipeline in front of it, authoritative public data sources, and evaluation harnesses rather than hand-tuning. Orchestration is our own code, kept deliberately debuggable. We will name every component in a security review.
Does this mean every engagement uses AI?
No, and most do not. Plenty of the work that delivers the largest return is rules-based automation with no model anywhere near it. Where AI fits is a narrower question than the market suggests.
Next step
If you have an engineering or security question these pages do not answer, bring it to the teardown. We would rather have that conversation early than discover the gap at contract stage.
Book a teardown