Version data and experiments.
Reconstruct a result from local data, code, configuration and artifact records; locate changed preprocessing.
By the end: Trace an experiment’s dependencies and distinguish file identity, interface compatibility, numerical replay and task quality.
Start with something concrete.
Two folders both contain iris.csv and model.json. One predicts differently. A version label does not tell you which data, preprocessing or software produced either result. Follow the manifest to reconstruct the evidence.
Try the interactive model ↓A file is renamed without changing its bytes. What happens to its SHA-256 digest?
Change one thing. Watch what follows.
- Reconstruct the original recorded files. Inspect the 89 training group IDs, rebuilt preprocessing and repeated prediction.
- Rename the CSV without changing it, then change one measurement without renaming it. Compare identity checks and inference parity.
- Rename a cm column to mm and explain why schema validation rejects it before preprocessing reconstruction.
- Change the stored spreads with internally consistent dependency hashes. Identify which compatibility checks pass and which lineage/numerical checks fail.
- Add a code comment and declare a different sklearn version. Explain why neither scenario by itself demonstrates worse task accuracy.
- Write and download a reproduction note with the first changed dependency, what the browser actually reran, and what a real training replay still needs.
Loading this browser experiment…
A result needs more than a filename
A class trains a model on flower measurements. A week later the same command produces a different result. The CSV still has the same name, but a measurement was corrected. A teammate also changed preprocessing. Without a record of the original inputs and recipe, rerunning the command does not reconstruct the original experiment.
Entering midway: a schema describes fields and their meanings. Configuration describes choices such as model family and training settings. An artifact is a saved output such as fitted weights. A manifest lists the inputs and dependencies needed to identify a run. Lineage is the chain connecting those inputs, transformations and outputs. Reproducibility means obtaining an explicitly specified result again under an explicitly specified protocol; say whether you mean identical bytes, close numerical results or similar task performance.
Start with the lab’s original manifest. It refers to a real local Iris model fitted earlier, not a fictional training claim. You can reconstruct its training-only means and spreads and reproduce a stored inference result without installing Python. Full fitting requires the separate implementation studio and its recorded environment.
Follow the dependency chain
| Dependency | What to preserve | Why it matters |
|---|---|---|
| Data | Exact bytes, source, licence, units and schema | A corrected measurement or changed unit changes the training problem |
| Partition | Grouping policy and exact training IDs | A different split changes what the model can learn and which checks are independent |
| Training recipe | Model family, hyperparameters, preprocessing and stopping settings | The same data can produce different fitted functions |
| Code | Exact loader, pipeline and exporter versions | A silent preprocessing edit can change the function without changing its interface |
| Environment | Language/library versions, relevant platform and execution settings | Numerical libraries and execution choices can change a result |
| Randomness | Seeds and how random streams are used, or an explicit reason they do not apply | A seed is only one input to a stochastic procedure |
| Artifacts | Weights, preprocessing, contract and their dependency fingerprints | Compatible file types are not necessarily the original fitted combination |
| Result | Inputs, expected output, metric definition and comparison tolerance | “It works” is too vague to replay |
The lab’s manifest records the original fitting library versions. It does not inventory the browser’s Python environment—there is no Python interpreter running here. Declaring the old version in a text field would not install it or prove it was used. Similarly, an editable local manifest is evidence to inspect, not authenticated provenance.
Content identity and behavior answer different questions
A SHA-256 digest fingerprints exact file bytes. Renaming a file leaves its digest unchanged. Adding whitespace or a harmless comment changes its digest even when program behavior stays the same. This sensitivity is useful for identifying the exact artifact; it does not measure whether the change was useful or harmful.
Try the code-comment scenario. The recorded code identity no longer matches, but the browser still uses the stored model for inference. The old probability can remain identical. That does not show what retraining the edited code would do, and it certainly does not measure new task accuracy.
A digest is not a digital signature, a licence grant or a data-quality check. Preserve the source and licence separately. Know where trusted expected digests came from; replacing both the file and its claimed fingerprint can produce a self-consistent record.
Rebuild preprocessing from the right partition
The supplied run uses 150 source rows but 149 unique measurement tuples. Identical feature vectors form a group. Within each species, first-occurrence group positions repeat through five buckets: evaluation, development, training, training, training. This yields 89 training, 30 development and 30 evaluation groups. Generated row IDs and matching measurements are not proof of physical specimen identity.
This three-way studio protocol differs from the original feasibility lab’s two-way split, even though both use the same CSV. The original dataset manifest records source provenance and its earlier teaching split; the experiment manifest records this run’s actual training IDs. Preserve both roles rather than assuming the dataset filename determines an experiment’s partition.
For a small separate example, training measurements 4, 5 and 6 cm have mean (4 + 5 + 6) / 3 = 5 cm. Their deviations are −1, 0 and 1 cm. Squaring and averaging gives (1 + 0 + 1) / 3 = 2/3 square centimetres. Taking the square root gives a population spread of about 0.8165 cm. Standardizing a 6 cm request gives (6 − 5) / 0.8165 ≈ 1.225, a dimensionless number.
Here “population” means dividing by the number of training values, N, rather than N − 1. This follows the fitted scaler’s convention; it is not claiming the training sample is the whole botanical population. Mean is the sum divided by N. Spread is the square root of the mean squared deviation. The implementation uses divisor 1 for a constant column, whose true spread is zero, so division remains defined; the original data have nonzero spreads.
Practice: an unrelated evaluation measurement changes from 8 cm to 9 cm. Should these training means and spreads change? No. Fit transformations on training data only. In the lab, changing a training value does change the reconstructed preprocessing even though the saved component can still reproduce its old prediction.
A valid replacement can be the wrong historical artifact
The changed-spread scenario multiplies every stored spread by 1.1 and updates both the preprocessor digest and the model’s dependency reference. Its file integrity and supported interface pass. Its lineage no longer matches the original manifest, and the reconstructed training spreads disagree.
For intuition, a deviation of 2 cm divided by a spread of 1 cm produces 2. Dividing the same deviation by 1.1 cm produces about 1.818. The weights have not changed, but their inputs have. The recorded request therefore generally has a different probability.
This is deliberately different from a broken dependency reference. An interface checker asks whether the declared artifacts can be used together under the supported contract. A reproduction checker asks whether they are the original artifacts and whether the specified outputs match. Task evaluation asks whether the resulting predictions are useful and reliable. Passing one does not imply passing the others.
Record randomness honestly
A seed initializes a random-number sequence; it does not describe the data, split, code, order of operations or software environment. Reusing one seed with different data does not recreate an experiment. Parallel execution and some hardware operations can introduce additional nondeterminism even with a seed recorded.
This logistic recipe uses lbfgs, a deterministic optimization procedure for this configured pipeline, without requested random sampling or stochastic initialization. The manifest explicitly records a null seed and explains why. A missing seed for a stochastic training loop would be a different problem. Do not invent a seed retroactively or imply it proves how an artifact was trained.
The training settings include C = 1, maximum 500 iterations and optimizer tolerance 1e-8. In this library, larger C means weaker regularization. The optimizer tolerance controls convergence; it is not the same as the inference comparison tolerance of 1e-12. Both are recorded with their meanings.
State exactly what was reproduced
The browser performs four kinds of work: hashes bounded local text files, reconstructs the training partition and preprocessing, checks the saved component’s declared dependencies, and computes one stored inference case. It does not rerun fitting, compare all future inputs, authenticate a publisher or establish task accuracy.
An absolute comparison tolerance of 1e-12 accepts probabilities whose difference is at most 0.000000000001. It accommodates small numerical rounding differences in this bounded example. It is not a universally appropriate model-quality threshold. Cross-platform training can require a separately justified numerical or statistical criterion rather than identical output-file bytes.
A full training replay needs the original data, partition and recipe; the exact code and suitable environment; a fresh execution; and declared comparisons for artifacts and results. The supplied component generator has been replayed on the development host, but this browser exercise does not run that generator for the learner. Use the classical pipeline studio to practice actual fitting and frozen replay.
Produce evidence for your chosen depth
- Guided exploration: reconstruct the original and changed-spread scenarios. Draw the first changed dependency and explain how a valid component can fail historical reproduction.
- Implementation practice: run the local pipeline studio, preserve the freeze manifest and code hashes, and reproduce a result in a fresh output directory. Add a test that fails when training preprocessing is rebuilt from the wrong partition. Explain any numerical tolerance and platform limitation.
- Decision practice: review two run records. Identify missing provenance, distinguish unchanged inference from retraining evidence, and list what must be checked before treating a changed model as the same approved release.
Download the manifest and your note. Keep mismatched evidence instead of relabelling the changed files as the original run. A changed experiment can be worth pursuing; give it a new identity and evaluate its behavior separately. Independent artifact review and learner validation remain distinct from completing this practice.
The original prediction is reproduced, but the training CSV hash differs from the manifest. What is established?
Take this idea with you.
Record exact data, schema, split, recipe, code, environment and artifact dependencies. Separate what matches numerically from what was actually re-executed.