10. Requirements from Physics (Not Stacked Buffers)

By mid-morning Wednesday the structural load requirement carried three separate safety factors — one from the component lead, one from systems, one from operations. The rationale table had a row for the number and no row for what uncertainty each factor was covering.

No owner could say which was which. The factors had stacked over time, each defensible on its own, none traceable to a named risk.

The released design came out 6% heavier, material cost up, pilot-line yield down against the previous baseline.

That is unmanaged uncertainty in the requirement line, presented as conservatism with no one accountable for any single part of it.

Physics-first requirement logic

Start from a measured physical limit in the requirement record, then add an explicit program buffer with an owner.

Write each requirement as a three-layer decision object:

  1. Define physical limit (what nature allows under named conditions),
  2. Set engineering target (what design commits to hit),
  3. Declare program buffer (what uncertainty margin is carried, by whom, and why).

If those layers are merged into one opaque number, no decision owner can tune risk intelligently at gate review.

How stacked buffers happen

Buffer stacking usually starts with three good-intention moves:

  • component lead adds margin in the requirement for model uncertainty,
  • system lead adds margin for integration uncertainty in a downstream spec,
  • operations lead adds margin for process uncertainty in release criteria.

Each margin looks reasonable in isolation, but combined they can exceed the product's weight, cost, or manufacturability limits.

At an energy storage program, three teams each added a thermal margin to the switching-stage requirement. The thermal lead added 5 °C for component tolerance. The systems lead added 3 °C for ambient worst-case. The manufacturing lead added 2 °C for process variation. All three margins were honest engineering judgments. Combined, the requirement was 10 °C tighter than any single physical driver justified — and the chosen architecture could not satisfy it. When the teams traced each margin to its physical source and its uncertainty basis, 7 °C of the buffer was recoverable without increasing real risk. The requirement moved from unmeetable to achievable without changing the architecture — and a two-month design study for a thermal architecture change became unnecessary once the margins were untangled. The conversation that untangled the three margins took ninety minutes. Eight weeks of design study replaced by a traceability column.

Fake safety vs real safety

More margin in a requirement line is not automatically safer for the delivered product.

Unexamined margin in the requirement can:

  • push design into new failure modes (mass, thermal, packaging) during integration,
  • force expensive materials or processes in sourcing,
  • reduce manufacturability and yield on the pilot line,
  • hide which uncertainty actually needs test closure before gate sign-off.

Real safety is explicit risk control — named owner, named uncertainty, named evidence. What you have when you stack unexamined margin is a tighter number and no idea how much of it you actually need.

Buffer hygiene rule

Every requirement buffer must carry five explicit fields:

  • assign a named owner,
  • identify the uncertainty source it covers,
  • state a quantitative value,
  • define a specific expiration or review trigger (a named gate, a test result, or a date — not "as needed"),
  • link planned evidence that will reduce or confirm it.

If a buffer has no owner or retirement trigger, it persists by inertia and silently hardens into baseline policy.

You have watched this happen. The 2 °C process buffer from the first design phase is still in the requirement four builds later, and nobody can find the engineer who added it.

Quick variation coverage check

Before blessing a requirement ID, run this variation-coverage check:

  1. Which variables drive this limit most?
  2. What ranges are assumed for each variable?
  3. Which interactions matter?
  4. What evidence currently supports those ranges?
  5. Which assumptions are weakest and need targeted test/model work?

This review does not require advanced math in the meeting room; it requires explicit assumptions in the requirement record.

Writing a clean requirement line

Weak requirement line: "Part shall withstand expected thermal load with margin."

Better requirement line: "At condition set X/Y/Z, measured by method M, value shall be <= N. Program buffer B covers uncertainty U, is owned by O, and is reviewed at gate G."

The intent is the same, but the owner, uncertainty source, and gate review trigger are now explicit and auditable.

Field test: If you can name the physical source and the uncertainty basis for each buffer in your tightest requirement, the requirement is grounded. If you cannot, the margin is ungrounded — stacked buffers are the most common reason, but the consequence is the same regardless of cause: you do not know how much design margin you actually have.

They untangled the stack: each factor mapped to a named uncertainty, the recovered margin handed back, the design lighter again. Then the combined-load case came in worse than any single factor had predicted, and the clean one-at-a-time numbers could not say why.