Case Study · 06
Manufacturing Reality Orchestrator.
A rocket factory runs on planning systems built for stable production — but a rocket line is not stable, and under the churn what the systems believe quietly drifts from what is true on the floor, invisibly on any single screen. This is a designed system that reads the four planning systems together, flags a schedule slip before it surfaces, and — from the same model — surfaces the likely cause of a cost problem no one had connected to it.
Interactive prototype
The orchestrator interface — factory floor & advisory dashboard
live 3D floor · ranked advisory · planned-vs-inferred schedule
The problem
Material planning software — MRP, and the ERP it lives in — was built for production that repeats. A refrigerator line runs the same design for years: the master data is stable because reality is stable, so what the system believes and what is true on the floor stay close together.
A rocket line is the opposite. The design is still maturing while units are being built — change orders keep landing, suppliers are still climbing their learning curve, processes are still being qualified, unit counts are low. Under that churn the master data drifts out from under reality constantly. Decoupling between belief and truth isn’t an edge case on this kind of line — it’s the normal condition.
And it is structurally hard to see. Each system is internally consistent with its own data, so nothing looks wrong from inside any one screen. The failure only becomes legible by reading several systems together, over time — which is exactly what no single planning screen is built to do. Not any one wrong value, but a disturbance that propagates across systems and surfaces far from where it started.
The system is positioned as an advisory layer over the existing planning stack. It computes nothing the planners rely on and has no authority over the schedule. It reads, and it flags — a starting point for a human to investigate, not a decision.
The approach
Two very different outputs from one model.
A single trained transformer reads the four systems as one multivariate sequence per stage — the dense operational streams (receipt timing and variance from Dynamics 365; dwell, cycle time and WIP from Opcenter) interleaved with the sparse discrete events (ECO releases from Teamcenter; requalifications from Epsilon3). From that one model come two outputs, useful in completely different ways — one looking forward, one looking backward.
Every system sits within its own acceptable window; nothing crosses a limit. Read together and in sequence, the same signature that drives the slip prediction also points at work-in-process building at a downstream cell that still reads nominal — cost surfacing where the cause isn’t.
A forward prediction — the learned part
Trained on the history of past stages, each labeled by what actually happened, the model learns that a particular joint early signature precedes a schedule slip: churn up, variance widening, dwell creeping, all at once, none alarming alone. The output is an early flag — this stage is developing the shape of stages that later slipped. Not demand forecasting; a schedule slip forecast from the factory’s own internal, cross-system operating signals.
A backward explanation — a by-product of the same model
Ask the model what its prediction rests on, using standard input attribution (SHAP and gradient methods — not raw attention weights). The attribution exposes the ECO-churn → supplier-variance → mill-dwell chain. No second model, no new machinery. And the same upstream signature driving the slip is the likely driver of the cost problem downstream — the mystery WIP at the healthy-looking cell. Two problems owned by two departments, surfaced as one root cause. That is the untangle.
A flag for human investigation — not an automated root-cause finder
The attribution reports importance, not causation. Run continuously, the model scores each stage, computes attributions on elevated predictions, requires a corroborating discrete event (an actual ECO release, an actual requal) before a flag reaches the queue, and emits a ranked queue of hypotheses: here is the risk, here is the upstream signature that appears to drive it, go look. It is judged by its hit rate, not by whether any single flag is true.
Design decisions
What I considered, and why I rejected it.
Not “which drift is the AI,” but “which work is learned.”
Forcing an “AI” label onto every part reads as overclaiming, because some of the work is deterministic — aligning a predicted slip with a co-moving cost effect is bookkeeping, not a model. The honest cut is by kind of work: the transformer does the learned prediction and its attribution; deterministic logic does the corroboration and the cost alignment. Keeping that line visible is what makes the whole thing credible.
Attribution, not “mechanistic interpretability.”
Mechanistic interpretability reverse-engineers a network’s internal circuits — a frontier area, and not what this does. This is attribution: which inputs drove a given output. It is mature and deployed, and it is stronger for not pretending to be something newer.
Prediction and explanation from one model, not two systems.
The explanation could have been a separate causal-inference system. It isn’t, deliberately: attribution is a by-product of the prediction, so one trained model yields both outputs — and keeps them honestly tied to the same learned signature rather than asserting a connection between two independent models.
A composed advisory surface, not a configurable tool.
The interface makes the call about what to show and how to rank it, rather than handing the user knobs to arrange it. The value is that the one view which makes the hidden thing legible has already been composed — decisive presentation, humble verdict.
Five commitments
- Beat the baseline it claims to beat. Catch cross-system, sub-threshold disturbances the per-system dashboards miss — on the same data.
- The data stays disjoint. Train / validation / calibration / test generated separately and kept apart; the test split touched once; labels never shown at inference.
- Attribution indicates importance, not cause — and the output says so.
- The system advises; it does not act. The existing planning stack keeps all authority over the schedule.
- The advisory must be legible — and honest. An output a human cannot read, or reads as a harder claim than it is, is worse than none.
Data & training
The churn that makes this painful is the same churn that makes it learnable.
The model needs history it can learn from: past stages, each represented as its full multivariate event history across the four systems, each labeled by what actually happened — did it slip, by how much, what downstream cost and WIP anomalies came with it. A stable line produces almost no decoupling events, so there is nothing to learn from. A line where design and process are constantly moving generates drift as its normal condition — which means it also generates the labeled examples the model trains on.
The honest gating risk, stated plainly: low unit counts mean few labeled slips. A realistic build pretrains on the abundant operational sequence data the systems already emit and fine-tunes on the scarce labeled outcomes. And earliness is only worth something if false positives are rare — precision on a data-poor line is the genuine engineering challenge here, and any version of this that hides that is selling something.
Because real training data of this kind isn’t available to a prototype, the demonstrable version runs on a synthetic scenario: a small model of the four systems’ streams with a disturbance injected at the root, so the propagation and its downstream surfacing emerge through the model’s own couplings rather than being drawn in by hand. The seam is kept clean — synthetic streams and a real feed present the same interface.
The interface
An advisory is only useful if a human can act on it — and trust it.
This system exists because a disturbance spread across four systems is unreadable to a per-system monitor. Hand a person four systems and a score and they face the same problem. The interface exists to do for the human what the model did for the data — and to keep the honest seams on the surface, not buried.
01
Two registers, stacked
The physical plant on top — ground truth — the ranked analysis below. Truth and interpretation, in one scroll.
02
Advisory, not verdict
A calibrated certainty carried as an advisory, never a hard call — the tone reflects a system with no authority over the schedule.
03
Systems, weighted
The four systems shown as tiles scaled by how much each drove the flag — it weighed everything; these are what mattered.
04
Implicated zones light on the floor
In two roles: the elements the inference reads from, and the element it infers is affected — drawn dashed, inferred rather than observed.
05
A ranked queue, in plain language
Each flagged event as an advisory, a description in the honest correlational voice, and a recommended place to look — not an instruction to reschedule.
06
The contrast, shown
Every system reads nominal while the advisory flags the combined, propagating signature — the thesis, demonstrated rather than asserted.
Roadmap & open problems
An idea worth building the next rung of.
- This design: four systems read as one sequence, a learned slip prediction, attribution as a hypothesis queue, corroboration by discrete events, on a synthetic scenario, advisory — through an interactive floor-and-dashboard interface.
- Next: harden against a richer library of disturbances, and tune the flag threshold against a real human-cost function — the point where an investigated flag pays off often enough to stay trusted.
- Then: learn the influence topology between systems, so a flag traces a path through the stack — churn to supplier to cell to downstream WIP — rather than a bag of weighted inputs.
The honest unknowns sit in the same territory:
- Correlational, not causal. Attribution points at what the model keyed on; turning that into a real cause is a human step.
- Precision on sparse labels. The whole value of earliness depends on a low false-positive rate, hardest to achieve on exactly the data-poor line where it matters most.
- Where trust sits. The advisory placement isn’t a limitation to engineer away — it reflects where trust in these methods actually stands.
Model
- PyTorch · attention over system streams
- SHAP / gradient attribution
- Calibrated confidence
Data
- Synthetic four-system generator
- Root disturbance injected
- Propagation emerges through couplings
Sources modeled
- Teamcenter (PLM) · Dynamics 365 (ERP/MRP)
- Opcenter (MES) · Epsilon3 (procedures)
- Dense streams + sparse events
Visualization
- Three.js factory floor
- Advisory HUD · attribution-weighted tiles
- Ranked advisory · planned-vs-inferred schedule
Artifacts