What Branching Clinical Simulation Actually Means

Branching clinical simulation means a patient world can commit a decision, move its own clock, fork into more than one future, and keep every fork for comparison and replay. It is a way to explore a specified setup under controlled uncertainty. It is not a prediction of what will happen to a real person, and it is not advice about what a clinician should do.

The phrase is easy to cheapen. Any chatbot can say "what if we had chosen differently" and write a second ending. That is branching as a literary device. The second ending does not share a stored past with the first. It does not name the moment of divergence. It cannot be replayed, because nothing was recorded except the prose. When the next session asks for the same fork, the model writes another ending, and the two "what ifs" do not have to agree.

Patientic is being built so that a branch is a state operation, not a style of answer. A fork starts from a committed point in a persistent patient. Both resulting histories remain. Replay reads the stored events. Comparison places two branches against the state they share. This essay names those operations and the limit that keeps them inside simulation.

A decision is a commit

In this design, a decision is not the moment a model finishes a paragraph. A decision is a commit: an accepted action written into the history of a branch. Before the commit, the action is a proposal. It can be rejected by policy. It can be revised. It does not yet move the patient world. After the commit, later states on that branch may depend on it, and the event is part of what replay will see.

The commit is what makes time meaningful. If every sentence advanced the case, then hedging, asking a question, and choosing would all be the same kind of event. They are not. Asking can disclose a fact without choosing a direction. Hedging can leave the state unchanged. Choosing, once accepted, is the event that a fork can later split from. The system design keeps those classes apart so a reviewer can see which one happened.

Time belongs to the simulation

Clinical language is full of sequence. A fact gathered early is not the same object as a fact gathered after a commitment, even when the words look similar. Simulation has to own that sequence with a clock, not with the timestamps of HTTP requests. Request time records when a computer was contacted. Simulation time records where the patient world is.

Advancing time is itself an action. It can be tied to a commit, or it can be an explicit step that says the world is now later and some disclosed facts may have changed under the scenario's rules. The important property is that time does not drift because a model wrote "the next morning" in a narrative. Narrative can describe the clock. It does not set it. If description and clock disagree, the clock is the state and the description is a rendering that failed to match.

Forks inherit time. Two branches that split at the same committed moment start from the same clock reading and then may advance differently. A comparison that ignores that reading will treat a later state and an earlier state as if they were alternatives, when one of them is simply downstream. Branching is not a pile of endings. It is a tree with timestamps on the nodes.

A fork keeps the shared past

A fork copies the past it needs and then accepts a different next action. The parent state remains addressable. Branch A does not erase branch B. Rewind, in this design, is non-destructive: you can look at an earlier point and start another branch from it without deleting the branch you left. Merge is not part of the model. Two futures do not collapse back into one official history, because the point of the fork was to keep both.

If branch A and branch B cannot both exist, you have thrown away the comparison you forked to create. The persistent patient described in What Is a Persistent Virtual Patient? is what makes the shared past real. Without durable state, a fork is a metaphor.

Controlled uncertainty sits inside the same structure. A scenario can withhold a fact, or resolve a chance event under a seed, without turning the whole run into a new patient. The uncertainty is a property of the world at a time. When it resolves, the resolution is an event on that branch. A different branch can resolve it differently, or not yet, because it has not reached the action that would disclose it. Uncertainty that is re-rolled silently on every message is not controlled. It is just noise, and nobody can replay it.

Comparison needs a named split

Comparison is the reason to branch. It is also the first thing informal "what if" conversations fail at. To compare two futures you need three references: the shared state at the split, the event sequence on the first branch after the split, and the event sequence on the second. If any of the three is only a paragraph, the comparison is a reading of two essays. Essays can be interesting. They are not a diff.

A useful comparison stays inside the simulation that produced it. It can say that, under this patient, this scenario, and these commits, branch A disclosed a fact before acting and branch B committed first. It cannot say that branch A is what a hospital should have done, or that branch B predicts a real outcome. The moment the sentence leaves the specified setup, it has stopped being a description of the branch and started being a clinical claim. This system is not for that claim.

Replay is how you check the comparison later. Replay walks the stored events of a branch and shows the same commits, the same disclosures, and the same clock. It does not ask a model to reminisce. If a replay disagrees with the original branch, the run was not actually recorded, or something outside the receipt changed. Receipts, and why they have to name the seeds and versions involved, are the subject of Why Every AI Patient Run Needs a Simulation Receipt.

time -->
state S0
  |
  commit C1
  |
state S1 ---------- fork
  |                  |
  branch A           branch B
  commit C2a         commit C2b
  |                  |
  state S2a          state S2b
  |                  |
  replay(A)          compare(S2a, S2b) against S1

The fork is a point, not a mood. Everything above S1 is shared. Everything below it is a separate history. Replay stays on one side. Comparison names both sides and the split.

What the branch is allowed to mean

Inside a branch, an actor — a person or an agent — can gather what the world will disclose, propose a commit, and see the state that follows under the scenario. Across branches, a reviewer can see what changed when the commit changed. That is a lot. It is also a narrow lot. It does not include a probability that a real patient will follow branch A. It does not include a recommendation. It does not include a score that says one branch was medically correct.

The uncertainty in the simulation is controlled so that exploration is repeatable, not so that it imitates the full uncertainty of a life. Seeds, which the receipt has to record, make a chance event the same event when the run is repeated. They do not make the event true outside the scenario. If a later use of this kind of system ever needed a stronger claim, that would be a different validation problem, with a different evidence bar, and it is not what the current design is asserting.

The practical test of a branching simulation is mundane. Can you point to the commit? Can you point to the clock? Can you open both forks tomorrow and still see the same split? If the answer is no, you have a story with optional endings. If the answer is yes, you have a simulation you can inspect. Patientic is being built toward the second thing, on a persistent patient world meant for synthetic, educational, or otherwise permitted scenarios.

Related reading

• What Is a Persistent Virtual Patient?
• Synthetic Patient Simulation: What It Is—and What It Is Not