11. Many Factors, One Honest Limit

The subsystem passed every single-factor check in the verification report. On paper it was green.

Then the combined-condition run — every variable loaded at once, the way the real product sees them — failed the requirement boundary. The team had tested one factor at a time and never run the combined envelope.

By Wednesday afternoon the gate owner had a stack of passing single-factor data and no basis to choose. The test plan had burned schedule without lowering the uncertainty that actually mattered.

When one-factor reasoning breaks

One-factor testing is useful during early screening. It fails when interaction effects dominate the decision boundary.

Use these trigger signs to decide when one-factor logic has broken:

integration repeatedly reveals failures not predicted by subsystem tests,
build-to-build results diverge without a single dominant cause,
response is highly sensitive near operating boundaries,
multiple coupled assumptions sit inside one requirement decision.

EMI is a common example: you can model the source with good accuracy, but coupling to other structures depends on layout, ground return paths, and shield geometry all at once. Shielding effectiveness calculated for a single source is only useful if you have correctly identified every significant source. Early testing with physical hardware can locate the coupling paths that single-domain analysis missed; catching that late means architectural changes after routing and mechanical design are fixed.

If any of these signs are present, additional one-factor testing usually burns time without reducing uncertainty enough to support a real decision.

Lead's job: scope the decision question

The lead does not need to run the analysis personally. The lead must scope a decision-ready ask with a named owner and due date.

Use this minimum ask format for the analysis request:

Name the decision to support,
cite the impacted requirement,
define factors and ranges to study,
specify output needed (limit, window, or pass/fail region),
set confidence/evidence threshold,
assign date and owner.

Without this framing, teams can generate impressive activity artifacts that still produce no bounded conclusion for the decision log.

A heat-generating module was mounted to a cooling structure. The thermal model predicted it would stay within its limit at full operating load. Three early prototype builds ran consistently hotter than predicted — not scattered results, the same gap every time.

The root cause was in what neither model was told to talk to the other about. At room temperature, the mounting assembly held good contact pressure across the thermal interface. At operating temperature, differential expansion between the module and the frame reduced that pressure at the interface edges. Lower pressure meant less effective contact. Less effective contact meant higher thermal resistance than the thermal model had assumed as a fixed input. Higher resistance meant higher temperature — which drove more expansion — a feedback loop no single-domain model could see.

Each model was valid given its own boundary conditions. The thermal model used a room-temperature interface measurement. The mechanical model validated contact at room temperature only. Neither was wrong. The interaction between them was the missing factor.

Fix: simplified geometry prototypes with one variable controlled at a time, each modeled to match before adding the next. The coupled model, validated against those steps, reduced prediction error from a consistent overshoot of roughly one temperature class to within a few degrees at full load. The same discovery post-tooling would have required a geometry change to the mounting architecture.

Rejecting activity theater

Reject analysis summaries that report:

"we tested a lot" without decision mapping,
"model looks good overall" without requirement impact,
"results are mixed, more work needed" without closure criteria,

because none of those statements names a decision owner, requirement artifact, or closure trigger.

Accept analysis packages that answer:

what changed in the decision baseline (the program's current standing commitments),
what uncertainty remains and who owns it,
what risk moved in the register,
what next decision date is now justified.

What "honest limit" means

An honest limit is not the most conservative number anyone can defend. It is the best current boundary supported by evidence, explicit assumptions, and named risk ownership.

Document the honest-limit package with four fields:

define tested or modeled domain,
state interpolation or extrapolation assumptions,
report confidence bounds,
list known blind spots.

This keeps confidence proportional to evidence when the gate chair reviews the limit decision.

Tie outputs to program controls

Analysis results are only useful if they propagate into program artifacts:

update the requirement value or buffer basis,
update the risk register entry,
update the one-page status delta,
feed the next gate decision packet.

If outputs stay in a technical slide deck, no program control artifact changes and behavior stays the same.

Thin bench approach

If the team lacks depth in multi-factor analysis:

borrow specialist support for method execution,
keep the decision question narrow and dated,
require output in program language, not only specialist language.

Lead responsibility remains: the lead still owns the decision question, artifact quality bar, and closure date.

Field test: name the analysis your program is waiting on right now. Does the request include the decision it is meant to support, the factors and ranges to study, and the date the decision is needed? If not, the analyst is guessing what matters — and the result will not close the decision, only inform it.

You can set the honest limit and still lose it. If a model run or a test cannot show what changed from the last baseline, it produced data, not a decision — and the limit you just fought for erodes one unacted-on result at a time.