Traceability in Simulation Outputs

Traceability is not the log you keep; it is the backward question you can answer. The property that matters is taking a specific output — this detection, this loss, this number in a briefing — and reconstructing the causal path that produced it. That is not the same as reproducibility: a deterministic black box reproduces perfectly and explains nothing. The reframe that makes deep traceability affordable is that you do not have to log everything. A deterministic run can be replayed from a small recorded envelope, so any level of causal detail can be reconstructed on demand instead of paid for in advance — traceability becomes an on-demand capability rather than an always-on tax.

The usual picture of traceability is forward capture: an envelope around each run recording scenario identity, model version, input data, execution configuration, and timestamped outputs. That envelope is necessary, and a run missing it cannot be trusted. But it answers only one question — how was this run configured — and that is not the question that arrives under scrutiny.

The question that arrives is about a specific result. Why did this sensor detect later in this run than in the last one. Why did this engagement happen at all. A perfect envelope says nothing about either; it locates the run without explaining the number. Traceability is the second, harder property: the ability to take a particular output and follow it backward to the events, orderings, and parameters that produced it. Capture is the precondition. Tracing is the capability — and the two are routinely confused, because the first is easy to build and easy to mistake for the second.

A deterministic system that re-runs to the same trajectory has reproducibility. It does not yet have traceability. Replaying a run hands you the same answer again; it does not tell you which factor drove it, or where in the execution the outcome was decided. Reproducibility is a statement about sameness. Traceability is a statement about attribution. They are complementary and frequently conflated, and the conflation is expensive: a team that can re-run any result comes to believe it can account for any result, and discovers the gap only when someone asks why — and the honest reply is that the system can produce the number again but cannot say where it came from.

Determinism matters here, but not as a substitute for explanation. It makes the explanation stable — the causal path behind a given output is the same every time the run is examined, so a trace is a permanent property of that run rather than a snapshot of one volatile execution. Without determinism, even a detailed trace describes only the run that happened to occur, and the next run, drifting, invalidates it. Determinism is what lets a trace mean something beyond the moment it was captured. It is not itself the trace.

The naive way to make a run explainable is to record everything as it happens — every state transition, every event, every intermediate value. At any serious scale this is infeasible, and it imposes a permanent trade between how much you can trace and how fast the system can run. Detailed traceability and high performance look like opponents.

A deterministic core dissolves that opposition. Because the run can be replayed exactly from a small recorded envelope — inputs, seeds, model versions, ordering policy — any intermediate detail can be regenerated afterward by replaying with instrumentation turned up to whatever depth the question requires. You record little and can recover much. The expensive, deep trace is not produced on every run and stored forever; it is produced on demand, for the one run and the one output being interrogated. Traceability stops being a tax levied on every execution and becomes a capability invoked when a result is challenged: cheap by default, arbitrarily deep when it has to be. This is one of the quieter dividends of building on a deterministic core — not that results repeat, but that they become cheaply explainable, because the run itself is the record and instrumentation can be added to a replay without changing what happened.

On-demand reconstruction still leaves a design decision: which causal events deserve to be first-class — named, indexed, and queryable directly — and which are left implicit, recovered by replay only when needed. Make everything first-class and the trace becomes its own unmaintained system, competing with the simulation for attention. Make nothing first-class and every backward question requires re-running the study before it can even be asked.

The resolution should follow the questions the analysis is expected to survive. If "why was this target engaged" is a question a reviewer will predictably ask, engagement decisions are recorded as first-class events with their triggering conditions attached, so the common question is answered immediately; the lower-level mechanics beneath them stay reconstructable for the rarer, deeper inquiry. Choosing that line is an analytical act, not a logging-configuration detail. It decides, in advance, which questions the system answers in seconds and which it answers in a re-run — and getting it wrong is not a loss of data, because determinism preserves the ability to reconstruct, but a loss of speed exactly where speed under questioning matters most.

Traceability exists to be believed by someone who was not present when the run executed — a reviewer, an accreditation authority, a customer. That makes the integrity of the record part of its function, not an afterthought. A trace that can be quietly edited after the fact, or silently reconciled against a different model build than the one that actually ran, is not evidence; it is a narrative that happens to support the conclusion.

So the envelope and any first-class events must be bound to the run that produced them — sealed at the moment of capture and tamper-evident, so that the version of the scenario and model in the record cannot diverge from the version that executed without the discrepancy being visible. The cryptographic mechanics for this are ordinary. The principle is not: traceability's entire value is that it is trusted by an outsider, and that trust extends exactly as far as the record provably cannot have been adjusted to fit the answer it now explains.

Traceability is designed backward from the questions a result must withstand, not forward from whatever is convenient to log. Determinism makes the deep answers affordable, by turning the run into something that can be re-examined rather than only re-read. The resolution decision makes the predictable answers fast. Integrity makes all of them believable. None of these is satisfied by a richer log file; each is an architectural choice about what the system can be asked after the fact.

A simulation that can be re-run but not explained has reproducibility without traceability, and under serious review that is precisely where confidence fails — not at the moment a result is produced, but at the moment someone asks why it is what it is, and the system can only offer to produce it again. The work of traceability is making sure the answer to "why this number" already exists, or can be reconstructed on demand, before anyone has thought to ask.