A pilot AOI model that converged cleanly on the training curve is not the same artefact as a model still holding its false-reject rate on a live conveyor three months later. The gap between those two states is telemetry — and wandb.log is the mechanism most teams use to capture it, then quietly abandon once the pilot dashboard looks good. That abandonment is the failure this article is about. wandb.log gets treated as a training-time scalar sink: log the loss, log pilot accuracy, watch the curve converge, and call the run done. The metrics that actually decide whether an automated optical inspection deployment survives contact with production — false-reject rate, escape rate, and distribution drift against a moving conveyor and shifting lighting — never make it into the log. So when the line-side model starts to degrade, there is no signal, and no artefact to prove the deployed model is even the model that was released. How does wandb.log work in practice? wandb.log is a single Python call that writes a dictionary of key–value pairs to the currently active run. You call wandb.init() once to open a run — which creates a versioned record with its own config, environment, and identity — and then wandb.log({"loss": 0.12}) as many times as you want during that run. Each call appends a row to the run’s history table under whatever keys you pass. The keys are arbitrary strings you choose; the values are usually scalars, but can also be images, tables, histograms, or media objects. The mental model that trips people up is thinking of wandb.log as “printing to a chart.” It is closer to writing a row to an append-only time series that happens to render as a chart. Every logged dictionary is stamped with a step, and the platform reconstructs curves from the sequence of steps. That distinction matters the moment you leave training, because in production the thing generating “steps” is no longer an optimizer loop — it is the conveyor, one inspection batch at a time. Two facts are worth stating plainly, because both are load-bearing for everything that follows. First, wandb.log is bound to a run; without an open run there is nothing to log to. Second, the run — not the log call — is what carries the identity and version evidence. The log call records what happened; the run records which model, on which code, with which config it happened to. Single step, step index, or summary: what is the difference? There are three logging patterns, and confusing them produces most of the “my charts look wrong” problems. Logging without a step lets W&B auto-increment an internal counter each time you call wandb.log. This is fine when your log calls are naturally sequential and you never need to align them against an external clock. It falls apart the moment two metrics are logged at different frequencies — the counters drift apart and the charts stop lining up. Logging with an explicit step index — wandb.log({"escape_rate": 0.004}, step=batch_id) — pins each row to a number you control. For a line-side model, the natural step is not a training iteration but a production unit: a batch index, a shift number, or a time bucket. Choosing the step deliberately is what lets you overlay false-reject rate and input-drift score on the same axis and trust that a spike at step 4,120 in one metric corresponds to step 4,120 in the other. Summary metrics are different in kind. wandb.run.summary["final_frr"] = 0.011 writes a single value that represents the run as a whole, not a point in its history. Summaries are what populate the run table you scan across dozens of deployments. The history answers “how did this run behave over time”; the summary answers “how do I rank this run against its siblings.” A production AOI instrument needs both — a continuous history for incident detection and a summary that lets an engineer sort forty line-side runs by escape rate at a glance. wandb.log pattern selection for line-side AOI Logging pattern What it captures Step choice for AOI Use it for No explicit step Auto-incremented sequence N/A (avoid in production) Quick pilot scalars only Explicit step= One row per production unit Batch ID, shift, or time bucket Continuous drift telemetry run.summary[...] One value per run N/A (run-level) Cross-deployment ranking, release evidence Media / table log Images, confusion tables, histograms Same step as scalars Rejected-sample audit, drift diagnosis The table is a starting rubric, not a rule. The one durable principle: in production, choose your step from the physical line, never from an optimizer. Which metrics should a line-side AOI model log beyond training accuracy? Training accuracy tells you the model learned the pilot distribution. It says nothing about whether the model is still useful on Tuesday’s night shift under a flickering fixture. The metrics that matter line-side are the ones tied to the cost of being wrong. False-reject rate (FRR) is the fraction of good units the model flags as defective. It is the metric that quietly kills AOI deployments: every false reject is a good part pulled off the line, re-inspected by hand, and counted against the automation’s ROI. A creeping FRR is the most common reason a team reverts to manual inspection — not because the model failed catastrophically, but because it started costing more than it saved. Escape rate is the inverse and the more dangerous one: real defects the model passed as good. Escapes are expensive because they surface downstream, sometimes at a customer. In our experience across industrial-CV engagements, teams instrument FRR long before they instrument escape rate, because escapes are harder to observe — you only learn about them when something breaks later (observed pattern; not a benchmarked rate). Logging an escape-rate proxy, even a lagging one built from downstream returns, is what turns a silent failure into a visible curve. Input distribution drift is the leading indicator for both. The conveyor speed changes, a supplier switches packaging, a maintenance crew swaps a light fixture, and the pixel distribution the model sees moves away from what it was trained on. Logging a drift score — an embedding distance, a per-channel brightness histogram, a population-stability index against the training reference — gives you the signal before FRR and escape rate move. Which drift signals actually predict AOI degradation is a computer-vision question in its own right; the compound-failure-mode framing for line-side CV models is the companion to this logging discipline. The parallel discipline for what to log and why is covered in W&B logging for AOI model reliability; this article is about the mechanics of the wandb.log call itself and where each pattern maps onto those requirements. How do runs and artifacts provide version-pinning evidence? Here is the reframe that separates a pilot dashboard from a production instrument. A dashboard proves a model once hit a number. A production deployment has to prove, continuously, that the model line-side today is the same released artefact that passed validation — and wandb.log alone does not do that. The run and its artifacts do. When you open a run with wandb.init(config=...), the config captures the parameters and, if you wire it up, the code state and environment. When you register the trained weights as a W&B Artifact and version it, you get an immutable, hashed reference. The line-side inference service then logs, alongside its FRR and drift telemetry, the artifact version it is actually serving. That single logged field is the version-pinning evidence: it links the metrics being observed to the exact model producing them. Without that link, a drift incident is undiagnosable. You see FRR climbing but cannot tell whether someone deployed the wrong checkpoint, a rollback half-completed, or the model genuinely degraded. With it, the first question — “is this even the released model?” — is answered by a logged field, not an archaeology dig. The W&B artifact versioning discipline for condition monitoring generalizes this pattern beyond AOI. How do you diagnose AOI drift in hours instead of days? The difference between a hours-long and a quarter-long recovery is whether the diagnosis is a query or an investigation. If your line-side model logs FRR, escape-rate proxy, input-drift score, and served artifact version to the same run against a production step index, a drift incident becomes a small number of overlaid curves you read in one sitting. Consider a worked case with explicit assumptions. Suppose a PCB inspection line logs per-shift batches, and on the Wednesday night shift the FRR curve jumps from a baseline near 1% to roughly 4%. You open the run and overlay three curves at that step: If the input-drift score jumped before FRR, the model is seeing something new — check the drift histogram: a brightness shift points at a light fixture, a shape-distribution shift points at packaging or a supplier change. If drift is flat but the served-artifact-version field changed at that step, a deployment swapped the model. The fix is a rollback to the pinned version, not a retrain. If both drift and artifact version are flat and FRR still moved, the change is in the physical process feeding real defects — the model is behaving correctly and reporting a genuine defect spike. That decision tree runs in the time it takes to open one run, because the evidence was logged as it happened. Teams that instrument telemetry this way recover from a drift incident in hours rather than days (observed pattern across TechnoLynx industrial-CV engagements; not a benchmarked rate). Teams that only logged training metrics have none of these curves — they discover the problem when a quarter of miscounted rejects surfaces in the numbers, and by then the line has already reverted to manual inspection. How does wandb.log fit into the validation pack and rollback path? wandb.log is the mechanism that populates the validation evidence, not the validation itself. Disciplined run and artifact logging is what makes drift telemetry and version-pinning evidence legible to an industrial-CV validation lens. The validation pack for a production AOI deployment wants three things the logging discipline directly produces: proof that the released model met its acceptance thresholds (the run summary), continuous evidence the line-side model still matches that release (the served-artifact-version field), and a telemetry trail dense enough to reconstruct any incident (the logged history). The rollback path depends on the same evidence. A rollback is only safe if you can name the version you are rolling back to and confirm the line-side service picked it up — both of which are logged fields, not tribal knowledge. Where these run logs feed the broader monitoring harness rather than sitting as an isolated dashboard is covered in how an experiment tracker feeds a production AI monitoring harness. FAQ What’s worth understanding about wandb.log first? wandb.log writes a dictionary of key–value pairs to the currently active run, opened with wandb.init(). Each call appends a row to the run’s append-only history, stamped with a step, and the platform reconstructs curves from that sequence. The keys are arbitrary strings you choose; the run — not the log call — carries the model identity and version evidence. What is the difference between logging a single step, logging with a step index, and logging summary metrics for a run? Logging without a step auto-increments an internal counter, which drifts apart when metrics are logged at different frequencies. Logging with an explicit step= pins each row to a number you control — in production, a batch ID or shift rather than a training iteration — so multiple metrics overlay correctly. Summary metrics (run.summary[...]) write one run-level value used to rank runs against each other, not a point in history. Which metrics should a line-side AOI model log through wandb.log — false-reject rate, escape rate, and input drift — beyond training accuracy? False-reject rate tracks good units wrongly flagged (the metric that erodes ROI), escape rate tracks real defects passed as good (the dangerous, harder-to-observe one), and input-distribution drift is the leading indicator that predicts both before they move. Training accuracy only confirms the model learned the pilot distribution; it says nothing about behaviour under a shifted conveyor or lighting environment. How do wandb runs and artifacts provide the version-pinning evidence that a deployed AOI model matches its released version? Registering trained weights as a versioned, hashed W&B Artifact gives an immutable reference, and the line-side service logs the artifact version it is actually serving alongside its telemetry. That logged field links the observed metrics to the exact model producing them, so the first diagnostic question — “is this even the released model?” — is answered by a field rather than an investigation. How do you use logged telemetry to detect and diagnose AOI drift from lighting, packaging, or conveyor variance in hours rather than days? When FRR, escape-rate proxy, input-drift score, and served-artifact version share one run and a production step index, a drift incident becomes a few overlaid curves you read in one sitting. Drift rising before FRR points at a new input (brightness shift = lighting, shape shift = packaging); a changed artifact version points at a bad deployment; both flat means a genuine defect spike. How does wandb.log fit into the validation pack and rollback path for a production AOI deployment? wandb.log is the mechanism that populates the validation evidence, not the validation itself: the run summary proves acceptance thresholds were met, the served-artifact-version field proves continuous release match, and the logged history supports incident reconstruction. The rollback path relies on the same logged fields to name the target version and confirm the line-side service picked it up. The question that decides whether any of this earns its keep is not “did we log the loss.” It is whether, given a false-reject spike on a night shift, an engineer can tell degradation from a bad deploy from a real defect surge before the line reverts to manual — and that answer is set the day you choose what wandb.log records, not the day the incident arrives.
