Trust
How this can't make things up
The whole point of this tool is that it cannot invent a medical fact. That is a property of how it is built, not a promise we ask you to take on faith. Here is the mechanism.
The clinical logic is data, not generation
Every recommendation and every nutrition number lives in a curated evidence bank, each entry tied to a named source with a verbatim quote and a link. The medicine is data you can read, not text a model wrote.
A plain engine assembles the plan
A deterministic rules engine reads the patient and the bank and puts the plan together. There is no language model anywhere in the path that produces a fact, a number, or a food instruction.
Un-cited data fails the build
An automated gate checks every rule and recipe against the schema and confirms each citation resolves. If any entry lacks a source, the build fails and it never ships. Missing a citation is a broken build, not a small risk.
A named clinician has signed off every rule (24 of 24)
A rule does not serve advice until a clinician reviews its verbatim sources and signs off, dated and by name. Right now every rule in the bank carries that sign-off. New rules ship flagged as pending until the review is done, and you can see the queue on the sign-off page.
Same patient, same plan, every time
Because it is deterministic, the same inputs always produce the same output. You can check it, and it will not drift between runs.
It says nothing rather than guessing
When a case falls outside what the bank covers, the tool refuses and routes to a clinician instead of filling the gap. Knowing when not to answer is part of the design.
This button generates Eleanor's full plan 25 times in your browser, right here, and fingerprints each result with SHA-256. Deterministic means every fingerprint is identical. A generative model could not pass this test.
Where this sits with the FDA's CDS framework
Federal law carves non-device clinical decision support around one idea: the clinician must be able to check the software's work. Section 520(o)(1)(E) of the FD&C Act covers software functions:
“enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”
That is this tool's design, literally: every recommendation displays its named source, a verbatim quote, and a link, so the basis is independently reviewable on the spot. Regulatory classification is a determination for the institution's compliance team; this describes design intent, not a cleared or classified status.