10. Requirements from Physics (Not Stacked Buffers)

Wednesday, 11:15 a.m., people already trading rumors about who pulls the weekend build, the structural load requirement carries three stacked safety factors while the latest build misses weight and yield targets.

The structural load requirement now includes three separate safety factors added by component, system, and operations leads.

No named owner can show which uncertainty each factor covers in the requirement rationale table.

The released design is 6% heavier, material cost is up, and pilot-line yield is down versus the previous baseline.

This is unmanaged uncertainty in the requirement line, presented as conservatism without traceable ownership.

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.

  • Old process: each team adds a margin independently, with no shared traceability column linking each buffer to a named physical source.
  • Artifact changed: a margin-breakdown table in the requirement record, with each additive buffer attributed to a named physical source and an uncertainty basis.
  • Measured improvement: 7 °C of recoverable margin found; program architecture unchanged.
  • Cost of the gap: the program had been holding a two-month design study for a thermal architecture change that became unnecessary once the margins were untangled.

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 comes from explicit risk control in the requirement and risk register, not from accumulating hidden margin.

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.

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.

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.