Continuous integration in pharmaceutical R&D

The eighteen-month problem

A translational lead running a phase II programme inherits a belief, not a fact: the mechanism works, or at least the preclinical and early-phase evidence points that way. That belief was fixed at some moment — the go/no-go meeting, the investment committee memo, the protocol lock. Everything published afterwards about the target, the comparator, the assay, becomes integration debt. In software, debt of that kind surfaces at the next merge. In pharmaceutical R&D it surfaces at the next scheduled review, which might be an interim analysis at month twelve, or might simply be never, because nobody re-opens a settled rationale unless something forces the question.

The failure mode is specific and recurring: a programme runs eighteen months on a result that was withdrawn in month three. The withdrawing preprint, the adverse-event signal in a related compound, the retraction notice buried in a journal's errata section — all of it existed, searchable, from early on. It simply never merged into the programme's working belief set, because nothing was watching the stream after the literature review that justified the original protocol. The cost of that gap is not abstract. It is patient-months, site fees, a regulatory submission built on a foundation nobody re-checked.

Two positions, both defensible

The first position: pharmaceutical evidence should be integrated continuously, the way code is. Trial registries update daily. Adverse-event databases like FAERS and EudraVigilance accept reports on a rolling basis. Preprint servers post revisions and retraction notices in near real time. A translational lead who treats a literature review as a one-off event, done at protocol design and revisited only for the next protocol, is doing milestone integration in a domain that increasingly generates continuous signal. The frozen review diverges from the evidence base at the rate the evidence base moves, and by month eighteen that divergence is not a rounding error.

The second position: medicine has a test suite problem that software never had at this severity. A green build in continuous integration is a real verdict — the code compiles, the tests pass, deterministically, in minutes. There is no equivalent oracle for "does this adverse-event report implicate our mechanism." A single case report is noise until it is three case reports with a plausible pathway; a retraction is sometimes reversed on appeal; a preprint flagged as concerning is sometimes vindicated on peer review months later. Merging every incoming signal into a live belief about programme risk, at the cadence the streams actually produce them, risks manufacturing false stops as readily as it prevents false continuations. A translational lead who reacts to every FAERS blip is not running a tighter ship. They are running a jumpier one, cancelling programmes on noise and calling it vigilance.

Both of these are correct about something real. The disagreement is not about whether continuous intake is possible in this domain — it plainly is, the streams exist and are queryable — but about whether continuous intake without a strong oracle is an improvement over periodic intake with a weak one. That is the actual argument, and it does not resolve by asserting that faster is better.

What the analogy borrows and what it cannot

Continuous integration did not begin with reliable tests. At Chrysler's C3 project in the mid-1990s, the automated build came first; test discipline was forced into existence because merging several times a day made untested merges intolerable in a way that made the pain visible immediately rather than at the end of a quarter. The oracle was built to match the cadence, not the other way round.

The pharmaceutical equivalent of that oracle is not a single green build. It is provenance and corroboration held together: a belief about a compound's safety margin should carry the sources that support it, weighted by independence, so that a fourth observation can be tested against three prior ones rather than absorbed as an isolated alarm. A single spontaneous adverse-event report is weak evidence and should move a belief only slightly, with the update itself recorded — this margin moved by 0.4 sigma on the strength of one unconfirmed report, flagged for re-assessment on the next data pull, not asserted as settled fact. That is a weak oracle. It is not the strong, deterministic oracle software enjoys, and pretending otherwise would be dishonest. But it is not nothing, and it is strictly more than the frozen literature review offers, which has no oracle at all — only the standing presumption that whatever justified the protocol at t=0 remains true indefinitely.

The contamination risk is the correct objection

The second serious objection is about propagation, not accuracy. Trunk-based development couples everything to everything: one bad commit can halt all downstream work, and the fix for that coupling — feature flags, staged rollout, the ability to bisect and revert — took years to mature and still adds real overhead. A programme that integrates every stream continuously risks the equivalent failure: one bad signal, wrongly weighted, propagating into every downstream conclusion the belief set supports. A translational lead does not want a system where a single mis-attributed adverse event auto-cascades into halting three related trials because a shared belief node updated without anyone examining it directly.

This objection is not answerable by denying the risk. It is answerable by the same mechanism software eventually built: quarantine and reversal. If every belief in the maintained set records which stream produced it and how, then a stream that turns out to be corrupted — a retracted preprint whose finding was load-bearing for a mechanism-of-action belief — can be excised, and every conclusion that depended on it can be identified and rebuilt, specifically, rather than the whole programme rationale being discarded or blindly kept. Without that provenance chain, the objection is fatal: continuous merging becomes continuous contamination, exactly as claimed, and a translational lead would be right to resist it. With it, contamination is bounded in the same way linux-next bounds a bad kernel commit — traceable to a specific merge, revertible without unwinding the whole tree.

Where the comparison actually lands

The table does not vindicate continuous intake outright. It shows that the third column is doing real work the first two cannot do simultaneously — early discovery and cheap correction — but only because provenance is present. Strip provenance out and the middle column is, as the objection says, worse than the frozen review on the dimension that matters to a translational lead: false stops that waste a programme as thoroughly as false continuations do.

The narrowed claim

So the resolution is not that continuous intake wins because continuous beats periodic. It is narrower. Continuous intake is only an improvement over periodic intake once it carries provenance sufficient to make correction local — otherwise it trades one failure mode (slow reconciliation of real error) for another (fast reconciliation of noise). For a translational lead, that means the discipline worth adopting is not "watch every stream in real time." It is: maintain a belief set where every claim about mechanism, safety margin and comparator performance cites its sources and their independence, refresh it against the registries and adverse-event feeds on a cadence matched to what those sources can actually support, and make every belief revocable back to the observation that produced it. That is a smaller, harder thing than "go faster," and it is the only version of the argument that survives contact with a domain where the oracle is weak and the cost of a false stop is measured in cancelled trials, not a failed build.