The Build-Up Matrix Is the One Section of a Flight Test Plan You Can't Fake
Every flight test plan has a build-up matrix. Or should.
It's the section that says: here are the test points, in the order we'll fly them, starting somewhere we understand and ending at the target. Weight, CG, speed, configuration — each row incrementing one variable at a time toward the condition that answers the requirement.
The build-up matrix is often the last thing written and the first thing skimmed. That's backwards. The matrix is what turns a plan from a description of what you want to do into a program a test pilot can fly.
Six rules I apply to every build-up matrix before the plan goes to TRR.
What the Matrix Actually Does
Every flight test point involves an article, a crew, and a set of conditions. If more than one of those is unfamiliar, you're not testing — you're guessing.
Build-up is how you keep only one variable unfamiliar at each point.
The first row is a condition you have prior data for — from a ground rig, a component test, or a previous flight in a similar configuration. When you fly it, you're verifying that the article and crew behave as predicted at a condition you understand.
The last row is the target — the condition the requirement is defined at. By the time you get there, you've walked through intermediate rows that let you build confidence and catch surprises early.
In between are the rows that carry the work. Each one is a step. Each step gives you data. Each data point either confirms your model or breaks it.
1. The First Point Is Below the Target
Not at the target. Below.
If the target is 40,000 lb / 120 KCAS, the first point isn't 40,000 / 120. It's 36,000 / 80 — a condition where the article's response is either known from prior data or benign enough that a surprise is recoverable.
Plans that put the target in row 1 to "save flights" tend to end up flying more, not fewer. The first point produces a surprise that requires investigation before anything else can happen.
2. Each Step Is a Decision, Not a Checkpoint
After every point, the crew and engineers decide whether to proceed to the next point. The decision is based on data — did the point match prediction? — not on the schedule.
If a point doesn't match prediction, you have two options: understand why, or stop. What you don't do is press on because the flight has more runway.
Building this into the plan means writing "review point X data with test engineer and system engineer before proceeding to point X+1" as an explicit line. Not "if time permits" — as a gate.
3. Isolate What You're Expanding
If the goal is to expand into higher energy, hold weight and CG constant. If the goal is to expand into a wider CG range, hold energy.
One variable per step. Any surprise at the next point gets attributed to that one variable. Change two things and you're back to guessing which one caused the response.
In practice this is harder than it sounds. Weight decreases during flight. Fuel state affects CG. Environmental conditions drift. Discipline means designing the matrix so the variable of interest is the largest contributor between rows, and the rest are held as constant as physics allows.
4. Abort Triggers Are Point-Specific, Not Just Plan-Level
Every FTP has plan-level abort criteria — crew calls abort, system anomaly triggers abort, weather goes out of limits. Those apply to every point.
But each point can add its own. A brake temperature threshold that applies to the high-energy stop but not the low-energy one. A wheel-speed lockup threshold that applies to the max-braking point. A pitch-authority limit that applies to the aft-CG point.
Writing these per-point triggers explicitly is what lets the crew know, before they enter the point, what they're watching for beyond the standard abort list. Without it, in-flight abort calls are made from memory instead of the plan.
5. Between-Point Data Review Is a Hard Gate
Between every point, the previous point's data must be reviewed and compared to prediction. If it matches, proceed. If it doesn't match, you either understand why — and update the prediction for the next point — or you stop.
This is where telemetry earns its cost. Real-time data lets the ground engineer confirm the point closed as expected before the aircraft is set up for the next one. Without telemetry, the review moves to post-flight, and the next point flies on pilot report alone.
Programs that skip between-point review usually do so because they're behind schedule. Programs that don't skip it usually finish faster overall, because they catch small issues before they become large ones.
6. Safety Support Is Set for the Highest-Risk Point
Chase aircraft, telemetry monitoring, emergency response, medical standby, runway margin — these are planned once, at TRR, based on the peak risk of the plan.
You don't downshift them mid-campaign because the low-energy point went well. And you don't upgrade them mid-campaign because the high-energy point turned out riskier than predicted — by then, it's too late.
Set the envelope of support to the hardest point in the matrix. Every point flies inside that envelope.
What the Matrix Tells a Reviewer
At review, the build-up matrix is one of the first sections a technical reviewer opens. Three questions they ask:
- Where does the matrix start relative to the target? Below? At the target?
- What variable increments between each pair of rows? Is it one, or is it three?
- Where is the review gate written? Is it a real line in the plan, or a hope?
If the matrix answers all three cleanly, the plan reads as flyable. If it doesn't, the reviewer has homework for the author, and the plan comes back.
Where Programs Get This Wrong
Two failure modes.
The matrix is compiled after the procedure is written. Someone wrote the general procedure section first, then filled in a matrix of "conditions we want" as an afterthought. The result lists targets, not a build-up. Fix: write the matrix first. Then write the procedure to serve the matrix.
The matrix collapses when weather doesn't cooperate. The plan assumed a specific temperature, wind, or visibility band. When conditions don't match, someone makes a judgment call about whether to fly anyway, and the build-up gets compressed. Fix: write the plan for the conditions you have most of the time. If the target requires a corner case, that corner case is its own test window with its own weather brief.
The FTP template I use includes a build-up matrix format with weight/CG/speed columns and a between-point review gate written into the procedure. It ships with the Test & Validation Essentials Bundle.
Get the Test & Validation Essentials Bundle → https://solriseengineering.gumroad.com/l/tier1-testvalidationessential