A clinical trial can spend years getting everything right and still create a serious incident in a few seconds, when a data package goes to the wrong recipient. It’s the kind of mistake nobody plans for and everybody quietly worries about, and it’s exactly what Sai Krishna Puli set out to make impossible with a new data architecture. Instead of relying on people to catch the error before it happens, his design makes it something the system itself refuses to allow.
The Problem: Too Many Hands, Too Little Structure
Clinical trial data passes through a long chain before it reaches anyone outside the organization that generated it. A sponsor’s protocol splits into sub-protocols, sub-protocols branch into projects, projects span investigators and sites, and every patient generates a steady stream of samples and results. At some point, someone has to package a slice of that data and send it to the right place, a lab, a regulator, a safety committee, or the sponsor itself.
Today, that “right place” is usually just a field on a form. Someone types in or selects a recipient, a colleague glances it over, and it goes out the door. It works most of the time. But when it doesn’t, the fallout is real: exposed patient information, a broken confidentiality agreement, a regulatory report nobody wanted to file, and a relationship between sponsor and vendor that’s hard to repair.
Sai Krishna’s diagnosis is that this isn’t really a training problem, it’s a design problem. Recipient identity is treated like any other editable field instead of something tied firmly to the protocol that authorized it. Systems describe “correct delivery” in a policy document instead of enforcing it in code. And whether a given step fails safely or fails open often isn’t even documented, let alone tested.
The Fix: Recipients as a Governed Relationship, Not a Text Field
Here’s the basic idea: stop letting one field decide both what data belongs to and who gets to receive it. Split those into two separate questions, and make sure neither one can be quietly edited on the fly.
- Data gets a fixed identity. Sponsor, protocol, patient, sample, each one carries a permanent ID with one clear path back to where it came from, so a look-alike name or a typo can’t quietly reroute anything.
- A recipient has to earn its spot, not just be typed in. Before any lab, regulator, or committee can receive data, two different people have to independently approve them for that specific protocol, and that approval is tied to a real certificate, not just a name in a dropdown. Puli calls this approved relationship a “RecipientBinding,” and any change to it, a new certificate, a wider scope, requires a fresh, independently re-approved version rather than a quiet edit.
- No one person can send data alone. Assembling a delivery and approving its release fall to different people, the same way changes to a recipient’s authorization need two sets of eyes.
- Every delivery has to pass four checks at once, right recipient, right data, right scope, right format. Miss any one, and the system holds the delivery instead of guessing.
- Everything is signed and logged. Each delivery’s contents are hashed and recorded on an immutable ledger before it ever leaves, and the recipient checks that hash again on arrival.
The whole thing runs on a simple principle: if the system can’t prove a delivery is correct, it doesn’t send it. A delayed shipment is annoying. A wrong one is a regulatory incident. That trade-off is deliberate.
Fail-closed pipeline
Testing It Honestly
Rather than lead with a big accuracy number, the architecture is built to be evaluated on things that actually matter in practice: does it ever let a bad delivery through, how fast does it catch a problem when one occurs, how often does it block something that was actually fine, does it hold up as trial volume grows, and does it fail safely when something upstream breaks. The plan for testing it combines formal verification, deliberately breaking the system to see how it responds, and outside reviewers actively trying to find a way around it.
Where It Can Still Break
No system is only as strong as its weakest layer, it’s as strong as what those layers secretly share. If the same identity provider hands out both “maker” and “checker” credentials, one breach undoes the whole point of having two approvers. If the routing logic and the verification check share a buggy library, they can fail the same way at the same time. If a certificate authority and the audit ledger both lean on one directory service, an outage there stops looking like one problem and starts looking like several at once. Puli’s answer is consistent: find the shared dependency and split it in two, so one failure alone is never enough.
Built With Regulation in Mind
The design isn’t detached from the rules trials already operate under, even though building it doesn’t hand an organization a compliance certificate on its own. The audit ledger and dual sign-off support what FDA 21 CFR Part 11 expects from electronic records. Tracing every piece of data back to its source supports the kind of traceability ICH E6(R2) calls for. The scope checks on every delivery align with HIPAA’s minimum-necessary standard and GDPR’s purpose-limitation rules. Whether a specific implementation actually satisfies these requirements is still something an organization’s regulatory and legal teams have to evaluate, the architecture makes that case easier to build, not automatic.
Room for Machine Learning at the Edges
The core decision, send or hold, is meant to stay black-and-white on purpose; a delivery gate that can’t be argued with shouldn’t run on probability. But the space around it is a good fit for machine learning. A model watching binding activity over time could flag a recipient’s configuration drifting from its own normal pattern before it ever becomes a real failure. Telling apart “this dependency is actually down” from “this dependency is just slow” is a solvable prediction problem, and solving it well would mean fewer legitimate deliveries getting held for no good reason. Even the testing process itself, running failure after failure through the system, produces exactly the kind of labeled data a model could learn from.
What Comes Next
Two things would move this from design to something teams can actually run: formally verifying the proof with tools built for that purpose, and testing the real implementation against deliberately induced failures. Longer term, there’s an opportunity to extend the audit ledger across organizations, sponsor, vendor, and recipient sharing one trustworthy record instead of three separate ones, and to map the whole thing onto standards like CDISC and HL7 FHIR so it can slot into systems that already exist, rather than replacing them.
Sai Krishna Puli’s architecture doesn’t promise that wrong deliveries become impossible. What it promises is more specific and, frankly, more useful: a system that won’t send anything it can’t prove is correct. That’s a meaningfully different standard than “someone checked it,” and it’s one clinical trial data delivery has needed for a long time.
