5. Spec Integrity and Requirement Hygiene

Ownership defines who closes decisions. What those decisions close on is the requirement record — and a decision is only as good as the requirement it references.

Tuesday, 7:20 a.m., the drawing package still warm from the printer, Rev C on the cover and Rev B still in the work instructions.

Manufacturing asks which revision is real. Test says they validated Rev C assumptions. Procurement already placed orders against Rev B.

The drawing package is "released." The program still has three definitions of done.

What spec integrity means

Spec integrity means every team can answer the same four questions with the same source:

What is the current requirement?
Why is it that value?
What evidence supports it?
Who approved the latest change?

If answers differ by function, the program does not have a spec. It has parallel interpretations.

Hygiene failures that look small and cost big

Most failures are not dramatic. They are quiet mismatches.

Rev C.2 changed the leak-test dwell value, but manufacturing work instructions still referenced Rev C.1 while test benches used the new value. That one mismatch forced three days of teardown and retest. The team then found the dwell requirement had no owner and no rationale trail for the original dwell change. Once an owner was assigned and a controlled revision record was created with the rationale, the next revision — a ten-second dwell adjustment — was processed in four hours and reached all affected work instructions the same day. - Old process: no owner on the dwell requirement, no rationale trail, revision chain broken — manufacturing, test, and supplier each building to a different value.

Artifact changed: an owner assigned to the dwell requirement and a controlled revision record created, with the rationale for the change documented.
Measured improvement: the next revision processed in four hours and distributed to all affected work instructions the same day.
Cost of the gap: three days of teardown and retest before the mismatch source was found and the requirement baseline was trustworthy.

Requirement statement quality (minimum bar)

A requirement is usable when it is:

specific (single unambiguous statement),
measurable (clear units and method),
bounded (conditions/scope explicit),
traceable (stable unique ID; named origin),
owned (named person accountable for quality).

Traceable means the requirement has an identifier that does not change when the value changes — downstream artifacts reference the ID, not the number — and a named origin: the customer spec, test result, or engineering decision that justifies why this requirement exists.

"System shall be robust" is not a requirement. "Leak rate shall be <= X under conditions Y and Z, measured by method M" is.

Revision discipline

Revision control is where integrity usually breaks.

The minimum: one controlled source — same location, same revision label — that every function reads from. If the value lives in a chat message or a personal folder, it is not controlled.

The rest adds durability:

Change log entry with rationale and evidence link.
Explicit impact note: which tests, supplier packets, and schedule rows must update.
Named approver matched to change scope — adjusting a tolerance within a validated range needs the requirement owner's sign-off; redefining what a requirement measures needs broader authority because every artifact built against it is affected.

On one program, a stress analyst revised a structural load limit after a test result, notified manufacturing verbally, and considered the revision complete. REQ-STRUCT-08 remained at the old value in the controlled record. Manufacturing built to the revised limit; the supplier qualification test ran against the original. The gap surfaced at first-article acceptance: a three-week hold while the record, the build, and the supplier notification were reconciled.

If a value changes without the controlled source updated, treat the change as unofficial until cleaned up.

Requirement hygiene checklist for active programs

Run this weekly on active high-risk requirements:

Owner named
Current value and revision confirmed
Source/evidence linked
Acceptance method defined
Last change rationale captured
Downstream artifacts updated (test plan, one-page status, supplier packet)

This is not paperwork for paperwork. It is a control loop for decision quality.

Three implementations that work:

A spreadsheet with a named-owner column, a current-value column, an evidence column, and a change-log tab — sufficient for most programs and requires nothing to set up.
A shared document with a fixed requirements table and a change history section at the bottom — works when the team already has a shared document location everyone reads from.
A version-controlled plain-text file in the same repository as design files — works for small engineering-led teams where file history serves as the revision record.

All three share the same requirement: six fields in one stable location — owner, current value, evidence link, acceptance method, change rationale, and downstream-update record — and a history that shows what changed and when. What disqualifies a tool is behavior: if the current value is in a message thread and the approval is in an email, there is no controlled requirement. There is only a number floating in conversations with no way to confirm which version is live.

Why requirement quality comes before gate design

Gates cannot be strong if requirement quality is weak.

A gate asks, "Are we ready to commit?" If requirement truth is ambiguous, the gate is a well-prepared presentation over hollow data — the review happens, the questions get answered, and nothing said in the room is reliable.

Spec integrity is the substrate under every later control: risk scoring, one-page truth, supplier alignment, and schedule realism.

If a requirement in your current baseline has no evidence link, no named acceptance method, and no revision history, it is not a requirement. It is a wish with a number. Find three of those today and fix them.