An operator walks over to your desk and asks why the condition monitoring model started firing false positives last Tuesday. The honest answer for most teams is: we are not sure. Somewhere between a baseline shift, a threshold nudge, and a retraining run that pulled in a fresh window of sensor data, the model changed behaviour — and nobody can reconstruct which of those things was actually live when the spike started. That gap is what W&B Artifacts is there to close. The naive reading of Weights & Biases (W&B) Artifacts treats them as a file locker: a place to drop the final model.pt so someone can download it later. That works right up until the first incident. The version that survives an operator’s scrutiny treats artifacts as a versioned, lineage-tracked record of the exact dataset slice, calibration thresholds, and drift-telemetry snapshots that produced a given model. That record is the evidence a reviewer signs off on — and the thing that lets you answer the operator instead of shrugging. What matters most about W&B Artifacts in practice? An artifact in W&B is a named, versioned bundle of files or references, plus the metadata that says where it came from. You log an artifact from a run, and W&B records which run produced it and which artifacts that run consumed as inputs. Do this consistently and you accumulate a directed lineage graph: dataset version → training run → model version → the evaluation run that measured it. The mechanism that matters for condition monitoring is the automatic edge between produced and consumed artifacts. When a training run calls run.use_artifact("sensor-window:v7") and later logs run.log_artifact(model), W&B stitches those into a traversable chain. Six months later you can start from a deployed model version and walk backwards to the exact training window and the calibration config that shaped it — without relying on anyone’s memory. That is the practical meaning: lineage that is queryable instead of tribal. None of this is magic storage. Artifacts can hold the bytes directly, or hold references to bytes that live in S3 or a data lake, versioning the pointer and a content hash rather than copying terabytes. For sensor archives that already sit in object storage, reference artifacts are usually the right call — you version the evidence of which slice was used without duplicating it. What should a condition monitoring team version — the model, the thresholds, or the dataset? The short answer is all three, as distinct artifact types, because they change on different clocks and for different reasons. This is where teams most often under-scope: they version the model and treat the calibration config as a side note in a config file that gets overwritten on the next tune. For an anomaly pipeline, the value of the model depends less on the weights than on the sensitivity thresholds it was tuned against and the baseline window those thresholds assume. A model that fires an alert when reconstruction error crosses a threshold is only as trustworthy as the record of what that threshold was and why. Overwrite it silently and you have destroyed the evidence a reviewer needs. A versioning rubric for anomaly pipelines Artifact type What it captures Changes when Why version it dataset-slice The exact training/baseline window (or a reference + hash) New data window, relabelling, sensor added Reconstruct what “normal” the model learned calibration-config Sensitivity thresholds, per-channel limits, baseline stats Every retune, duty-cycle change Answer “which thresholds were live?” model Weights + architecture config Retrain Roll back or reproduce inference drift-snapshot Distribution stats logged at deploy time Each deploy checkpoint Compare live drift against the deploy baseline eval-report Metrics + false-positive counts on a held-out slice Each evaluation Reviewer sign-off evidence Treat these as separate types with their own version streams. A calibration retune that does not touch the weights should produce a new calibration-config:v-next linked to the same model — which is exactly the distinction the naive single-blob approach erases. How do artifacts capture lineage between data, model, and thresholds? Lineage is not a feature you turn on; it is a property you earn by being disciplined about use_artifact and log_artifact calls. Every time a run declares its inputs and outputs, W&B adds edges to the graph. Skip the declaration once and the chain breaks at that node. The pattern that holds up in practice: the training run consumes a dataset-slice version and produces a model version; a separate calibration run consumes that model plus a validation slice and produces a calibration-config; the deploy step consumes both and stamps a drift-snapshot as the baseline. Now the deployed configuration is a single traversable subgraph. When you ask “what produced the thing that is currently firing alerts,” the answer is a query, not an archaeology dig. This is the same discipline that makes an experiment tracker feed a production monitoring harness rather than just decorate a dashboard. The tracker captures the run; artifacts capture the durable objects the run touched. In our experience, teams that get value from W&B in production are the ones that treat artifacts as first-class deliverables, not as an afterthought at the end of a notebook — an observed pattern across the reliability engagements we run, not a benchmarked rate. How do artifacts help reconstruct a false-positive spike? Return to the operator at your desk. With artifact lineage in place, the diagnosis is mechanical: find the model version that was serving on the day of the spike, walk to its linked calibration-config, and compare the sensitivity thresholds and baseline stats against the version that was live the week before. If a retune shifted a per-channel limit, you see it in the diff. If the training window rolled to a new season of sensor data, the dataset-slice version tells you. Without this, the same investigation is guesswork — someone greps chat logs, someone half-remembers a threshold change, and the model gets muted rather than fixed. The ROI is blunt: artifact-tracked lineage shortens the time to diagnose a false-positive spike from days of archaeology to a lineage lookup, which keeps the false-positive rate inside the review queue’s triage capacity instead of overwhelming it. That is a project-specific outcome we anchor to, not a universal number — the size of the win scales with how noisy your baseline shifts are. Artifacts version the evidence, but they do not detect the drift for you. The drift-snapshot you stamped at deploy is a baseline to compare against; you still need live telemetry to notice that today’s distribution has moved. Capturing that telemetry is a separate discipline — logging drift telemetry from a production model with wandb.log feeds the live signal, while artifacts hold the fixed reference points that signal is measured against. How do artifacts fit into a validation pack a reviewer signs off on? Before an anomaly model goes to production, a reviewer needs to see that the calibration was deliberate, the thresholds are documented, and the evidence is reproducible. W&B Artifacts is one concrete mechanism for producing exactly that record: the versioned calibration-config and dataset-slice, linked to the eval-report that shows false-positive behaviour on a held-out window, is the operational-anomaly validation lens made tangible. The reviewer is not signing off on the model weights. They are signing off on the claim that these thresholds, tuned against this data, produce a false-positive rate the review queue can absorb — and on the assurance that if it goes wrong, the state can be reconstructed. Artifacts turn that assurance from a promise into a lineage query. This is the same evidence posture that governs where reliability gates belong across an ML pipeline: each gate consumes a versioned artifact and emits one, so the sign-off chain is unbroken end to end. It sits inside our broader approach to production AI reliability, where the durable question is always whether the evidence outlives the engineer who produced it. What are the limits — where do you still need separate monitoring? Artifacts are a system of record, not a monitoring system. Three limits are worth stating plainly. First, artifacts do not watch anything. They hold the deploy-time drift-snapshot, but noticing that live sensor distributions have drifted away from it requires continuous telemetry and an alerting path — the artifact is the ruler, not the alarm. Second, artifacts do not triage. When false positives climb, someone still has to work a review queue and decide which alerts are real. Lineage shortens the diagnosis once you are looking; it does not replace the queue. Third, lineage is only as complete as your discipline. A run that forgets to declare its input dataset breaks the chain at that node, and the graph silently tells you less than you think. This is closely related to the discipline of tuning sensitivity thresholds that actually hold — the sweep produces the numbers, and the artifact preserves which numbers you chose and why. FAQ How does wandb artifacts work? A W&B artifact is a named, versioned bundle of files or references plus the metadata recording which run produced it and which artifacts it consumed. Logging artifacts consistently builds a traversable lineage graph — dataset version to model version to evaluation — so you can walk backwards from a deployed model to the exact inputs that shaped it without relying on memory. What should a condition monitoring team version as an artifact — the model, the calibration thresholds, the training dataset slice, or all three? All three, as distinct artifact types with separate version streams, because they change on different clocks. The model’s trustworthiness depends heavily on the sensitivity thresholds and baseline window it was tuned against, so versioning the calibration config separately — linked to the same model — preserves the evidence a reviewer needs and avoids silently overwriting it on the next tune. How do wandb artifacts capture the lineage between a training dataset, a model version, and the sensitivity thresholds it was tuned against? Lineage is earned through disciplined use_artifact and log_artifact calls: the training run consumes a dataset slice and produces a model, a calibration run consumes that model and produces a threshold config, and the deploy step consumes both. Each declaration adds edges to a graph, making the deployed configuration a single traversable subgraph you can query instead of reconstruct from chat logs. How do artifacts help reconstruct which calibration and drift-telemetry state was live when a false-positive spike occurred? Find the model version serving on the day of the spike, walk to its linked calibration config, and diff the thresholds and baseline stats against the prior live version. A shifted per-channel limit or a rolled training window shows up in the diff, turning a days-long archaeology exercise into a lineage lookup. How do wandb artifacts fit into the validation pack a reviewer signs off on before an anomaly model goes to production? The versioned calibration config and dataset slice, linked to an evaluation report showing false-positive behaviour on a held-out window, form the reproducible evidence a reviewer signs against. The sign-off is on the claim that these thresholds tuned against this data produce an absorbable false-positive rate — and on the assurance that the state can be reconstructed if it goes wrong. What are the limits of wandb artifacts — where do you still need separate drift-telemetry monitoring and a false-positive review queue? Artifacts are a system of record, not a monitoring system: they hold the deploy-time drift snapshot but do not watch live distributions, and they do not triage alerts. You still need continuous drift telemetry to notice movement against that baseline and a false-positive review queue to work the alerts; lineage shortens diagnosis but does not replace either. How do artifact versions support rolling a retune back cleanly after a baseline shift as an asset ages or its duty cycle changes? Because a calibration retune produces a new config version linked to the existing model, rolling back is a matter of re-pointing the deploy step at the prior calibration-config version whose false-positive behaviour is documented in its linked eval report. As an asset ages and its duty cycle changes, the version stream becomes an audit trail of every threshold decision, so a clean rollback is a lineage operation rather than a reconstruction. The harder question is not whether you can version the evidence, but whether your pipeline forces you to. If the calibration state a model was tuned against is not itself a versioned artifact, the pipeline is trusting an operator’s memory to survive the next baseline shift — and that is the failure class that quietly mutes a model six months past go-live.
