A reproducible financial calculation is a specified computation that can be rerun with identified inputs and execution conditions to meet a declared agreement criterion. A model-service artifact is only one component of that specification.

The calculation behind a model name

A model name identifies a family or implementation label. The actual result also depends on input data, contractual conventions, numerical settings and execution dependencies. Keeping the name unchanged does not keep those inputs unchanged.

A conventional pricing model consumes defined market and contract inputs. A learned model also carries fitted parameters and the training process that produced them. Both need versioned runtime inputs and execution conditions, although a pricing-library version and a learned parameter artifact represent different objects.

Take unchanged model code receiving a revised curve and a changed solver tolerance. A different result can follow from those changed inputs without any corrupted deployment. Diagnosing the change requires the full calculation specification, not only the source-code revision.

Runs, artifacts and data references

MLflow organizes work into runs with associated metrics and artifacts. A run record can connect code, parameters, outputs and the files needed for reconstruction. The record still needs references that resolve to the intended data and environment.

A dataset name that always resolves to the latest data is weaker than an identified retained version. A random seed controls a specified source of randomness; it does not freeze changed inputs, libraries or numerical configuration. The intended agreement criterion also needs to be explicit: identical stored bytes and agreement within a stated numerical tolerance are different requirements.

Calendars, curves, units, missing-value handling and reference mappings belong in the input contract when they affect the calculation. An application that supplies the same array shape with a different unit has changed the computation’s meaning even if the service accepts the request.

Build provenance and calculation validity

Build provenance connects a software artifact to its source and build process. Artifact signing supports verification under a signing and trust arrangement. SLSA and Sigstore supply mechanisms for these software-supply-chain questions.

A correctly identified artifact can still implement an unsuitable financial model or use incorrect conventions. Provenance establishes where the code came from; numerical tests establish selected computational properties; model assessment addresses fitness for the intended use. These findings need separate evidence.

A release comparison can hold data and settings fixed while changing the artifact. A data comparison can hold the artifact fixed while changing an input version. Separating the changes makes output differences attributable within the test’s stated scope.

Serving and dependency lifecycles

A production service adds request validation, failure handling, monitoring and operating dependencies. A training framework, registry and inference server can have separate support lifecycles. Continued ability to execute an old artifact does not establish continued support for every component that serves it.

The service needs a defined response to infeasible inputs, unavailable data and numerical failure. Returning an output is a different result from satisfying the declared tolerance or business contract. Monitoring needs to preserve that difference.

Scope of reproducibility

A complete replay requires the specified artifacts, permitted input access and controlled execution conditions. A reproducible result can still rely on historically unavailable data or an unrealistic simulation assumption.

What changes between model services is the calculation and operating environment. Reproducibility preserves a declared computation; it does not, by itself, establish statistical validity, financial suitability or permission to reuse the inputs.

Questions about experiment tracking

Does fixed model code guarantee the same result?

No. Data, conventions, numerical settings and execution dependencies also affect the result.

Does a signed artifact establish a valid financial model?

No. Artifact provenance and model suitability answer different questions.

Does a fixed random seed guarantee reproducibility?

No. It controls a specified source of randomness; the other inputs and execution conditions still need to be preserved.