A requirement is not operational until an engineer can implement it and a test can tell whether it worked.
AI is starting to help with decisions about people's health, in hospitals, and in pro sports, where teams use data about players' bodies to decide who plays and when. Darwin by Medigram is the system that checks the AI: it scores every decision on six kinds of trustworthiness and keeps a permanent record, so whether the stakes are a patient's care or a player's career, nothing happens unchecked and there's always proof. Designed to work on mobile, where the work happens.
For engineering, the core problem is the handoff between standards, architecture and verification. Medigram’s approach is to read the requirement closely enough to make it executable, build the control, and design the behavioral test that distinguishes implementation from documentation.
A short reader path into Building Darwin, the full CEO Letter.
Why standards matter technically
TTIC notes that engineering already depends on standards for interoperability and reliability. In clinical AI, the additional requirement is being able to show how the system behaved, who authorized it and what evidence supports the result.
Architecture choices are governance choices
Darwin places its trust boundary before the model, records validation outcomes rather than suppressing evidence, and preserves the record even under stress. Those are engineering decisions with governance consequences.
Why the feedback path stays whole
A requirement that passes through separate standards, architecture, security, and QA teams tends to lose information at each handoff: intent gets restated, edge cases get dropped, and a finding from adversarial testing may never make it back to the people who wrote the original requirement. This architecture is built around a single feedback path instead: requirement → architecture → implementation → adversarial test → finding → remediation → regression → evidence, so a finding anywhere in that chain can change the requirement, not just the code.
Why Sherri and the Medigram team
That loop is closed today because Sherri Douville worked across standards authorship, architecture, AI engineering, and security testing directly, so a finding from adversarial testing could reach the requirement and the architecture without a handoff in between. The work now is encoding that same feedback path into Darwin’s engineering process so it holds regardless of who is doing any given piece of it.
Behavioral verification closes the loop
The CEO Letter describes a specification → adversarial test → finding → remediation → regression → evidence loop. Evidence then re-enters the specification rather than ending as a compliance artifact.
What to require under contract
These specifics are not offered freely. At the vendor evaluation stage, under contract and NDA, require the behavioral remit, model and version controls, boundary placement, test methodology, finding ownership, regression coverage, provenance of decision records, and the mechanism used to verify that evidence has not been altered.
Need the full architecture and evidence?
The CEO Letter contains the detailed technical rationale, verification loop, standards context and diligence path.