Introduction
I have a protocol in active use right now. Writing it made the problem I am about to describe more concrete than it has ever been for me.
It is also a document. And documents are interpreted.
When a site coordinator reads an eligibility criterion that requires a baseline HbA1c between 7.5% and 10.0%, measured within 90 days of screening, that criterion exists as text. The coordinator interprets it, applies it, and records the result. Two coordinators at two sites may apply it differently. The EDC system that captures the data may not enforce it at all, recording whatever value is entered without checking whether the criterion is satisfied. The deviation that results from that inconsistency may not be discovered until the data management team begins cleaning the dataset, weeks or months after the affected participant was enrolled.
This is not an edge case. It is the standard execution model for most clinical trials, and it is the structural problem that Behavior-Driven Development addresses at the platform level.
The Translation Gap
The gap between a protocol and its execution is not a gap between what the sponsor intends and what sites do. It is a gap between a scientific specification expressed in natural language and the operational systems that are supposed to implement it.
Natural language is ambiguous by design. It accommodates nuance, context, and the kind of clinical judgment that cannot be fully specified in advance. A protocol that attempted to eliminate all natural language ambiguity would be unreadable and would fail to anticipate the judgment calls that clinical practice requires. The protocol is written to be understood by clinicians, reviewed by regulators, and interpreted by experienced professionals.
Software does not interpret. Software executes. When a clinical data platform receives an eligibility entry, it either enforces the criterion or it does not. If the eligibility logic has not been explicitly encoded in the platform, the system records what it receives without evaluating whether what it received is correct. The enforcement obligation falls back to the site coordinator, then to the monitor, then to the data manager, then to the statistician preparing the analysis population. At each step, the deviation that was not caught at data entry becomes harder to resolve cleanly.
The translation gap is the distance between the protocol as written and the protocol as executed. In a standard EDC-based trial, that gap is bridged by people: coordinators, monitors, data managers, and clinical operations staff who collectively implement the protocol's intent through training, SOPs, oversight, and post-hoc correction. This works until it does not, and when it does not, the consequences fall on the dataset.
What BDD Actually Is
Behavior-Driven Development is a software engineering methodology that originated in the agile development community as an evolution of test-driven development. Its core principle is that the behavior of a system should be specified in a structured, human-readable format before any code is written, and that those specifications should function simultaneously as documentation, as communication between stakeholders, and as executable tests.
The specification format is a structured natural language called Gherkin, organized around three components: Given, When, and Then. Given describes the preconditions or context. When describes the event or action. Then describes the expected outcome or system behavior.
Applied to software in general, a BDD specification might describe how a user login behaves when valid credentials are entered, or how an error state is handled when a required field is empty. The specification is written before the code that implements it, reviewed by all stakeholders including non-technical ones, and then automated so that the system can verify its own behavior against the specification continuously.
What makes BDD particularly well-suited to clinical trial platform development is not the Given-When-Then syntax. It is the underlying principle: that the behavior of the system should be expressed in terms that the domain expert, the software engineer, and the compliance reviewer can all read, understand, and verify. In clinical trials, the domain expert is the protocol author. The compliance reviewer is the regulatory affairs professional. The software engineer is the platform developer. BDD creates a single artifact that all three can own.
What BDD Specifications Look Like When Applied to a Clinical Protocol
Consider the eligibility criterion described in the introduction: a baseline HbA1c between 7.5% and 10.0%, measured within 90 days of screening.
In a standard EDC implementation, this criterion might be documented in the data management plan, referenced in the site training materials, and noted in the monitoring guidance. The EDC form captures the HbA1c value and the date of the measurement. Whether those values satisfy the criterion is evaluated by the coordinator entering the data, not by the system receiving it.
In a BDD-based clinical data platform, that criterion becomes an executable specification:
Given a participant is at the screening visit
When a baseline HbA1c value is entered
Then the value must be between 7.5% and 10.0%
And the measurement date must be within 90 days of the screening date
And if either condition is not satisfied, the participant must not be permitted to proceed to randomization
This specification is not a comment in a database schema. It is not a validation rule buried in a configuration file that only a developer can read. It is a human-readable statement of what the system will enforce, expressed in language that the medical monitor, the regulatory affairs team, and the site coordinator can all read and confirm is consistent with the protocol's intent. And it is executed every time a relevant data entry occurs.
The same approach applies to visit scheduling logic, endpoint capture conditions, branching workflows triggered by laboratory results, adverse event severity escalations, and any other protocol-defined behavior that the platform must implement. Each becomes a specification. Each specification is reviewable by non-technical stakeholders. Each is enforced by the platform at the point of data entry.
BDD Specifications as the Shared Contract
The phrase "living documentation" describes something specific in BDD practice. A BDD specification suite is not static documentation that describes what the system was designed to do. It is a continuously executed set of tests that verify what the system currently does. If the system's behavior diverges from the specification, the divergence is detected automatically. The specification and the system behavior are always in sync, because any divergence fails the test.
In a clinical trial context, this property has a direct regulatory implication. FDA's 21 CFR Part 11 requires that electronic records be accurate, reliable, and consistent with their intended use. ICH E6 requires that clinical trial data be complete, consistent, and accurate. An audit trail that shows the platform's behavior matches the protocol's specifications at every enforcement point is stronger audit evidence than a system description document written at configuration and never tested against the running system.
When an FDA inspector asks how the sponsor can demonstrate that the platform enforced the eligibility criteria as specified in the protocol, the answer in a BDD-based system is direct: here is the specification that defines the enforcement logic, expressed in terms that map to the protocol's language; here are the test results showing that the running system satisfies those specifications; here is the audit trail showing that those specifications were in place from the first participant enrolled. The specification is the shared contract between the protocol, the platform, and the regulatory submission.
This matters most when the protocol changes. Protocol amendments are a routine part of trial execution. When an amendment modifies an eligibility criterion, changes a visit schedule, or adds an endpoint, the BDD specification for the affected behavior must be updated before the platform behavior changes. That update is reviewable by the same non-technical stakeholders who reviewed the original specification. The change is documented, the new specification is reviewed and approved, and the platform's behavior is updated to match. The audit trail captures not just what the system does now but what it did before the amendment and exactly when the change was made.
What This Changes Operationally
The operational consequence of a BDD-based platform is not primarily a quality assurance story, though it is that. It is a prevention story.
Eligibility deviations that originate from inconsistent site-level interpretation of protocol criteria do not occur in a system that enforces those criteria programmatically at the point of data entry. They cannot occur, because the system will not allow a participant who does not satisfy the criteria to proceed through the enrollment workflow. The deviation is prevented at the source rather than detected downstream.
Visit scheduling errors that occur when site coordinators apply incorrect windows to protocol-defined visit timing are eliminated when the visit schedule is encoded as a BDD specification and the platform enforces the window at the point of scheduling. The site does not need to interpret the window. The platform applies it.
Endpoint capture inconsistencies that arise when different sites apply different operational definitions to a common endpoint are reduced when the endpoint's capture logic is specified as an executable behavior and enforced by the platform across all sites simultaneously.
This is what Alethium means by protocol-to-platform execution. The protocol is not a document that sites interpret and platforms record. The protocol's scientific intent is translated into BDD specifications that the platform enforces, at every relevant data entry point, across every site, from the first participant enrolled to the last visit completed. The dataset that results from that execution is a record of what the trial actually did, not what the trial was supposed to do according to a document that was interpreted differently across twelve sites.
Conclusion
The most common sources of clinical trial execution failure are not failures of scientific design. They are failures of translation: the gap between what the protocol specifies and what the platform enforces. BDD addresses that gap at the architectural level, by making the protocol's operational logic the foundation of the platform's behavior rather than a document the platform is supposed to reflect.
The result is not merely cleaner data. It is a study that can demonstrate, at any point in the trial lifecycle, that its platform's behavior corresponds to its protocol's intent. In a regulatory environment where data integrity is examined at the system level, not just the record level, that correspondence is the infrastructure on which the evidentiary case is built.
