The Constitution Before the Code
PDI Med — Post 3 of an ongoing series
Before I wrote a single line of code, I wrote a list of things the system could never do.
Not things it shouldn’t do. Not things it promised not to do. Things it would be structurally incapable of doing — by design, by architecture, by the kind of constraint that doesn’t bend under pressure or convenience or a well-intentioned engineer at two in the morning who just needs the logging to work.
This distinction — between a promise and an architecture — is the most important idea in PDI Med. Everything else is downstream of it.
My grandfather died when I was young. I never knew him the way I would have wanted to.
What I have instead is the house he designed — the one I grew up in. I notice his handiwork everywhere in it. The way the light moves through certain rooms at certain times of day. The decisions that only make sense if you understand what he was trying to protect against. The structural choices that were never meant to be seen, and aren’t, but hold everything else up.
Architecture outlasts the architect. That’s the thing about building something for load rather than for appearance — it keeps doing its work long after the person who designed it is gone. I think about that more than I can explain.
I think about it constantly when I think about what medicine’s AI infrastructure is quietly becoming.
Most healthcare AI platforms are built with good intentions. I believe that about almost all of them. The engineers who built them did not sit down and decide to surveil physicians. They decided to add crash reporting because crashes are bad to miss. They added telemetry because it helps with debugging. They added analytics because investors want growth metrics. They accepted the logging library because it was standard and familiar and the sprint was ending.
Each of those decisions was locally reasonable. The aggregate of those decisions is a platform that knows, in granular detail, how every physician using it practices medicine.
That’s not paranoia. That’s the second-order effect of default software behavior applied to clinical data. And once the capability exists — once the infrastructure can see — it can be asked to report. By a payer. By a hospital administrator. By a legal team responding to a subpoena. By an acquirer who has different priorities than the founders did.
The failure mode isn’t malice. It’s architecture without constraint.
This is the distinction I want to spend this whole post on, because it’s the one I think medicine is getting wrong, and it’s the one PDI Med is built around.
Governance is a rulebook for how a tool is used. Constraint is how a tool is built.
Governance is relaxable. It can be revised, waived, reinterpreted, or quietly ignored under enough incentive pressure. It depends on the continued good behavior of whoever holds the rulebook — and on that person’s successors, and their acquirers, and the legal environment they operate in a decade from now. Governance is a promise.
Constraint is structural. It makes the wrong thing impossible rather than prohibited. It doesn’t depend on anyone’s restraint, because the capability to do the wrong thing was never built.
The difference is the difference between these two sentences:
“We promise not to use your data.”
“We built it so we can’t reach your data.”
The first is governance. It is exactly as durable as the incentives of the company making the promise. The second is constraint. It is true regardless of incentive, ownership, or pressure — because it’s a fact about the architecture, not a statement of intent.
A system that can be gamed will be gamed. So the protection has to live in the construction, not in the policy.
Here is the problem stated in Munger’s terms, because it’s the clearest frame I know:
Assume that human beings will do what is easy, socially rewarded, and incentive-aligned. Design so that the easiest path is the safe path, the unsafe path is hard, and violations are obvious and costly.
Most clinical software does the opposite. The easiest path is to add the analytics SDK, enable the logging, accept the default telemetry. The safe path — building a system that is genuinely incapable of exposing physician behavior — requires deliberate, sustained, and often inconvenient architectural choices.
So I started from the other direction.
Before I wrote a parser, I wrote a constraint clause. A list of non-negotiable architectural invariants. Not aspirations — invariants. Things the system cannot do, not things it hopes not to do.
The first invariant is domain separation.
PDI Med operates as two distinct zones that do not blur. The Vault — the local, physician-controlled environment where identified clinical data lives — is one zone. The federated layer, where de-identified intelligence travels, is the other. No feature may soften that boundary for convenience. No “just this once” exception exists in the architecture.
The second is capability denial.
The identified zone has no outbound network by default. Not a restricted outbound network. No outbound network. Attempts to transmit identified data off-device are not warned against — they fail closed, treated as security incidents. This is not a log entry. It is a wall.
The third is irreversibility.
Anything leaving the identified zone must be transformed such that it cannot be re-identified by the platform operator. “We promise not to look” is not an architecture. Structural impossibility of looking is an architecture. If I cannot reconstruct a patient’s identity from what leaves the vault, then neither can anyone who compromises my servers, serves me with a subpoena, or acquires my company.
The fourth is minimal retention.
Raw clinical text is not allowed to persist anywhere unintended — not in logs, not in caches, not in crash reports, not in temporary files. The physician’s note lives in the vault. It does not live in my observability pipeline.
The fifth is verifiable integrity.
Trust should be earned by verifiable properties, not by reputation. Signed builds. Software bills of materials. Automated gates that fail closed when a constraint is violated. Not “we run tests” — proof that the tests ran, what they found, and what was done about it.
These are not features. They are the constitution. And every one of them is a constraint, not a governance policy — each makes a category of harm structurally impossible rather than merely against the rules.
I want to be honest about why this matters more for a system built the way I built PDI Med than for one built by a traditional engineering team.
AI-assisted coding is extraordinarily powerful. I could not have built this system without it. But AI code generation has a specific failure mode that traditional development does not: it suggests standard patterns. Industry defaults. Things that work in other contexts and are socially reinforced by years of developer practice. Analytics SDKs. Verbose logging. Crash reporting libraries. These suggestions are not malicious. They are trained on codebases where those choices are correct.
In a clinical context, they are often catastrophic.
When the code generation tool suggests a debugging library and I accept it without thinking, I have just introduced a data pathway I may not fully understand into a system that touches physician-patient relationships. The code compiles. The tests pass. The pipeline ships. The capability exists.
This is why the constraint clause has to come before the code. Not as a checklist you run afterward. As the architectural foundation that every subsequent decision is evaluated against.
If a feature requires violating a constraint, the answer is not negotiation. It is redesign.
There is a deeper point here that took me longer to articulate.
In medicine, we have a phrase for clinical documentation: if it wasn’t documented, it didn’t happen. The converse is also true in a more troubling way: if it was documented, it can be used. Every note, every order, every result that exists in a structured, queryable form is a potential input into someone else’s decision about a physician’s practice.
The promise that it won’t be used that way is exactly as durable as the incentives of whoever holds it. Which is to say: it is governance, and governance is not enough.
This is Chesterton’s fence applied to data. Before you tear down the fence between physician data and institutional visibility, you need to understand why the fence was built. The fence is there because physicians practice differently when they know they’re being watched. Because clinical reasoning requires the freedom to be uncertain, to document ambiguity, to work through a differential out loud in a note — and that freedom evaporates the moment the note becomes a performance review.
The intelligence I’m trying to build is only as good as the honesty of the inputs. And the honesty of the inputs depends entirely on whether the physician trusts that what they document cannot be turned against them.
Trust is not a product feature. It is a precondition of useful clinical data.
This leads to a test I use to tell the two apart — sovereignty and extraction — because they can look similar from the outside.
The test is directionality. When insight flows back to the person who generated it, that’s sovereignty. When value is pulled away from the person who generated it, that’s extraction. Same data, same intelligence, opposite direction — and the direction is the whole moral difference.
A platform that learns from a physician’s work and returns that learning to the physician, first, is a sovereign system. A platform that learns from a physician’s work and sells the resulting insight back to her — or to her employer, or to a payer who will use it to rank her — is an extraction system wearing the language of partnership.
The bright line I’ve drawn for myself: never charge a physician for insight derived from her own judgment. The moment you do, you’ve inverted the directionality, and no amount of friendly framing changes what the system has become.
The commit event is where this becomes concrete.
When a physician commits an encounter in PDI Med, two things happen that are architectural facts rather than policy statements.
First, the source text becomes fixed. Immutable at the local level. Append-only from that point forward. If something needs to be added later — a pathology result returns, an addendum is required — it gets added as a dated, attributed addendum to the original record. The original does not change. The history does not disappear.
Second, the parsed output is versioned and attributed. When a better parser is released, prior commits are not silently reinterpreted. The prior parse is preserved. The new parse is an upgrade, not a rewrite. The physician can see exactly what changed and why. Silent reinterpretation is poison in a trust-based system.
There is one thing I want to be precise about, because I’ve spent the better part of a year working through it and I’m confident in where I landed.
Participation in PDI Med’s federated intelligence layer is not a separate opt-in. It is a condition of entry. When a physician joins PDI Med, they are joining a physician intelligence network — the same way participation in STS or NSQIP requires data contribution as a condition of membership, not as an optional add-on. The collective intelligence is only as good as the honesty and completeness of what physicians contribute to it. A system where you pick and choose which cases to contribute rebuilds exactly the bias that makes today’s evidence fail the patient in front of you — the network stops reflecting how medicine is actually practiced and starts reflecting only the cases physicians were comfortable being seen.
What remains physician-controlled is the quality gate. The physician decides when an encounter is complete enough to represent their clinical practice in the aggregate. Nothing federated is incomplete by physician standards — that threshold belongs to the physician. But the direction of travel, once you are in, is contribution. The PHI stays home. The de-identified structure travels. That is the bargain, and it is a transparent one.
I am sometimes asked whether all of this constraint makes the system harder to build.
Yes. Meaningfully yes. Every constraint I’ve described creates engineering friction. Building within hard limits is slower than building without them, at least in the short term.
But I keep returning to something I learned in residency about intraoperative decision-making: the surgeon who knows exactly what they will not do under any circumstances makes better real-time decisions than the surgeon who is always negotiating with themselves about exceptions. Constraint is the substrate for clarity. When the fence is built before the code is written, you never have to decide, under pressure, whether this particular feature is the one that gets to cross it.
My grandfather’s house is still standing. The rooms he designed still move light the way he intended. The walls he built for load are invisible — you walk past them every day without knowing they’re what’s holding everything up.
That is what I am trying to build. Not a product that looks trustworthy. A system whose trustworthiness is structural, invisible, and load-bearing.
The constraint clause is the wall. Everything else is what it makes possible to build on top of it.
Dan Bristow, MD Founder, Physician Driven Innovations, LLC (PDI Med) Kansas City, Missouri
Previously: The Library That Isn’t a Library — why the EHR was built for the wrong person.
Next: What it actually means to parse a clinical note — why this is a problem in epistemology as much as engineering.