The board does not need to determine whether an AI system is technically safe. It should require management to prove how consequential AI is governed.
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.
Here is the plain version: your job is not to become an AI expert. It is to require management to show, with evidence rather than a policy binder, where AI touches a consequential decision, who stays accountable for it, and whether the safeguards are actually still working.
A short reader path into Building Darwin, the full CEO Letter.
What changes for the board
AI creates a gap between policies that describe intended behavior and evidence of what actually happened in a specific decision. The board should expect management to close that gap for consequential uses.
Five questions directors should ask
- Which consequential decisions involve AI or agents?
- Who remains accountable for each?
- What technical constraints enforce that authority?
- How do we know those controls continue to work?
- Can management produce the contemporaneous record later without reconstructing it?
Why the architecture matters
Darwin is designed so the governed record is the product. Model identity, policy, governance, security controls, verification and evidence are part of the operating architecture rather than a post-hoc compliance package.
The standard worth asking any vendor to meet
When your board is asked to sign off on adopting AI in a consequential decision, the usual evidence offered is a policy document describing intended oversight, not proof that oversight actually holds together across the standards, legal, security, clinical, and technical teams responsible for it. Fragmented ownership among those teams is normal, but it also means no single function is positioned to catch a control that looked sound on paper and stopped working in production. This architecture keeps requirements, technical controls, verification, and evidence in one accountable chain instead of several disconnected ones, which is the standard worth asking any AI vendor to meet.
Why Sherri and the Medigram team
That kind of chain is unusual enough to name directly. Sherri Douville co-founded and chairs the Trustworthy Technology & Innovation Consortium (TTIC), built to convene the leaders across the functions required to build, deploy, integrate, implement, and maintain healthcare AI and technology (CIOs, CISOs, physicians, engineers, lawyers, executives) because, as TTIC’s own founding account puts it, “each perspective is necessary. None is sufficient on its own.” Medicine only trusts that kind of claim when it’s accredited: when who was in the room, how disagreements were settled, and who could object are all a matter of record, not assertion.
That’s the standard worth holding any AI vendor to, not whether one person at the company is personally capable, but whether the vendor operates with that same discipline: an accountable chain that survives contact with disagreement, evidenced rather than asserted. Sherri holding the actual standards seats behind that discipline (IEEE/UL 2933, ANSI/HSI 2800) and personally authoring Darwin’s implementation record is what that discipline looks like applied inside one company, not a substitute for your board asking whether it’s becoming Medigram’s institutional practice rather than one person’s habit.
What good oversight looks like
A strong board signal is not a larger AI policy binder. It is management’s ability to show traceable authority, active monitoring, named findings, remediation, regression testing and evidence supporting what the system did and why.
Need the full architecture and evidence?
The CEO Letter contains the detailed technical rationale, verification loop, standards context and diligence path.