Why Every AI Patient Run Needs a Simulation Receipt

A simulation receipt is the record that makes an AI patient run repeatable. It names the patient and scenario, the seeds that controlled randomness, the model and provider versions, the policy and evidence-pack versions, the actor, and the timestamps. Without that record, a run is a story about what seemed to happen. With it, someone else can ask whether a later result is the same experiment.

Reproducibility here is a property of the simulation, not a claim about clinical truth. Two identical receipts should be able to walk the same commits and the same disclosed facts. They still say nothing, by themselves, about what a real clinic should do. The receipt is how you stop a demo from being a one-time performance. Patientic is being built so that a run can carry this kind of record, because a patient world that cannot be repeated cannot be evaluated either.

What "the same run" has to mean

People say a result is the same when the final paragraph looks similar. That is a weak identity. Two paragraphs can match while the agents gathered different facts, hit different policy decisions, or benefited from a hidden fact that was accidentally left in the prompt. Sameness has to be defined on the inputs that the environment actually used.

A receipt draws that boundary in public. It says which patient world was loaded, which scenario rules applied, which chance events were seeded, which model produced proposals, which policy accepted them, and which pack of scenario evidence the world was allowed to draw on. Change any of those and you have a different run, even if the prose rhymes. Keep them and you have a basis for replay, for comparison, and for noticing when a regression is real.

The fields that have to travel with the run

The receipt is a list of identities, not a narrative. Each field answers a question a later reader will have, usually after the people who ran the session have forgotten the details.

A patient identity without a version is not enough, because a persistent world changes as commits land. The receipt has to be able to point at the state the run started from, not merely the patient's name. Otherwise "the same patient" means "whatever that patient has become since Tuesday."

Model and provider versions are where agent work usually goes vague. "We used a frontier model" is not a version. Providers ship changes under stable product names. If the receipt only stores the product name, a different completion next month is indistinguishable from a different agent policy. The version string, or an equivalent immutable identifier, is what makes "the model changed" a checkable statement.

Policy version and evidence-pack version are easy to leave off because they feel internal. They are the run. A policy change that newly rejects an action will change the branch even when the agent proposes the same thing. An evidence pack change can disclose a different fact under the same question. If those versions are invisible, the agent is blamed for a shift in the world. The receipt keeps the blame attachable to the thing that actually changed.

The actor matters because a person and an agent can share a branch. "The run" is ambiguous until the receipt says who committed. Timestamps matter twice: wall-clock time says when the record was written, and simulation time says where the patient clock stood. Mixing them up makes a fork look like a later event when it was an alternative at the same moment. Branching only works if that distinction is stored, which is why receipts and forks belong together, as described in What Branching Clinical Simulation Actually Means.

Why a missing field breaks comparison

Suppose two agents are compared on one patient and one of them "does better." Better at what, under which policy, with which seed, against which evidence pack? If the receipt is incomplete, the honest answer is that you do not know. You know that two transcripts differ. You do not know whether the difference is the agent, the hidden update of a model, a policy tweak between Tuesday and Wednesday, or a seed that resolved a chance event in one direction.

That ambiguity is not a philosophical problem. It is an engineering one. Evaluation of agents in a patient world, laid out in How to Evaluate AI Agents in a Patient World, reads behavior across a run: what was gathered, what was uncertain, what was permitted, what was committed. Every one of those readings assumes the world stayed the world you think it was. The receipt is the assumption written down.

A receipt also limits the stories you are allowed to tell. If the model version is missing, you cannot claim the agent was responsible for a change in behavior across months. If the seed is missing, you cannot claim a rare branch was a property of the agent rather than a roll of the scenario. The discipline is the same as refusing to publish a result without the method. The method, here, is the environment plus the versions that configured it.

run
  patient @ start state
  scenario version
  randomness seed
  model/provider version
  policy version
  evidence pack version
  actor
  timestamps (wall clock + simulation clock)
        |
        v
  events: proposals, accepts, rejects, commits
        |
        v
  replay uses the receipt to ask: same inputs, same events?

The receipt sits above the events. Replay does not start from the final state and walk backward through a model's memory. It starts from the named inputs and the stored event list. If those inputs cannot be named, replay is improvisation.

What a receipt is not

A receipt is not a certificate of clinical validity. It does not say the scenario was realistic, the policy was wise, or the agent's commits would be acceptable in care. It says the run is specified. Specified is the precondition for every stronger statement, and it is not a substitute for them.

A receipt is not a dashboard of outcomes. It should not grow a score that implies a patient got better or worse. Patient worlds of the kind Patientic is building are synthetic, educational, or otherwise permitted simulations. A number attached to a branch is, at most, a description of that simulation under the recorded versions. The receipt's job is to make the versions impossible to lose, not to decorate the run with a grade.

What reproducibility is for

Reproducibility lets a builder tell a regression from a rewrite. It lets a reviewer check that an impressive branch still exists when the same receipt is applied again. It lets two agents be compared without quietly changing the patient underneath them. It lets a future reader, who was not in the room, see the actor and the clock instead of inheriting an anecdote.

It does not let anyone skip the safety boundary. A perfectly replayable run can still be the wrong thing to deploy against real patients, and this design does not cross that line. The receipt makes the simulation honest about itself. Honesty about the simulation is the part that can be engineered now. Claims beyond the simulation would need a separate validation gate that this essay is not pretending to open.

Patientic is being built so a run in the product can leave this kind of trail: seeds, versions, actor, and time, stored with the branch rather than reconstructed from chat. If a result cannot say which of those it used, it is not yet a result you can stand on.

Related reading

• AI Agents Need Environments, Not Just Context Windows
• How to Evaluate AI Agents in a Patient World