11. Many Factors, One Honest Limit

Wednesday, 2:35 p.m., the integrated test chamber still cycling in the next room, the subsystem verification report green on single-factor tests while the combined-condition run fails the requirement boundary.

The subsystem passes every single-factor check in the verification report.

The verification team tested variables one at a time and never ran the combined condition envelope that exists in the real product.

That test-plan gap burns schedule without reducing uncertainty enough for the gate decision owner to choose.

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 artifact:

  1. Name the decision to support,
  2. cite the impacted requirement,
  3. define factors and ranges to study,
  4. specify output needed (limit, window, or pass/fail region),
  5. set confidence/evidence threshold,
  6. 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, predicted peak temperature within a few degrees of measured across the operating range.

  • Old process: fixed interface assumption in the thermal model; mechanical contact validated at room temperature only.
  • Artifact changed: a coupled model treating contact pressure as a temperature-dependent input to the thermal boundary condition.
  • Measured improvement: prediction error reduced from a consistent overshoot of roughly one temperature class to within a few degrees at full load.
  • Cost of the gap: a handful of controlled builds and model cycles; 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.