Short answer
Software is good at keeping a launch's records true: where evidence came from, which decisions depend on it, what was decided and when, and whose approval a change needs. Reading the evidence, and deciding what to do about it, stays with the team.
The question nobody could answer
Halcyon Medical is a composite company, assembled from patterns across early device launches. It is a worked example, not a customer case.
In September, Halcyon’s launch lead Priya Nair asked a simple question in a launch review: why did we ever believe procurement sign-off takes under 90 days?
Nobody could answer. The number was in the launch plan, the board deck, and the rep training material, and each copy said something slightly different. The basis, a set of reference-account conversations from the spring, existed in a departed consultant’s spreadsheet. When two site visits contradicted the number in August, the team spent a week reconstructing what it had originally believed, from whom, and why, before it could begin deciding what to change.
The problem was not effort or intelligence. The launch had a project tracker, a CRM, a shared drive, and a messaging channel, all actively used. What it did not have was a record of what the team had decided, on what evidence, with what depending on it. Device teams already keep design history files so that every design decision can be traced to its basis, a requirement the FDA carried from the old Quality System Regulation into the Quality Management System Regulation that took effect in February 2026. Launch decisions have no equivalent record. That is the gap a launch truth system has to fill, and it divides cleanly into what software should do and what it should never do.
What software should do
Four jobs. All four are record-keeping, and record-keeping is what software is for.
Preserve evidence lineage. Every material claim in the plan links to its source: the visit note, the payer bulletin, the committee agenda, the conversation, with a date and an author. When someone asks why the team believed 90 days, the answer is a lookup, not an excavation.
Show dependencies. An assumption does not sit alone. It is wired to milestones, forecasts, hiring plans, contracts, and the board deck. The system should answer, for any assumption, what touches it: if this moves, what else moves.
Version decisions. What was decided, when, by whom, on what basis, and what it replaced. Not a changelog for documents: a changelog for judgments. The plan the team is running today and the plan it was running in June should both be retrievable, with the reason for the difference attached.
Route approvals. When evidence contradicts an assumption, the proposed change should reach the person whose call it is, with the basis attached, and wait. Nothing about the plan updates itself. The system’s job is to make the decision easy to make well, and impossible to make by accident.
What software should never decide
The same four jobs have a shadow side. Each has a version that sounds like a feature and behaves like a liability.
It should never judge whether evidence is credible. Two site visits against three spring reference accounts is a weighting problem, and the weighting depends on context the system does not have: which sites, which observers, what incentives. Software can lay the evidence side by side. The weighting is the team’s.
It should never reopen a decision on its own. A system that flags a contradiction is useful. A system that treats the flag as the decision has just made the least accountable member of the team, the software, the most powerful. Flags propose. People dispose.
It should never accept risk on the team’s behalf. Holding the October 1 date despite the 120-day evidence is sometimes the right call. But it has to be a call: made by a named person, recorded, with the reason attached. Risk accepted by silence is not accepted risk. It is unexamined risk.
It should never speak for the team. Drafting the revised forecast, the board note, the question list for Thursday’s site call: all good uses. Sending them is not. Anything that leaves the building with the company’s name on it passes through a person who owns it.
The division of labor
| Software owns | The team owns |
|---|---|
| Keeping every claim linked to its source and date | Deciding whether a source is credible |
| Showing what an assumption touches | Deciding what a contradiction means |
| Recording what was decided, when, and why | Making the decision |
| Routing the proposed change to the right approver | Approving, editing, or rejecting it |
| Drafting the update | Sending it |
The line is consistent: software owns the record, people own the judgment. Trouble starts when either side crosses it, when records live in people’s heads, or when judgments get delegated to the tool that holds the records.
What to ask of any tool, including ours
Most teams run pieces of this today. The tracker holds milestones. The CRM holds accounts. The drive holds documents. The messaging channel holds the running commentary. The gap is rarely a missing system. It is that these systems store artifacts and not the links between them, so the assumption, its evidence, and its dependents live in three places that have never met.
Five questions separate a truth system from another place to store files:
- Show me a claim in the plan. Can I see what evidence it rests on, and when that evidence was last checked?
- If that evidence changed this morning, what would the system show me tonight?
- Can I see the decision as it stood in June, and the reason it changed?
- When a change needs approval, does the approver see the basis, or just the request?
- What does the system do on its own, and where exactly does it stop?
Ask us the same five. A vendor that answers question five quickly is telling you the truth about the rest.
What this does not prove
The Halcyon scenario is a composite, and composites cannot prove that a truth system changes launch outcomes. The honest claim is narrower: the cost of not having the record is paid in reconstruction weeks, in decisions made by accident, and in risk accepted by silence, and those costs are visible in any launch that has been through one contradicted assumption.
It also does not follow that more recording is always better. A system that demands documentation the team will not maintain becomes another stale artifact. The record has to be cheap enough to keep that keeping it is not itself a launch risk.
Sources
- U.S. Food and Drug Administration, Quality Management System Regulation, 21 CFR Part 820, effective February 2, 2026
- RevWorx Insights, “The Half-Life of a Launch Assumption” — the assumption register — /insights/launch-assumption-half-life
Frequently asked questions
- Is this not what our project tracker already does?
- Trackers record activity: tasks, owners, dates. They do not record what the plan assumes, what evidence those assumptions rest on, or which decisions a changed assumption should reopen. A task can be complete and the plan can still be wrong. Both records matter. They are not the same record.
- We are a six-person team. Is this overkill?
- The smaller the team, the less slack there is for a reconstruction week. The record scales down: eight assumptions, the decisions linked to them, and a weekly review. The version that is overkill is the enterprise rollout with a steering committee.
- Does software never get to say "this launch is off track"?
- It can and should say that the evidence for a named assumption has moved, and list what that movement touches. That is a report. The line it does not cross is concluding what the team should do about it, or acting on the conclusion itself.
- What about AI drafting?
- Drafting is one of the best uses, as long as the draft carries its lineage: the evidence it drew on, the decision it proposes, and a human approver before anything changes or ships. A draft without lineage is just a faster way to lose track of why you believed something.