Package a model as a component.
Export and reload a real local model bundle; check named inputs, fitted preprocessing, dependency hashes and output meanings.
By the end: Load a versioned model component reproducibly and reject inconsistent artifacts or requests before inference.
Start with something concrete.
Your model worked in training, but another application gets very different predictions from the same measurements. Inspect what travels with the weights: feature order, units, missing-value policy, scaler and label meaning.
Try the interactive model ↓A replacement scaler is valid JSON and its file digest matches. Can the existing model safely use it?
Change one thing. Watch what follows.
- Load the supplied bundle and run the example request. Inspect all four standardized features and their contributions.
- Serialize and reload the active bundle. Rerun the same request and compare probabilities.
- Select the replacement-scaler scenario and load it. Explain why its valid digest is insufficient; verify the preceding component remains active.
- Try corrupted model bytes, reversed feature order and weights-only artifacts. Distinguish missing contracts, integrity and compatibility failures.
- Use the request presets to declare millimetres, then to mark petal length missing. Compare rejection with the explicit stored-fill policy.
- Download the runtime, bundle and request. Run the Python command, compare its probability and export your inspection note.
Loading this browser experiment…
The weights are only one part of the model
Imagine recording flower measurements in centimetres, subtracting training averages, dividing by training spreads, and then fitting a classifier. Another application sends raw measurements directly into those weights. Every number is finite and the program runs, but it is computing a different function.
Entering midway: a feature is one input measurement. Preprocessing transforms inputs before prediction. An artifact is a saved file used by the application. An input/output contract states what values mean and which forms are accepted. A digest is a short fingerprint computed from file bytes; changing those bytes changes the fingerprint with overwhelming probability.
The lab packages the existing classical-ML studio’s binary logistic classifier. It was fitted using 89 unique training measurement groups from the licensed Iris dataset. It predicts Iris-virginica versus the other two species. These groups identify identical measurements, not proven specimen identities. Packaging adds no new training and makes no new accuracy claim.
Trace a measurement before trusting its prediction
The component names four features in order: sepal length, sepal width, petal length and petal width. Every measurement uses centimetres. A missing value is explicitly null; zero is rejected because this contract requires positive measurements.
For each coordinate, replace a missing value with that coordinate’s stored training mean. Then subtract the stored training mean and divide by its stored training standard deviation, which measures spread. The resulting value describes how far the measurement lies above or below the training mean in units of training spread. It is dimensionless.
For a separate worked example, suppose a length is 6 cm, its training mean is 5 cm and its training spread is 0.5 cm. The standardized value is (6 − 5) / 0.5 = 2. Read this as “two training spreads above the mean”. This example explains the mechanism; the live table uses the actual fitted values.
Multiply each standardized coordinate by its corresponding learned weight, add those contributions and the bias, then apply the logistic transform to produce a probability between zero and one. The table connects every input to that calculation. The deliberately broken comparison skips scaling while keeping the same weights, so its different number is a software defect, not evidence that another model is better.
Do not refit preprocessing from each request. That would make a request’s meaning depend on what happened to arrive with it. If all four inputs are missing, the stored-fill rule produces standardized zeros and a bias-only prediction. A valid numerical result does not mean the application should act on it; an operating policy may require referral instead.
Define the complete interface
| Contract | What this component declares |
|---|---|
| Request | Version iris-cm-v1, unit cm, exactly four named fields, each null or a number in (0, 10] |
| Preprocessing | Training-mean fill followed by the saved mean and positive standard deviation |
| Model | Four logistic weights and one bias bound to exact preprocessing and contract digests |
| Output | Probability of Iris-virginica; label selected at threshold 0.5; “other” combines the remaining species |
Named JSON fields avoid depending on object key order. The internal weight vector still depends on the contract’s feature order. Reversing that order is incompatible even if all four names are present. Likewise, changing a label list can change the meaning of an otherwise unchanged probability.
The request declares its units. Merely changing “mm” to “cm” does not convert the measurements; divide millimetres by ten before declaring centimetres. Shape checks cannot detect every semantic lie: a plausible in-range number with the wrong meaning may pass. Test known examples and validate upstream measurement processes too.
Check integrity and compatibility separately
The bundle contains three JSON texts: contract, preprocessing and model. Each has a SHA-256 digest. The model also names the exact preprocessing and contract digests it requires. The scaler names its required contract.
A byte change without an updated digest fails integrity. A replacement scaler can have a correct digest for its own bytes and still fail compatibility because the model names a different scaler. A weights-only file cannot establish either the input transformation or output meaning. Try each failure and identify the first check that rejects it.
These checks are not authentication. Someone who replaces every file and rewrites every matching digest can create a self-consistent bundle. Obtain packages through a trusted distribution process; use appropriate signatures or trusted expected digests when provenance matters. A fingerprint alone proves neither who produced a model nor whether its behavior is acceptable.
Activate a replacement only after loading succeeds
The loader parses bounded inert JSON, checks versions, exact fields, numerical ranges, digests and dependency references, then activates the component. A failed replacement leaves the preceding successfully loaded component active. The UI displays its digest so a rejected candidate cannot be mistaken for the active model.
This demonstrates transactional loading: prepare and validate the new component before replacing the old one. It is not a production deployment or traffic-routing service. Release gates, rollback decisions, monitoring and incident response need additional evidence and are separate operations lessons.
Serialize and reload the active bundle, then submit the same request. Its probability should match. Download the same artifact and run it through the Python runtime to test another implementation of the contract. The recorded parity suite contains 152 cases, including missing values, compared against the original fitted pipeline within an absolute probability tolerance of one trillionth (0.000000000001). That checks numerical agreement, not generalization or calibration.
Keep execution and data separate
The required browser exercise uses small CPU arithmetic and locally supplied artifacts. Loading a bundle never executes learner text. The downloadable Python runtime uses only the standard library and inert JSON; it does not need the training framework or dataset to make a prediction. Both runtimes reject oversized files and incompatible inputs.
The source manifest preserves Iris attribution, licence and hashes. The parity record identifies training groups and the training recipe. Reproducing the fitted artifact uses the pinned P03 environment and repository script scripts/build-model-component.py. Running inference alone does not retrain it.
Practice: same outputs, different evidence
A browser and Python program agree on every supplied public example. This is useful integration evidence. It does not prove that every implementation is correct, that every input is safe, or that performance transfers to a new population. Add independently chosen boundary cases and review the intended use before making broader claims.
Apply this to your path
Guided experiment: export a valid bundle, reload it and explain one integrity failure, one compatibility failure and one request failure using their visible messages.
Implementation: run the Python component, then independently implement its loader or prediction function. Test renamed fields, reordered object keys, wrong units, missing values, zero spread and a valid replacement scaler bound to the wrong model. Keep parsing, validation and inference separate. Passing supplied examples is practice; implementation quality still needs independent review.
Decision brief: define what evidence is needed to accept a component from another team: input meaning, transformation version, provenance, task evaluation, known failure modes and ownership. Explain why a consistent bundle alone is insufficient for deployment approval.
Continue to account for computation to examine resource assumptions, or revisit the pipeline studio to inspect how the model was fitted.
A bundle has internally consistent hashes and passes the input contract. Which claim is justified?
Take this idea with you.
A reusable model is weights plus exact transformations, typed inputs, output meanings and versioned dependencies. Load atomically and test the same examples across runtimes.