Determinism Is Not Repetition: The Conditions of Reproducible Data

1. The misleading equation

A common architectural slogan states:

As a definition of a mathematical function, this is unremarkable. As a statement about production data systems, it hides almost everything that matters. What appears to be $F$ is usually a family of computations indexed by versions, configuration, time, environment, and external knowledge.

A more honest model is

where $v$ is code version, $\theta$ configuration, $r$ reference data, $e$ execution environment, $t$ temporal context, $p$ policy state, and $\omega$ stochastic or concurrency state. Two runs with identical source rows may legitimately differ because one of these arguments changed.

Repetition means invoking what appears to be the same job again. Determinism means that a fully specified state maps to one output. Reproducibility means that an independent execution under a sufficiently equivalent state can regenerate the result. Auditability means that the state and transformation can be inspected well enough to justify the result. These properties overlap but are not synonyms.

2. What counts as the same input?

In data work, input is often identified with a file or table snapshot. Yet a record acquires meaning through context. A code A17 may be interpreted through a dictionary; a local timestamp through a time zone; a monetary amount through a currency table; a clinical value through a unit and method; a customer status through policy valid at a particular date.

Define the effective input as

where $X$ is the observed dataset, $R$ the reference state, $\Theta$ configuration, $P$ policy, and $T$ temporal frame. Equality of effective inputs requires an equivalence relation, not necessarily byte identity:

The equivalence relation depends on the computation. Two library patch versions may be equivalent for one transformation and not another. Two reference snapshots may differ in irrelevant entries. Reproducibility therefore requires a declared notion of material equivalence.

This is philosophically significant. Identity is not a primitive label but a criterion. The platform must specify the criterion by which two computational situations count as the same for the claim being reproduced.

3. Sources of non-determinism

Some non-determinism is explicit: random sampling, probabilistic models, approximate algorithms. Other forms are accidental and more dangerous.

Distributed operations may not guarantee row order. Floating-point aggregation can vary with reduction order because

under finite precision. Concurrent upserts can produce race-dependent winners. APIs can return changing results. Current-time functions, auto-generated identifiers, environment variables, locale settings, and default time zones introduce hidden state. Query planners and library upgrades can alter execution paths. Mutable reference tables can retrospectively change mappings.

Even apparently deterministic SQL may contain ambiguity if ordering is omitted. A first or last operation without a total ordering is not a function over the logical relation; it is a function over an incidental physical arrangement.

Let $N$ be a non-determinism budget. We can classify sources as

where the terms represent scheduling, concurrency, floating point, environment, and external-service uncertainty. The goal is not always to make $N=0$, which may be prohibitively expensive. It is to identify which components can alter decisions and to constrain or record them accordingly.

4. Reproducibility as evidence preservation

A reproducible computation requires an evidence package. Let the provenance record for output $y$ be

where hashes identify input, code, references, environment, and policy; $\tau$ records execution time and logical interval; and $\rho$ records runtime parameters, seeds, and resource-relevant metadata.

Hashes alone are not enough. A content hash proves identity if the referenced object is retained and retrievable. Container digests help but may not capture external services. Dependency lock files help but may not capture CPU-specific numerical behaviour. Reproducibility is an engineering spectrum, not a binary seal.

For critical outputs, the platform should preserve either the full execution environment or a reconstruction recipe with verified artefacts. The required fidelity depends on consequence. Exploratory analytics may accept approximate reproduction. Regulated reporting may require bitwise or numerically bounded equivalence. Machine-learning outputs may require tolerance-based criteria:

The tolerance $\epsilon$ is part of the contract and should not be invented after a discrepancy appears.

5. Event time, system time, and the moving present

Time-dependent computation is a major source of false reproducibility. A query such as “active records” or “latest valid result” depends on an evaluation time. Rerunning it tomorrow against the same append-only history may produce a different answer because the predicate references the present.

Temporal functions should be written explicitly:

where $t_{asof}$ is the time in the represented world and $t_{known}$ the system’s knowledge cut-off. Bitemporal reasoning allows the platform to reconstruct what was true at a time and what was known at a time.

Late-arriving events complicate this further. A report generated on Monday may be correct given Monday’s knowledge and different from a retrospective report generated Friday for the same event period. Neither is necessarily wrong. They answer different temporal questions.

Reproducibility requires that those questions be preserved. Otherwise the organisation mistakes a moving epistemic horizon for computational inconsistency.

6. Reproducibility in distributed platforms

Distributed systems complicate the idea of a single execution. A job may be retried at task level, speculative copies may run concurrently, partitions may complete under different executors, and outputs may be committed through transactional protocols. The visible run is an equivalence class of lower-level attempts.

Let $E=\{e_1,\dots ,e_k\}$ be execution attempts and $K$ a commit protocol. The published output is

not simply $F(x)$. Determinism therefore includes commit semantics. Exactly-once claims often mean exactly-once visible effect under a particular protocol, not exactly-once physical computation.

A reproducible platform must record partitioning, checkpoint state, watermark, and commit identifiers where these can affect output. It must also distinguish logical idempotency from physical replay. Re-executing a deterministic transformation can still duplicate effects if sinks are not idempotent.

The lesson is that reproducibility belongs to the end-to-end computational transaction, not merely to transformation code.

7. Equality of results and equality of reasons

Two executions can produce numerically equal outputs for different reasons. A changed mapping may be offset by changed source values; a failed filter may be masked by an empty partition. Equality of $y$ does not prove equality of computation.

We should distinguish extensional equality

from intensional equivalence

The first compares results; the second compares the production path and relevant state. Audit requires both. A number that happens to match is not necessarily the same warranted claim.

This distinction echoes a long philosophical debate between extension and intension. In data platforms, the debate is operational. A regulator, scientist, or incident investigator may need to know not only that the total is unchanged but that the same population, rules, time window, and exclusions produced it.

Reproducibility is therefore an epistemic property. It concerns the repeatability of justification, not merely the recurrence of a value.