9. Requirements Lifecycle (Hypothesis -> Bless -> Evidence -> Revise)

Wednesday, 6:50 a.m., lab hallway quiet, the thermal verification log shows the board thermal limit set to 65 °C while the full-load chamber test at 40 °C ambient shows the control board measuring above 70 °C.

The program ran thermal management work — redesigning airflow, shifting components, iterating the layout — trying to bring the board temperature below the limit.

The requirement had a value and an owner. It did not have a scope note naming which operating scenario it applied to, or a rationale connecting the limit to actual component requirements.

Three weeks of committed design work against a requirement whose basis had never been confirmed.

Requirements are managed hypotheses

A requirement starts as a controlled hypothesis in the requirement log: this value must hold for a named operating condition. Both the value and the operating condition are part of the hypothesis. Changing the understanding of the bounding scenario — what worst-case actually looks like in field deployment — is itself a revision trigger, not only a measurement that crosses a threshold.

The requirement hypothesis becomes decision-ready through:

1. stating assumptions in the requirement record,
2. attaching bounded evidence to the same requirement ID,
3. recording controlled revisions with rationale,
4. assigning clear approval authority for each revision.

Treating early requirement values as permanent truth creates fake certainty and expensive rework once evidence arrives.

Lifecycle states (practical model)

Track each requirement ID through four lifecycle states:

• Hypothesis: initial value, assumptions explicit, low confidence.
• Bless: approved for current program phase with stated confidence/risk.
• Evidence: test/model/supplier data collected against requirement.
• Revise: requirement updated (or reaffirmed) with rationale and impact.

Each state requires an explicit move condition: Hypothesis advances to Bless on a named authority sign-off with stated confidence for the current phase. Bless advances to Evidence when the first data record is attached to the requirement ID. Evidence advances to Revise when data crosses a predeclared threshold or operating conditions change materially. Revise re-enters Bless once the revision record is complete — old value, new value, evidence source, rationale, approver, and date.

The requirement owner repeats this loop after each evidence update, gate review, or operating-condition change.

This loop makes changes legible in the log and mandatory for every downstream decision that consumes the value.

Frozen-but-wrong is worse than revised-with-evidence

Leads rightly fear uncontrolled churn in the requirement baseline. The opposite failure is also common: freezing wrong values in the requirement register to protect schedule optics.

A frozen-but-wrong requirement baseline causes:

• hidden divergence between design and test reality — the requirement log and the test record reference different values with no revision entry connecting them,
• late design turns — design is built to a known-wrong bound until a gate exception forces the change after commitment,
• supplier misalignment — supplier inspection criteria reference the frozen value, not the test-confirmed limit,
• and "surprise" gate failures — visible earlier in data, masked by a requirement record that stayed frozen.

Revision discipline in the requirement log prevents both uncontrolled churn and evidence denial.

The board thermal limit was set to 65 °C by the electrical engineering team — a conservative estimate intended to protect component lifetime across the product's operating range. It was not decomposed to the case temperature limits of the specific components on the board, and no scope note identified which operating scenario it applied to.

The full-load chamber test ran at full power and 40 °C ambient — the scenario defined for UL qualification — and measured the control board approaching 70 °C. The limit said 65 °C. The program ran three weeks of thermal management work: airflow changes, layout iterations, component placement. None of it was targeted, because the requirement had not been tied to the actual components at risk.

When the requirement owner pulled the 65 °C limit back to its basis, two questions surfaced: which components it was protecting, and which scenario it applied to. The answers changed the problem. The 65 °C estimate was a lifetime operating condition limit — it applied to sustained load in worst-case ambient across the product service life, not to a one-time UL qualification test at 40 °C. No component case temperature limit was being violated under the qualification test scenario. For the lifetime scenario, the question became which specific components were at risk and what their case temperature limits were — a decomposed set of requirements the 65 °C proxy had been standing in for.

• Old process: a single board-level temperature estimate applied as a requirement across both the lifetime operating scenario and the UL qualification scenario, without decomposition to component case temperature limits and without a scope note identifying which scenario it applied to.
• Artifact changed: the board thermal limit in the requirement log revised — the proxy replaced by a decomposed set of component case temperature limits for the lifetime scenario, with the qualification test scenario confirmed out of scope for that requirement; the revision record named the evidence source, rationale, impact scope, approver, and date.
• Measured improvement: three weeks of whole-assembly thermal management work redirected to targeted mitigation on the two components whose case temperatures were actually at risk under lifetime operating conditions.

Revision criteria (minimum)

Revise a requirement only when predeclared decision thresholds are met:

1. evidence crosses a pre-defined threshold,
2. operating conditions changed materially,
3. supplier/process capability data invalidates prior assumption,
4. a pending gate decision or design release depends on confirming or correcting the current value before commitment.

Each revision entry in the requirement log should include:

• old value, new value,
• evidence source,
• rationale,
• impact scope (design, test, cost, schedule),
• approver and date.

Acceptable implementations for the requirement lifecycle log include a gated product-data revision route when build truth must trace to an authoritative BOM, an issue-tracker type with gated fields for owner, evidence links, and revision trail when releases are routed from backlog records, a locked shared spreadsheet with named owners and protected history columns for early programs that still need fast iteration, or a controlled markdown log under version control when the team is small and repository-led. The OS does not care which; it cares that old value, new value, evidence source, rationale, impact scope, approver, and date are all in the same row.

Preventing moving-goalpost behavior

Teams resist revisions when the decision record looks arbitrary.

Prevent goalpost behavior by separating two artifacts:

• decision criteria (requirement ID, revision threshold, and decision owner — defined and locked in the revision memo before data arrives),
• decision outcome (revised value or reaffirmation — recorded after criteria are evaluated, with evidence source and approver).

If criteria stay stable in the decision record, revisions read as disciplined learning rather than political drift.

Weekly lifecycle review

For each active high-impact requirement ID, run a short weekly review:

• state check (Hypothesis/Bless/Evidence/Revise),
• evidence delta since last review,
• pending revision decisions and owners,
• downstream artifact update status.

The requirement owner should finish this review in minutes and publish one delta note, not run a half-day meeting.

If you cannot point at one requirement ID in your current program that revised in the last quarter with evidence in the log, an approver on record, and a downstream-update note, you are running on frozen-but-wrong values somewhere. Re-read Frozen-but-wrong is worse than revised-with-evidence.