How Do You Know When Your Requirements Are Stable Enough to Release to Manufacturing?
The question sounds procedural. It is not. Releasing a design to manufacturing against requirements that are not yet stable is one of the most expensive decisions a program can make, and it is made routinely under schedule pressure, with insufficient data, by people who know better but cannot prove their case to the program office.
This article gives you the criteria, the metrics, and the reasoning to make that case — or to make the release decision with confidence when the data supports it.
What “Stable” Actually Means
A common mistake is to treat requirements stability as a binary state: either the requirements are baselined or they are not. Baseline is a configuration management concept. Stability is an engineering concept, and they are not the same thing.
A baselined requirement can still be volatile. It can be changed through the formal change process. What you need to know is not whether the requirements are under change control, but whether the rate of substantive change has dropped to a level where the design can proceed through manufacturing without being invalidated.
A working definition: requirements are stable enough to release to manufacturing when the probability that a requirement change will force a manufacturing rework or scrap event has dropped below a threshold the program has explicitly accepted.
That threshold is a business decision, but it must be explicit. Programs that release without naming the threshold are not making a decision — they are deferring one, at higher cost.
The Metrics That Actually Matter
Volatility Rate
Requirements volatility rate is the most direct quantitative indicator. Calculate it as:
Volatility Rate = (Number of requirements with approved changes in the measurement period) ÷ (Total number of requirements in the affected specification) × 100
Track this weekly across a rolling four-week window. A single week of low volatility means little. A sustained trend does.
Practical threshold values drawn from programs that have tracked this rigorously:
- Above 5% per week: Do not release. The requirements are actively evolving. Manufacturing will be building to a moving target.
- 2–5% per week: Elevated risk. Investigate whether the changes are clustered in specific subsystems or interface areas. Partial release may be defensible if the volatile requirements are isolated.
- Below 2% per week, sustained over four weeks: Release is potentially defensible, pending the other criteria below.
The four-week window matters because a two-week lull following a major change campaign is not stability — it is the pause before the next wave of changes as the implications of earlier changes propagate.
One important caution: volatility rate is only meaningful if people are actually looking at the requirements. A specification that has not been reviewed in six weeks will show zero volatility not because the requirements are right, but because no one has examined them carefully enough to know they are wrong.
TBD and TBR Closure Rate
TBDs (To Be Determined) and TBRs (To Be Resolved) are formal markers of known incompleteness. Every open TBD is an admission that a value, constraint, or decision required to fully specify the design has not yet been established. Every open TBR is an admission that a conflict or uncertainty has been identified but not yet resolved.
Before any volatility metric is meaningful, you need a TBD/TBR closure campaign: a systematic review in which every open marker is either resolved with a specific value or decision, or elevated to a formal risk with an owner, a resolution path, and a deadline.
Closure rate should be tracked as a trend, not just as an absolute count. A program that has closed 80% of its TBDs over the past eight weeks and is closing the remaining 20% on a documented schedule is in a different position than a program that has had 20% open TBDs sitting unexamined for three months.
Release criterion: Zero open TBDs in requirements that drive manufacturing process design. Zero open TBRs involving interface definitions that affect tooling, fixturing, or test equipment. Any exceptions require documented risk acceptance by the chief engineer, not by the program manager.
This distinction matters: the authority to accept technical risk on incompleteness should be an engineering authority, not a schedule authority.
Verification Method Assignment
A requirement without an assigned, feasible verification method is not a complete requirement. It is a statement of intent without a closure plan. Releasing it to manufacturing means manufacturing will build something that may never be formally verified — or will need to be rebuilt when the verification method is eventually established and proves incompatible with the design as built.
Check three things for each requirement:
- Is a verification method assigned? (Test, Demonstration, Analysis, or Inspection — one of the four, or a documented combination.)
- Is the method feasible given the manufacturing configuration? Some test methods require access to internal interfaces that will be closed off after a manufacturing step. If the test must be done before enclosure and the requirement is assigned to final system test, you have a verification gap.
- Are the verification resources baselined? Test equipment procured or on order. Test procedures drafted. Test facilities identified and reserved. If the answer is no to any of these, the verification plan is notional, not real.
Requirements that pass the volatility and TBD/TBR criteria but fail the verification assignment criteria are not ready for manufacturing release. They may look stable because no one has thought hard enough about how to verify them.
Stakeholder Sign-Off — What It Should Mean and What It Usually Means
Formal stakeholder sign-off is a required criterion, not a sufficient one. It matters because it surfaces disagreements before they become change orders. It does not, by itself, indicate that the requirements are technically complete.
The sign-off process should include:
- Customer or customer representative: Confirming that the requirement as stated captures the actual intent and that derived requirements are authorized.
- Systems engineering: Confirming that requirements are traceable, non-conflicting, and that the verification logic is complete.
- Manufacturing engineering: Confirming that the requirements are producible as stated and that no manufacturing process constraint has been overlooked.
- Test and verification: Confirming that verification methods are feasible and that test infrastructure can be ready in time.
The manufacturing engineering sign-off is the one most commonly treated as a formality. It should not be. Manufacturing engineers reviewing requirements before release will catch producibility issues — tolerance stackups that are theoretically achievable but practically unreliable, surface finish requirements that require process steps not yet in the manufacturing plan, material specifications that create supply chain dependencies not yet resolved.
The Dangerous Illusion: Stability by Neglect
This deserves its own section because it is the failure mode that experienced engineers consistently underestimate.
A requirement that has not changed recently is not necessarily stable. It may be:
- Correct as written, and no one needs to change it. This is genuine stability.
- Wrong or incomplete, but no one has reviewed it carefully enough to know. This is stability by neglect.
- Awaiting an upstream decision that will force changes when it arrives. This is pending volatility.
The way to distinguish these is active review, not passive observation. Before declaring requirements stable, the engineering team must conduct a structured requirements review — not a walkthrough of existing text, but a systematic attempt to break the requirements by asking:
- Can this requirement be satisfied by a design that does not meet the actual intent?
- Is there a scenario in which this requirement is simultaneously satisfied and the system fails?
- Is this requirement traceable to a specific customer need, or is it an orphan that has never been challenged?
- Has the interface partner reviewed this requirement and confirmed their interface assumptions match?
Requirements that survive this review without generating changes are genuinely stable. Requirements that have simply not been reviewed are not.
Manufacturing Readiness Is a Parallel Criterion, Not a Derived One
Even when requirements are genuinely stable by all the criteria above, release to manufacturing requires that the manufacturing process design is ready to receive them.
Manufacturing Process Readiness is sometimes treated as a downstream consequence of requirements stability: once requirements are stable, manufacturing can finalize the process design. This is wrong. Manufacturing process design has its own lead time and its own open questions. The two readiness assessments must run in parallel.
Before releasing to manufacturing, confirm:
- Critical manufacturing processes are qualified or are on a documented qualification path with schedule margin ahead of first article inspection.
- Tooling and fixturing designs are complete or the delta between current tooling and final tooling is explicitly bounded.
- Manufacturing process FMEAs have been completed for high-risk steps, and process controls are in place for the identified failure modes.
- The manufacturing process design is traceable back to the requirements. Not informally, but with documented process links. If a requirement changes after release, you need to know immediately which manufacturing steps are affected.
This last point — traceability from requirement to manufacturing process step — is where most programs are most exposed. When a post-release change order arrives, the question “what do we have to redo?” is answered by this traceability. Programs that do not have it answer that question by convening meetings and interviewing engineers, which is slow, expensive, and error-prone.
How Modern Tools Make the Release Decision Defensible
The criteria above are all computable. Volatility rate, TBD/TBR closure rate, verification method assignment completion, stakeholder approval status — these are data. The question is whether your tooling makes that data visible at the program level, in real time, without requiring a requirements engineer to manually compile a status report the night before a milestone review.
This is where Flow Engineering earns its mention. Flow Engineering tracks TBD and TBR markers as first-class objects within the requirements model, giving programs a live closure rate trend rather than a snapshot count. Volatility trends are computed from change history automatically, so the release readiness picture is current at any point, not just at formal review gates.
The practical value is not just efficiency. It is that programs making the release decision have objective data in front of them when schedule pressure is pushing toward early release. “Our TBR closure rate is still declining and we have 14 open TBRs in the interface definitions” is harder to override than “I think we need a few more weeks.” The data changes the conversation.
Flow Engineering’s model-based approach also surfaces the verification method assignment gaps that traditional document-based reviews miss. When requirements live in a connected model rather than a specification document, incomplete verification assignments appear as model integrity issues, not as annotation gaps buried in a table.
Decision Framework: A Practical Gate
Before signing the release to manufacturing, each of the following must be true:
| Criterion | Threshold | Exception Process |
|---|---|---|
| Volatility rate | < 2% per week, 4-week sustained | Chief engineer written acceptance |
| Open TBDs (manufacturing-affecting) | Zero | None — no exceptions |
| Open TBRs (interface definitions) | Zero | None — no exceptions |
| Verification method assigned | 100% of requirements | Chief engineer written acceptance |
| Verification feasibility confirmed | 100% of requirements | Systems engineering written acceptance |
| Stakeholder sign-offs complete | All four categories | Program director written acceptance |
| Manufacturing process readiness confirmed | Per manufacturing readiness checklist | Manufacturing engineering written acceptance |
The exception process column is not permission to skip the criteria. It is documentation that a specific, named person with appropriate authority has accepted a specific, bounded technical risk. The documentation must include the risk description, the acceptance rationale, and the mitigation plan if the risk materializes.
Honest Summary
Most programs that release to manufacturing too early do not do it because they lack criteria. They do it because the criteria are not enforced with data — the assessment is qualitative, the pressure is quantitative, and qualitative assessments lose that argument.
The path to a defensible release decision is making the criteria quantitative, tracking the metrics in a tool that keeps the data current without manual compilation, and assigning exception authority at the right engineering level. Requirements that are genuinely stable, actively verified as stable, and backed by a manufacturing process that can receive them — that is the threshold. Anything short of it is a schedule decision disguised as an engineering one.