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.

The released drawing package had Rev C on the cover and Rev B in the work instructions — both inside the same folder stamped "released," on a Tuesday morning with the line about to build.

Manufacturing asked which revision was real. Test had validated Rev C assumptions. Procurement had placed orders against Rev B.

The package was "released." The program still had three definitions of done.

What spec integrity means

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

1. What is the current requirement?
2. Why is it that value?
3. What evidence supports it?
4. 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 start as a single revision not propagated — one team still running the old value while another has already moved.

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.

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. The structural load requirement 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 verbally is reliable.

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

Field test: 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.

A month later that same requirement revised again — cleanly this time: one value, one owner, one confirmed date. Two weeks after that, the gate deck still showed the old number. The package was right. Nothing downstream had heard about it.