A rocket engine is covered in sensors. Each measures one physical quantity — a pressure, a temperature, a speed — many times per second. The resulting stream is telemetry, and each individual stream is a channel.

The standard safeguard is a redline: a fixed limit on each channel. If chamber pressure exceeds its redline, an alarm fires. Each channel is judged alone, against its own limit. This is simple, fast, trustworthy, and catches any fault severe enough to push one reading out of bounds.

It has one structural blind spot. Some failures never push a single channel past its limit. They appear as a small, coordinated shift across several channels — sometimes all at once, more often rippling from one to the next over seconds — vibration creeping up, a temperature trending warm, a pressure easing off — each comfortably inside its own redline, but together forming a pattern that does not belong. This is a coupled, sub-threshold fault: coupled because the evidence is spread across channels, sub-threshold because none crosses a limit.

A per-channel redline cannot catch this, and not by accident: it never compares channels to each other, so a fault existing only in the combination is invisible to it by construction.

Catching that class of fault is the entire purpose of this project.

If the fault lives in the relationship between channels, the detector must read the channels together rather than one at a time. That is the whole idea in one sentence.

The system learns what the engine's channels normally do together in a given situation, and flags departures from that joint pattern even when every channel stays within limits. It sits above the redline system as an advisory layer: the redlines keep all authority to act; this system only offers an earlier, subtler warning that something coordinated is drifting.

Everything that follows is the construction of that system, in two halves: first the data it learns from (Part II), then the model that learns (Part III).

To build and test a fault detector we need two things: examples of an engine running normally, and examples of it running with the exact faults we mean to catch. We have neither. No real engine telemetry is available, and deliberately breaking a real engine is not an option.

So we simulate. We write a generator: a program that models the engine's physics and produces telemetry — normal runs, and runs with faults injected on purpose. Because the generator authors every fault, it knows the ground truth about each one, which makes it the test oracle: the source of the right answers we score the detector against.

NoteThe generator is a physics model written as code — equations we run to produce plausible readings. It is not a language model inventing numbers. The values come from physical relationships, so the correlations between channels are consequences of the equations rather than decoration added by hand.

It is a reduced-order model: a simplified stand-in, not a validated simulation of a specific engine. The claim is only that its behavior is physically plausible and correctly coupled — enough to make the detection problem genuine. It sits behind a clean seam, so real telemetry could replace it later without changing anything above it.

Every run has the same simple shape: one-dimensional time series, all on the same clock.

• 1 command channel — throttle (Ch. 05).
• 8 sensor channels — the engine's response (Ch. 06).
• Sampling period: 10 ms (100 readings/second).
• Duration: 60 seconds — one full run, startup to shutdown.

60 s × 100 Hz = 6,000 timesteps. With 1 command + 8 sensors, a run is a 9 × 6,000 grid of numbers. Faulted runs carry one extra item: a label recording which fault was injected, on which channels, over which time window.

The label is never shown to the detector. It exists only to score the detector's answers (Ch. 08). That is the entire data format. The physics and couplings are not stored as extra fields — they live inside the shape of these ordinary time series.

An engine does not drift on its own; it is commanded. We simulate one command: throttle, the master thrust setting. This is a deliberate minimum. One command suffices because a throttle change legitimately moves many channels at once. That coordinated, expected motion is precisely what a fault can be mistaken for, and telling "expected response to a command" from "unexplained fault" is a hard problem in itself. Because throttle is the only command, anything else that might have been an order — such as mixture ratio — is instead a measured response, and lives on the sensor side.

The throttle follows a simple profile: a startup ramp, a steady hold, and a shutdown ramp.

"Steady" does not mean "flat."

At constant throttle, the fast mechanical and pressure channels settle to nearly level values, but the thermal channels do not: bearing and nozzle temperatures keep rising as heat accumulates. Normal behavior during the hold is therefore an expected trajectory — some channels level, others on a slow warming curve. The fault must be distinguished not from a static value but from that expected trajectory: a degrading bearing warms faster than the normal curve while staying under its redline. That is a departure from an expected path — exactly what a redline misses and a model of normal can catch.

The eight sensor channels are the engine's response to throttle: chamber pressure, turbopump speed, turbopump vibration, bearing temperature, nozzle/coolant temperature, coolant flow, feed-line pressure, and mixture ratio.

How each channel's model is derived

The same four-step recipe applies to every channel: name the governing principle (a conservation law or constitutive relation); pick the timescale; express its dependence on throttle and upstream channels (this is what creates the coupling); and inject faults as a perturbation to a single term in one equation.

The eight models

The physical chain runs: throttle → pump → feed → flow → thermal.

Why coupling is the whole point

The channels are not independent. Feed pressure is a function of pump speed; flow of feed pressure; both temperatures of upstream channels. So a perturbation anywhere ripples downstream on its own. Only three things must be right: the direction of each dependence, the relative magnitude, and the dynamics (instant vs. lagging). That is enough to make the coupled-fault problem genuine.

We have described the class of fault we are hunting. Now we must specify one, precisely — because a fault that is not defined cannot be injected, and a fault that is not injected cannot be detected.

The requirement

The fault has to satisfy three conditions simultaneously: coupled (it must move several channels), sub-threshold (no single channel may cross its redline), and detectable (the joint pattern must become clearly abnormal within the 60-second window). Condition 2 fights condition 3: push the fault harder and it trips a redline; soften it and it never becomes findable. The fault must live in the narrow band between those two failures.

The v1 fault: bearing degradation

We inject a single physical perturbation: progressive bearing wear, expressed as a slowly rising friction coefficient in the turbopump. We perturb one term in the bearing-temperature equation:

Everything that follows happens through the model's own couplings: bearing temperature rises, vibration grows, turbopump speed sags slightly, feed-line pressure and coolant flow ease with it. Five channels have moved. Not one has moved far. Every one stays comfortably inside its redline.

But the combination is impossible. In normal operation, at fixed throttle, bearing temperature does not climb while speed droops while vibration grows. It is a broken relationship — precisely what a model of normal, reading the channels together, can see.

The onset

The fault begins partway through the steady hold, where throttle is constant, and grows gradually. Onset rate is the parameter that must be tuned into the narrow band: too fast and a channel eventually crosses a redline; too slow and the deviation stays buried in sensor noise when the run ends.

There is no way to derive the right rate from first principles. It is set by generating candidate faults and checking two things directly: does every channel stay under its redline for the whole run, and does the joint deviation clear the noise floor before shutdown? The rate that satisfies both is the one we keep. (Open item 3.)

LimitationA v1 with a single fault type proves the thesis but does not prove generality. Until we test a second, structurally different fault, we will have shown the system detects this fault, not that it detects unfamiliar faults. That distinction matters and is easy to blur.

One run is never enough. "Normal" is a range, not a single trace. So the generator produces many normal runs (varying slightly, so the system learns normal as a distribution) and many faulted runs (differing in fault type, severity, and onset time).

The four splits

1. Training — normal runs only. The runs the model learns from. Nothing about quality can be judged here, because it has effectively been given the answers.

2. Validation — held out, but consulted repeatedly while building the model. Because we make decisions against it, we gradually tune ourselves toward it. Validation is honest but consumable.

3. Calibration — a separate set, held out from training. Used after training to rescale the model's confidence so it matches observed accuracy. Must be fitted on runs the model did not train on.

4. Test — runs the model has never seen, in any capacity. Touched once, at the very end, to produce the number we report.

Leakage destroys the instrument. If a test run appears in training, the model can score well simply by recognizing it. The test then measures memory rather than understanding, and reports a reassuring result that means nothing.

Keeping the splits disjoint requires more than good intent. In practice: no run appears in more than one split; random seeds differ so the generator cannot accidentally reproduce an assignment; fault signatures are not shared across splits; and the test split is committed before any result is seen. Violate any of these conditions and the score you report is not the one the system actually earned.

A channel's current value is not enough to judge it. What matters is its recent behavior: its level, whether it is trending, how fast, how noisy. Behavior exists only across time, so the model must look at a window — the last x readings of that channel. An encoder turns one such window into a short, fixed-size list of numbers called an embedding.

What one encoder actually sees

One encoder reads one window of one channel. Not the whole run; not all eight channels.

With a window of 100 samples compressed to an embedding of 16 numbers:

There are eight encoders, one per channel, run in parallel. The model slides the window along the run one position at a time, yielding a sequence of ~6,000 verdicts — not one summary. That is what lets us watch a fault develop. Whether those eight encoders share a single set of weights — one encoder applied to each channel in turn — or each has its own is left open; it is a design choice settled empirically in early testing, not a matter of principle. Either way the structure is identical; only the number of distinct weight sets differs.

The atom: weighted sum, bias, squash

Take the input numbers, multiply each by a weight, add them, add a bias. Then apply a squash (ReLU: if negative, output 0; otherwise pass through). Stacked weighted sums without a squash collapse back into a single straight line; the squash is what supplies the bend that lets the encoder represent curved, thresholded relationships.

Honest noteNobody proved that multiply-add-and-bend is the right primitive. It is simple, cheap, tunable — and when built up and trained, it turned out to work, repeatedly, across enormously varied problems. The tidy justifications came after the results. Trust the scoreboard, not the elegance of the story.

After encoding we have eight embeddings, one per channel. Each was produced by an encoder that saw only its own channel, so they know nothing about each other.

Here is the problem in one observation: whether a channel's behavior is normal usually depends on what the other channels are doing.

Bearing temperature is rising. Normal? Unanswerable alone. If pump speed just increased, it is ordinary. If pump speed is flat and throttle has not moved, the same rise is suspicious.

Identical bearing-temperature embedding; opposite meaning — decided entirely by the other channels.

A channel's meaning is relational, not self-contained. The mechanism that places each channel in the context of the others is attention (Ch. 11).

Each channel must draw information from the others that bear on it. The model needs a number for every pair — how much should channel A pull from channel B, right now? — that is data-dependent, asymmetric, and learned. Attention, built from the weighted sum of Ch. 09 plus a dot product, delivers exactly this.

Move 1 — Scoring

The dot product measures alignment. But relevance is not similarity: bearing-temp needs pump speed because speed explains its warming, yet the two are different quantities. Raw similarity would score exactly the pairing we most need low. And relevance is asymmetric — A may need B while B does not need A — which the symmetric dot product cannot express.

The fix: push each embedding through a learned weight matrix first — a different matrix for asking vs. offering — then compare:

Move 2 — Retrieving

Raw scores become proportions via softmax. A third learned matrix M₃ produces each channel's value — what it hands over if attended to. Each channel's updated embedding is then the weighted sum of everyone's values:

Before: eight isolated summaries. After: eight context-aware summaries, each having absorbed exactly what it needed. The three matrices (M₁, M₂, M₃) are shared across all eight channels — channels behave differently because their embeddings differ, not because each gets its own set.

Naming + honest noteAttention is the operation; a transformer is the architecture built around it. Our fusion layer is a small transformer over 8 channel-embeddings; an LLM is an enormous one over word-embeddings. Nobody derived attention from first principles. It satisfies the three requirements and turned out to work. Trust the scoreboard.

During a throttle ramp, many coupled channels move at once. The system sees correlated multi-channel motion and flags an anomaly — but nothing is wrong. This is the false-alarm trap: a commanded throttle change produces the same correlated multi-channel motion as a coupled fault.

The model must not ask "is this pattern unusual?" but "is this pattern unusual given the throttle history?"

Where the command enters — three options, two rejected

Option 1 — Throttle as a ninth channel. Give it an encoder like the others and let it sit in the set attention reads.

Rejected: this gives the command no structural priority. Throttle becomes one of nine items attention may weigh — and the model is free to weight it near zero. Nothing forces the sensors to be interpreted relative to the command; it is merely permitted. But command context is not one input among many, it is the frame the others are judged against. Making it a peer misrepresents its role.

Option 2 — Bake throttle into every encoder. Feed each sensor encoder its own channel and the throttle.

Rejected: this couples the encoders to command logic. An encoder does one clean job — summarize one channel. Mix command reasoning in and every encoder becomes partly a command-response model, impossible to tune or debug independently.

Option 3 — Handle it in the fusion layer. ← the choice

Keep the encoders pure sensor-summarizers. Let the fusion layer — where the channels are already being read together — also consult the command history.

Why this wins: "Does the throttle history explain what all these channels are doing?" is a question about the joint state, and the fusion layer is exactly where the joint state is assembled. The concern lives where it belongs; the encoders stay modular; command reasoning lives in one place.

The mechanism: cross-attention

Command awareness uses the identical machinery of Ch. 11, pointed at a different set:

Each channel asks "what in the recent throttle history explains what I am doing?" and pulls in whatever is relevant. Or it attends and finds nothing — throttle is flat, no part of it explains a bearing warming while speed droops.

That is the fault signal: not "the sensors moved," but "the sensors moved and the command history offers no account of it."

The command side must be a short sequence of recent throttle readings — not a single value — because the dynamic channels have time constants: bearing temperature is still warming from a ramp that finished seconds ago.

A real transformer block wraps three further pieces around attention. None is a new idea — each is repetition or elaboration of what you already have.

Multi-head attention

One set of matrices forces every channel into a single judgment about relevance. A channel may need several relationships at once — mechanical context and thermal context. The fix: run attention several times in parallel, with different matrices. Each is a head; their blends are concatenated and mixed by one more learned matrix.

The feed-forward network (FFN)

Attention moves information between channels; it does little processing of what it moves. So each block follows attention with a small FFN applied independently to each channel:

Residual connections, normalization, stacking

A residual connection adds the block's output to its input (output = input + block(input)), so each block learns a correction. Normalization keeps training stable. Stacking lets relationships compose. For eight channels, starting with one or two blocks is right.

Every component is built from two operations: the weighted sum and the dot product. Nothing else.

The encoder's weights start random, so the encoder starts useless. Learning is the process of tuning them, repeated over the normal training runs: predict (feed a slice through the model), measure the error (the loss function), assign blame (the gradient, computed by backpropagation), step (nudge every weight downhill by the learning rate), and repeat until the loss falls and levels off — this is called convergence.

Updates happen per batch, not per run. A batch is a small chunk of data; many batches fit inside one 6,000-step run. The weights are nudged many times within each run — a steady trickle of tiny adjustments, not one correction at the end.

Because the model only ever sees normal runs, the only way it can lower its loss is to internalize the real structure of normal operation. Shown a fault later, it predicts poorly — and that poor prediction is the signal.

Two ways to phrase the prediction

Forecasting: show timesteps 1–100, predict 101. Reconstruction: show 1–100, rebuild 1–100 through the embedding bottleneck. Both yield a residual; both work for anomaly detection. Which suits this problem is an empirical question. (Open item.)

Epochs: the same data, many times over

One full pass through the training data is an epoch, and training runs for many of them — tens, sometimes hundreds.

Why repeat? Because each update is deliberately tiny — that is what the learning rate is for. One pass nudges the weights a little way toward good values, nowhere near all the way.

But repetition is also precisely the pressure that tips into memorization (Ch. 15). So the number of epochs is not fixed in advance; it is watched. Train until held-out error stops improving and begins to creep upward, then stop. That moment is where learning-the-pattern turns into memorizing-the-sample. This is early stopping (Ch. 16).

The freeze is what makes detection possible. If weights kept updating on the data they were judging, the model would quietly learn the fault and the anomaly signal would vanish.

This is how essentially all modern AI is trained

An LLM learns by repeatedly predicting the next word of ordinary text — the text is its own answer key — using this identical loop. Ours predicts sensor readings; the normal telemetry is its own answer key. Both are self-supervised: the data supervises itself, with no hand-labeling.

The named machinery is shared everywhere: gradient descent (in practice stochastic gradient descent on random batches, often with a refined step rule called Adam) driven by backpropagation. It powers image recognition, speech, recommendation, protein folding, and fraud detection alike. Fraud detection is our closest cousin — it also learns normal and flags the outlier, applied to spending instead of an engine.

The learning algorithm is indifferent to how many channels there are. It learns relationships among a set of vectors; it does not know or care what they represent or how many there are. Everything domain-specific lives in how you turn your problem into a set of vectors — not in the learning itself.

Three differences from an LLM are worth holding: data (coupled physical time series, not text), scale (eight channels, not the internet), and — the important one — goal. An LLM is deployed for its good predictions. We train ours to predict normal well precisely so that its bad predictions become informative. For us, the errors are the product.

The training data is only a sample, standing in for the world. Every sample contains structure that predicts the target repeatably (real signal) and structure that predicts it accidentally. The model cannot tell them apart from training data alone — both reduce training error.

Overfitting is latching onto the accidental structure. The tell-tale sign: training error keeps falling while held-out error starts rising. Three independent cures:

• More data — a coincidence in run 12 is contradicted by runs 1–500.
• Less capacity — a smaller embedding leaves no room to store coincidences.
• Regularization — directly penalize complexity.

This is the project's deepest risk. Our fault lives in subtle cross-channel correlations. The danger is that the model latches onto a correlation that is real but incidental to our synthetic runs — an artifact of the generator. The question to keep asking: is this correlation a feature of engine physics, or a coincidence of this sample?

More training data helps — up to a point. The curve flattens once the model has seen the true variety of normal operation. Beyond that, adding runs does not improve detection, because the ceiling is set by the fault itself: it is deliberately sub-threshold, so no quantity of normal training data makes it obvious. More data shrinks variance; it cannot shrink the detection trade-off.

Training sets the parameters. It cannot set the hyperparameters — the choices that define the model before training starts.

Embedding size has a U shape: too small and the fault's subtle signature is compressed away; too large and the encoder memorizes training-run quirks; right-sized and the bottleneck forces distillation of signal from noise. Finding that band is a sweep, not a derivation.

After any search, automated or not, the test set is the only honest number left.

Early stopping: train until held-out error stops improving and starts creeping upward — then stop. That moment is where learning-the-pattern turns into memorizing-the-sample.

The honest approach is manual before automated. Vary one hyperparameter at a time, form a hypothesis, confirm or refute it, then move to the next. Manual search builds intuition and catches obvious mistakes before they compound. Automated search — grid, random, or Bayesian — covers more ground but creates a specific trap: run it long enough and you find not the best hyperparameters, but the ones that got lucky on the validation set. The callout above is the only real protection.

At inference the model predicts what each channel should be doing given the throttle and recent past. The gap between prediction and reality is the residual. On a normal run, residuals stay small. When a fault develops, the joint prediction degrades and residuals grow.

This catches the coupled fault because the model learned the normal relationships between channels, not merely their normal levels. A coupled fault breaks those relationships while each channel stays in range — so the residual is large because the joint pattern is wrong. Scoring happens after the combination, which is exactly what lets a single number reflect a pattern spread across channels.

To turn a score into a decision we draw a threshold, which forces an unavoidable trade-off: too low catches every fault but fires on normal runs; too high is quiet but misses subtle faults.

The system reports a confidence, and by default it is systematically overconfident: it will report 95% certainty where it is right only 70% of the time. For an advisory safety system that is unacceptable — an operator told "95% confident nothing is wrong" by a 70%-reliable system is being actively misled toward complacency.

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

The fix is post-hoc calibration: a small adjustment applied after training. The standard method is temperature scaling — divide the raw scores by a single learned number before converting to probabilities. It must be fitted on the calibration split — runs the model did not train on — because on its own training runs the model's errors are unrepresentatively small.

Calibration does not improve detection. It is monotonic — it does not reorder anything, so recall and false-alarm rate are unchanged; any threshold you could set before calibration you can still set after. What it changes is whether the number attached to a verdict can be trusted. For an advisory system, that is not optional. For this system, a score of 0.85 after calibration means the current engine state is more unusual than 85% of the normal states the model has seen, evaluated under similar commanded conditions — so a throttle ramp does not register as anomalous simply because it is rare.

The output is an anomaly flag, a confidence, and a short ranked list of the channels the model weighted most. Those channels are relevant, not causal. Where a fault originates and where it shows up are often different channels. The ranking comes from attention weights — and what a model attends to is not guaranteed to be what it truly relied on.

We hold this line strictly because overclaiming is how an advisory tool becomes dangerous: an operator who reads "bearing temperature caused this" may chase the wrong thing. Determining cause remains the engineer's job.

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

An unreadable verdict is not a partial success. It is ignored — and an ignored advisory system is exactly as valuable as no system at all.

There is a symmetry worth stating. This system exists because high-dimensional, correlated state is unreadable to a per-channel monitor. Hand a person eight channels, a score, and a set of attention weights and they face the same problem. The interface exists to do for the human what the fusion layer did for the data.

Three things must land, in descending order of how fast they must land: State (is anything wrong — legible before a single number is read, carried by color), Where (which channels carry the anomaly), and How sure (the calibrated confidence).

The verdict must point at metal

A ranked list of channel names is an abstraction. A glowing bearing on a picture of the engine is a location. The verdict is mapped back onto a spatial layout of the physical engine — a ring layout, channels arranged around the engine, the implicated ones brightening and drawing inward as a verdict forms. The evidence visibly assembles from several channels into one conclusion — the thesis itself made visible.

And it must show the contrast: the same drift run side by side with the conventional per-channel view, every individual limit sitting quiet while the orchestrator flags the combined signature. That is the entire claim of Ch. 01, demonstrated rather than asserted.

Honesty must be built into the design, not appended to it

Ch. 19 committed to a hard line: the ranked channels indicate relevance, not cause. That commitment is easy to honor in a document and easy to betray in an interface. An interface that displays "Bearing degradation — 87%" in large type has made a causal claim, whatever the footnote says. Presentation is a claim.

The design must convey, structurally and not parenthetically: these are the channels the model weighted, not the channels that failed; this is a starting point for investigation, not a diagnosis. If the interface cannot say those things while still being fast to read, then it is the interface that must be redesigned — not the honesty that must be relaxed.

Five constraints hold regardless of how the design evolves:

1. It must beat the baseline it claims to beat. The system must catch coupled, sub-threshold faults that per-channel redlines 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 commands and telemetry — labels stay out.
3. Attention indicates relevance, not cause — and the output says so.
4. The system advises; it does not act. Deterministic redline protection keeps all authority.
5. The verdict must be legible. An output a human cannot read under pressure is an output that will be ignored.