A rocket factory runs on a stack of planning systems. A PLM system holds the evolving design. An ERP/MRP holds the plan — what is ordered, what is due, what the lead times are. An MES holds what the floor is actually doing. A procedures system holds which qualifications and requalifications run when. Each is a system of record: a database of what one part of the world is believed to be.

The standard way to watch such a stack is one screen at a time. Each system has its own dashboard, internally consistent with its own data, each value inside its own acceptable range. This is simple, fast, and it catches any problem severe enough to push one number out of bounds on one screen.

It has one structural blind spot. Some problems never push a single system's number out of range. They appear as a small, coordinated drift across several systems — engineering change orders running a little hot, a supplier's deliveries scattering a little wider, a machine's cycle time creeping up a few percent — each comfortably inside its own normal band, but together, and in sequence, forming a pattern that does not belong. This is a cross-system, sub-threshold disturbance: cross-system because the evidence is spread across systems that don't talk to each other, sub-threshold because nothing crosses a limit.

A per-system dashboard cannot catch this, and not by accident: it never compares systems to each other over time, so a disturbance that exists only in the combination is invisible to it by construction. Worse than a redline's blind spot, because there are four systems and the drift moves between them.

The failure is only legible when the four systems are read together, in sequence — which is exactly what no single planning screen is built to do.

Catching that class of disturbance — early, while every dashboard still reads green — is the entire purpose of this project. Everything that follows is the construction of a system that does it: first the plant and the data it learns from (Part II), then the model that learns (Part III), then how its output is made honest and usable (Part IV).

The idea is to add one advisory layer over the existing stack. It changes nothing the planners rely on and has no authority over the schedule. It reads the four systems together, over time, and does two things from a single trained model.

First, a forward output: a learned early flag that a stage is developing the shape of stages that later slipped — a schedule slip predicted from the factory's own internal, cross-system operating signals, before it surfaces on any dashboard (Ch. 12).

Second, a backward output: an explanation of what that prediction rests on, obtained by input attribution over the same model — the upstream signature that appears to drive the flag, offered as a candidate for a human to investigate (Ch. 13).

Two outputs, one model — one looking forward, one looking backward — and they come from the same place.

Two design commitments run through everything after this. The system is advisory: it surfaces hypotheses a human would not otherwise see; it does not make the call (Ch. 19). And its honesty is structural: which work is learned and which is deterministic bookkeeping, whether a signal is importance or cause — these distinctions are kept visible rather than blurred into one undifferentiated "AI" (Ch. 14, Ch. 19).

Two things are needed to build the detector: examples of normal operation across the four systems, and the exact cross-system disturbances we mean to catch, each labeled by what actually happened. Real production data of this kind, cleanly labeled, is not available to a prototype — so we simulate.

The generator is a small model of the four systems' streams. A disturbance is injected at the root, and the propagation and its downstream surfacing emerge through the model's own couplings rather than being drawn in by hand (Ch. 07).

NoteThe generator is a process model written as code — relationships between the four systems, run forward to produce plausible records. It is not a language model inventing numbers. The couplings between systems are consequences of the model's structure, not decoration added by hand — which is the whole reason a disturbance injected at one point can surface somewhere else on its own.

The seam is kept clean: synthetic streams and a real feed would present the model the same interface, so the concept can be shown honestly without claiming a trained result it does not have. The honest limits of leaning on synthetic data — that the model might learn a quirk of the generator rather than a real pattern — are stated plainly later (Ch. 15).

The stack modeled here mirrors a real orbital-manufacturing environment. Four systems, read together as one sequence, with two different kinds of signal in them.

The dense streams (D365, Opcenter) produce a value on a regular cadence — the predictive substrate. The sparse events (Teamcenter, Epsilon3) happen occasionally and irregularly — an ECO release, a requalification. They are not four of a kind, and the system does not treat them identically: the dense streams detect, the sparse events corroborate (Ch. 14).

The scheduling context — which procedures run when — lives in Epsilon3, a system the MRP never reads as a constraint.

One illustrative scenario runs through the whole book, so the abstract "cross-system disturbance" has a concrete shape. A flight-critical forging — an isogrid barrel section for a second stage — is early in its life: new design, a supplier still maturing the process, low unit count. Watch one disturbance move through the four systems, in order.

It starts in engineering. The barrel's design is still being resolved, so change orders on this part run above baseline. Teamcenter holds this as elevated ECO churn.

It reaches the supplier. Absorbing those changes, the supplier becomes less predictable — not yet late, but their delivery dates begin to scatter. Dynamics 365 records each receipt, and each one is within the acceptable window, so nothing flags.

It reaches the floor. At isogrid milling, the operator re-fixtures repeatedly to handle the incoming part variants, and cycle time drifts up a few percent. Opcenter holds this as creeping dwell.

Every one of these signals is individually unremarkable. None crosses a threshold. Every dashboard stays green.

That is the point. The disturbance is one thing in the physical world, scattered across four partial representations that don't talk to each other. It is only legible as a single thing when the four are read together and in sequence. And it is not done — it has not yet surfaced where it will actually be noticed (Ch. 06).

The disturbance surfaces somewhere else entirely. The cell fed by milling starves during the delays. To stay productive, it backfills with other committed jobs — and work-in-process quietly accumulates at a station that, looked at on its own, appears completely healthy.

Cost and disorder show up where the cause isn't.

This is the sharpest form of the problem, and the most valuable thing the system can surface. The slipping date and the cost anomaly are seen by different people, in different units — one owned by the program, one owned by finance — and nobody connects them. They are the same root cause. Collapsing two separately-investigated problems into one is the "untangle" the whole idea rests on (Ch. 13).

Why this is hardThe affected cell is not observably broken. Its own dashboard reads nominal. Nothing measured there is wrong; the claim that it is affected is an inference from the cross-system signature, not a reading off a gauge. Any honest presentation has to show it as inferred, not observed (Ch. 20).

To learn from this class of disturbance, we have to be able to produce it — many times, with variation, each time knowing the truth. The generator models the four systems' streams and the couplings between them, then injects one disturbance at the root (the ECO churn) and lets it propagate.

This matters for honesty. The money-shot — cost surfacing at a healthy-looking cell — is not drawn in stage by stage. It emerges because the generator's structure carries one injected cause forward. Perturb the root; the shape appears downstream on its own.

The clean seamSynthetic streams and a real feed present the model the same interface. Nothing in the model "knows" the streams are simulated. That is what lets the concept be demonstrated honestly on a synthetic scenario without claiming a trained result on real data (Ch. 15).

The unit the model learns from is a stage: one part moving through the line, represented as its full multivariate event history across the four systems. Each stage carries a label recording what actually happened — did it slip, by how much, and what downstream cost and WIP anomalies came with it.

The label is never shown to the model. It exists only to grade the model's answers. At inference, the model sees only the four systems' signals — the outcome stays out.

Stages are partitioned into non-overlapping splits — training, validation, calibration, and test — generated separately and kept apart, so that no stage used to fit the model is ever used to judge it. The calibration split earns its own keep later, making the confidence honest (Ch. 18); the test split is touched once.

Everything the model knows about a disturbance lives inside the shape of these four ordinary system streams. Nothing is stored as a hint.

The model reads the four systems as a single multivariate sequence per stage. "Multivariate" means each step in time is not one number but a vector of many measurements. "Sequence" means the order and timing carry meaning — the disturbance is defined by churn now relating to variance weeks later relating to dwell after that.

The hard part is that the four systems speak in two registers. The dense operational streams (receipt timing and variance from D365; dwell, cycle time and WIP from Opcenter) arrive on a regular cadence. The sparse discrete events (ECO releases from Teamcenter; procedure and requalification events from Epsilon3) arrive irregularly — a spike on a timeline, not a stream.

Getting regular streams and irregular events into one aligned sequence a single model can read — dense interleaved with sparse — is a real modeling problem, and it is where the two kinds of system are first brought together rather than watched apart.

A single system's reading is not meaningful in isolation. Supplier delivery scattering a little is unremarkable on its own — suppliers vary. Cycle time creeping up a few percent is unremarkable on its own — floors drift. Elevated change-order churn is unremarkable on its own — new designs churn.

The signal is the conjunction, in order: churn up, then variance widening, then dwell creeping, then WIP surfacing downstream — the same disturbance seen four times, from four partial vantage points, none alarming alone.

The disturbance's meaning is relational, not self-contained. It exists only in how the systems move together.

This is precisely why a per-system dashboard cannot catch it (Ch. 01) and why the systems must be read jointly. The mechanism that reads them jointly — letting each system's signal be placed in the context of the others — is attention (Ch. 11).

Attention is the operation that lets each element of a sequence weigh its relationship to every other element — near or far, and by an amount the model learns rather than fixes in advance. For this problem it is exactly the right primitive: the relevant relationships are between systems and across weeks, and which ones matter is not known ahead of time.

Applied here, attention lets the model ask, for any moment, how much should the milling signal be read in light of the supplier signal three weeks earlier, and the ECO churn before that? — and answer with a weight computed from the data itself.

NamingAttention is the operation; a transformer is the architecture built around it. The model here is a transformer over the four systems' interleaved sequence. Nobody derived attention from first principles — it satisfies what this problem needs and, built up and trained, it works across enormously varied sequence problems. Trust the scoreboard, not the elegance of the story.

The forward output is the learned part. Trained on the history of past stages — each labeled by what actually happened to it — the transformer 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.

It reads as a probability of a future slip — not a fact, and not an alarm that a limit was crossed.

It is worth being precise about what this is not. It is not demand forecasting — the mature, crowded thing most people mean by "AI in MRP." It forecasts a schedule slip from a factory's own internal, cross-system operating signals. That is a much less trodden claim, and it is the one this project is actually about.

The prediction's honest weak point is stated where it belongs: earliness is only worth something if false positives are rare, and rarity is hardest to achieve on exactly the data-poor line where this matters most (Ch. 16).

The backward output is a by-product of the same model. Ask the model what its slip prediction rests on — using standard input attribution, the well-understood family of methods (SHAP and gradient-based attribution). The attribution exposes that the prediction is driven by the ECO-churn → supplier-variance → mill-dwell chain. No second model, no new machinery: the explanation falls out of the prediction already trained.

The right, honest nameThis is attribution — which inputs drove a given output — not "mechanistic interpretability," which reverse-engineers a network's internal circuits and is a different, frontier thing. And it is not raw attention weights, a known-unreliable explainer. Attribution is mature and deployed; using the accurate name is stronger than reaching for a newer-sounding one.

Here the two outputs meet. The same upstream signature driving the slip prediction is also the likely driver of the cost problem downstream — the mystery WIP at the healthy-looking cell (Ch. 06). The model surfaces that the slipping date and the cost anomaly are one root cause. That is the untangle.

Attribution reports importance, not causation. It is a candidate for a human to investigate — the honest hard line drawn in Ch. 19.

One move makes the whole thing materially more deployable, and it is where the two sparse systems earn their place. A flag riding only on dense-stream drift — variance and dwell creeping — is weaker than one that also lines up with a discrete event: an actual ECO release in Teamcenter, an actual requalification in Epsilon3.

Requiring that corroboration before a flag reaches the queue raises the hit rate without retraining anything. It is deterministic bookkeeping layered on the learned prediction.

Which work is learnedThis is the honest cut the project is organized around: the transformer does the learned prediction and its attribution; deterministic logic does the corroboration and the cost alignment. Forcing an "AI" label onto the bookkeeping would be overclaiming. Keeping the line visible is what makes the whole thing credible.

The churn that makes this problem painful is the same churn that makes it learnable. A stable line produces almost no decoupling events — 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.

Training adjusts the model's parameters to reduce error against the labels, one small step at a time, over many passes — and stops when held-out error stops improving and begins to creep upward. That moment is where learning-the-pattern turns into memorizing-the-sample.

The deepest riskBecause the demonstrable version runs on synthetic streams (Ch. 07), the model could latch onto a quirk of the generator — a correlation real in the simulation but incidental to the world. It would look like signal in training and evaporate on a real feed. Guarding against that — disjoint splits, a test set touched once, eventually a second structurally different disturbance — is the discipline the whole result depends on.

Here is the honest gating risk, stated plainly: low unit counts mean few labeled slips. A from-scratch model trained only on a handful of slipped stages is unlikely to work.

A realistic build pretrains on the abundant operational sequence data the systems already emit — the dense streams pour out constantly, labeled or not — and fine-tunes on the scarce labeled outcomes. The abundant data teaches the model what the plant's streams normally look like; the scarce labels teach it which shapes precede trouble.

Precision on a data-poor line is the genuine engineering challenge here, and any version of this that hides that is selling something.

And earliness is only worth something if false positives are rare. A model that flags a slip every other week is worse than useless on a real floor — it gets ignored, and an ignored advisory is worth nothing (Ch. 17). The whole value of the forward output depends on a low false-positive rate, achieved on exactly the data where it is hardest.

Run continuously, the two outputs become one specific, buildable thing. The model scores each stage on a schedule, computes attributions on any elevated prediction, filters by corroborating discrete events (Ch. 14), and emits a ranked queue of hypotheses: here is the risk, here is the upstream signature that appears to drive it, go look.

Standing this loop up is routine engineering. The difficulty is not the plumbing; it is keeping the queue worth a human's time. Because attribution surfaces whatever the model keyed on, it will sometimes key on a coincidence. Automating means generating candidate causes at volume — and most candidate causes are wrong.

So the honest deliverable is not "the AI finds the root cause." It is a hypothesis-generation system for human investigators, judged by its hit rate — how often a flag, once investigated, pays off — not by whether any single flag is true.

A queue that mostly wastes an investigator's time gets ignored — and an ignored advisory system is exactly as valuable as no system at all.

The forward output states a confidence. That number has to mean something. Calibration is the property that it does: of all the stages the system flags at 64%, roughly 64% should actually slip.

Of all the moments where the system says 64%, it should be right about 64% of the time.

It is enforced by a post-training rescaling fit on the held-apart calibration split (Ch. 08) — a standard step (temperature scaling) that does not change which stages rank as riskier, only what the numbers claim.

Where scrutiny landsCalibration is earned on data and verified — and this is a line where labeled slips are scarce (Ch. 16), which is exactly the regime where calibration is hardest. Stating a calibrated confidence is a commitment, not a decoration; it is the number a careful reader will test first.

Two hard lines hold, and the output must state them rather than footnote them.

Importance, not cause. The attribution reports which inputs the prediction leaned on. The step from "the model keyed on the ECO-churn signature" to "the design churn is what's driving the slip and the cost" is an inference the attribution enables, and a human confirms. What the model produces is a strong candidate connection — correlational, not proven.

Advisory, not authority. The system flags for a human; it computes nothing the planners rely on and has no authority over the schedule. The advisory placement is not a limitation to engineer away — it reflects where trust in these methods actually stands.

The system is worth building to surface hypotheses a human wouldn't otherwise see — not to make the call for them.

This chapter adds no model, and it is still necessary — because the purpose is to get a human looking at the right place earlier than a dashboard would, and that fails entirely if the human cannot read the output.

There is a symmetry worth stating. 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.

It is one scrolling view with two registers stacked. On top, a live 3D model of the plant — the physical floor, the ground the systems only describe — with a compact inference layer over it: an advisory (never a verdict) carrying the calibrated certainty, the four systems as tiles scaled by how much each drove the flag, and the implicated zones lit in two roles — the elements the inference reads from, and the element it infers is affected, drawn as inferred rather than observed. Below, the analysis: a ranked queue of flagged events; for the selected one, the advisory in a sentence, a plain-language description in the honest correlational voice, and a recommended place to look; then the four sources by attribution weight, the affected cell against an explicitly calm remainder, and a planned-versus-inferred schedule.

Presentation is a claim. An interface that shows "SN-9 — 64%" in large type has asserted a cause, whatever the footnote says.

So the honest seams are built in, not appended: two outputs kept visually distinct (forward flag versus backward attribution), learned kept distinct from deterministic, importance from causation, inferred from observed. It must also show the contrast — every individual system reading nominal while the advisory flags the combined, propagating signature. That is the claim of Ch. 01, demonstrated rather than asserted.

Five constraints hold regardless of how the design evolves:

1. It must beat the baseline it claims to beat. The system must catch cross-system, sub-threshold disturbances that per-system dashboards miss — on the same data.
2. The data stays disjoint. Training, validation, calibration, and test splits are generated separately and kept apart. The test split is touched once. At inference, the model sees only the systems' signals — labels stay out.
3. Attribution indicates importance, not cause — and the output says so.
4. The system advises; it does not act. The existing planning stack keeps all authority over the schedule.
5. The advisory must be legible — and honest. An output a human cannot read, or reads as a harder claim than it is, will be ignored or will mislead. Legibility and honesty are one requirement.