Plant-to-Plant Transfer: Building Once, Deploying Across the Network

"We already built this for Plant A — just point it at Plant B" is the sentence that starts almost every plant-to-plant transfer project we've been brought in on, and it's almost never true in the way it's said. What usually exists is a model tuned to Plant A's tag naming, sensor placement, maintenance logging habits, and mix of equipment ages — excellent at one plant, untested at the thing that actually makes it valuable, which is generalizing. Pointing it at Plant B doesn't produce a working system with a few tweaks. It produces a debugging project that looks, from the outside, like it should have been a configuration change, and that mismatch is where transfer efforts usually lose their sponsors.

Why the naive version fails, specifically

The failure isn't that the underlying pattern doesn't hold across plants. Bearing degradation genuinely does look similar across two lines running similar equipment, and demand volatility genuinely does share structure across plants in the same network. The failure sits upstream of the model, in everything it was quietly built to assume. Plant A's vibration sensors might be mounted at a slightly different point on the gearbox than Plant B's, shifting the frequency signature the model learned to recognize. Plant A's SCADA historian might tag "line speed" as one thing and Plant B's as something similar but differently scaled or sampled. Plant A's maintenance team might log a bearing replacement as a work-order category the model treats as ground truth; Plant B's team might log the same event three different ways depending on who's on shift. None of this is a modeling problem — it's a set of assumptions the first build made implicitly, because implicit assumptions are the fastest way to ship a working pilot, and every one becomes a landmine the moment the model meets a plant that doesn't share them.

What transferable actually requires, built in from the start

The plants where transfer has genuinely worked for us share a specific discipline, and it starts well before the second plant is in scope.

A canonical data layer that plants map into, rather than a model that reads each plant's raw tags directly. If the model consumes "gearbox_vibration_rms" as a defined quantity in a shared ontology, and each plant's integration layer maps its own historian tags into that definition, adding a plant becomes an integration task — build the mapping, validate it — instead of a modeling task. Read Plant A's raw tags directly instead, and every new plant requires touching the model itself: a one-off with extra steps. This is the highest-leverage decision in the whole effort, and it has to be made before Plant A's build finishes, not discovered when Plant B's kickoff reveals the model can't read anything.

Feature definitions that are explicit about what's plant-invariant and what isn't. Some features genuinely transfer as-is — a frequency-domain signature of bearing wear behaves similarly regardless of which plant the bearing is in. Others need to be defined relative to the plant, not as an absolute value: a vibration reading that's alarming on a new gearbox is routine on a ten-year-old one, so the model needs "deviation from baseline," not "raw amplitude," or it will cry wolf at one plant and miss real degradation at the other. Getting this right, feature by feature, is the actual engineering work of transfer — far more of it than tuning the model architecture.

A validation protocol for the new site that doesn't assume the old site's ground truth. The tightest trap in transfer is validating the new deployment against the metric that made the first one look good, without checking whether that metric means the same thing at the new site — a false-positive rate that looked great at Plant A can look great at Plant B for the wrong reason, if Plant B's maintenance team simply logs fewer actual failures. Real validation means re-establishing ground truth at the new site independently, not assuming the first site's validation carries over.

An explicit decision, per feature and per plant, about accommodate versus standardize. Every plant has real, defensible quirks — a different equipment vendor, a different shift structure, a genuinely different failure profile. Not every quirk deserves a special case in the model. Organizations that scale well have someone with the authority to say "this difference is real" versus "this is just how this plant happens to log things, and we're asking them to log it consistently instead." Without that authority, every quirk gets absorbed into the model, and the system meant to be one thing slowly becomes six barely-related systems sharing a repository.

The organizational cost nobody prices in

All four disciplines cost something beyond engineering time: they slow down the first plant. None is necessary to get Plant A's pilot working fast, and all are necessary to get Plant B, C, and D working without a rebuild — a real trade-off, not a free upgrade. The pilot built for transfer looks less impressive in its first quarterly review than the one that wasn't. Plants that scale are the ones whose sponsors accepted a less flashy first plant for a network that actually compounds; the ones where transfer stalls usually optimized entirely for that first review, then discovered — expensively, plant by plant — that build-once-deploy-across-the-network was never what got built.