Engineering release and configuration control: the drawing that went to production unapproved
Configuration management is the discipline that keeps what you built matching what you designed. It is implemented, in most programmes, as a workflow state transition that anyone with the role can perform on behalf of anyone who is on holiday.
How does an unapproved drawing reach production?
Through a workflow state. A revision release authorises manufacture, and the approval record is a PLM workflow field naming a user — with delegation during absence universal and usually unrecorded as delegation. The drawing that reaches the floor is trusted because the state says released.
- PLM systems model approval as workflow states with approver fields. The approval is not bound to the specific model or document released.
- Absence delegation is universal, informal and prohibited by most procedures, which means it happens and is not recorded.
- Binding the approval to artefact hashes turns a nonconformance investigation from archaeology into a lookup.
Part of Defense industrial base identity
The investigation that takes three weeks
A machined part fails inspection. The dimension is out of tolerance against the drawing the inspector is holding. The shop was working to a different revision.
Now reconstruct: which revision was released when the work order was issued, who approved it, what did they approve, and was the approver the person named in the record?
In most programmes that reconstruction involves the PLM history, the ERP work order, the shop traveller, and a conversation with an engineering manager about who was covering for whom in March. It takes weeks and produces a probable answer.
What configuration management assumes
Configuration management standards for defense programmes establish that configuration items are identified, changes are controlled, status is accounted for, and configuration is audited against the product baseline.
All four depend on knowing which configuration was authorised at a point in time, by whom. The standards assume that is recorded. The implementation records a workflow state and a user id.
Three specific gaps
| Gap | Consequence |
|---|---|
| Approval not bound to the artefact | The approver approved revision D, not this specific model file. A regenerated or re-exported file is indistinguishable. |
| Delegation undocumented | The record names the approver; the approval may have been performed by a delegate under informal cover. |
| No render binding | Model-based definition means the authoritative artefact is a 3D model with embedded PMI. What the approver viewed is not captured. |
The third gap grows as programmes move from drawings to model-based definition. A drawing is a picture; a model is a database, and what a reviewer saw depends on their viewer configuration.
The Release Approval Receipt
{
"type": "manav-stmt/1",
"action": "engineering_release",
"render": [
"Item: [part number] Revision: [rev]",
"Model hash: [value] Drawing hash: [value]",
"Change reference: [ECO/ECN number]",
"Effectivity: [serial range | date]",
"Approval basis: [checked | verified | qualified]"
],
"approver": "[credential assertion, authority reference]",
"delegation": "[reference, where the approver is acting under cover]"
}The delegation field is the honest addition. Absence cover is a real operational need; making it explicit and bounded is better than a procedure that prohibits it while everyone does it.
Designing absence cover properly
A bounded delegation for approval authority should carry four constraints:
- An expiry matching the absence, not an open-ended grant.
- A scope limited to item classes the delegate is technically qualified to approve.
- An explicit exclusion of safety-critical or flight-critical items, which should wait.
- Visibility to the programme, so the delegation appears in configuration status accounting rather than in an email.
What this saves
The direct saving is investigation time, and it is substantial. A nonconformance investigation that begins with a verifiable release record starts three weeks ahead of one that begins with a PLM query.
The larger saving is scrap and rework avoided when a configuration mismatch is caught at release rather than at inspection. That number is programme-specific and every quality organisation already tracks it.
What this does not address
It does not validate the engineering. An approver with authority can approve a design that is wrong, and the receipt will faithfully record that they did.
It also does not address configuration drift at the shop — work performed to a superseded revision because the traveller was printed before the change. That is an ERP and shop-floor problem, adjacent and separate.
What configuration control assumes
| Assumption | Implementation |
|---|---|
| A competent authority released this revision | A workflow field was set |
| That authority reviewed the change | No record of what was reviewed |
| The released revision is the one manufactured | Usually true, and unverified at the machine |
| Delegation is exceptional and recorded | Delegation is routine and invisible |
Objections and honest limits
“PLM permissions control who can release.” They control who can set the state. Delegation rules, administrators and integrations all sit inside that permission model, and each produces an identical record.
“The drawing is checksummed downstream.” Which proves the file did not change in transit. It says nothing about whether the release was authorised.
Binding a release
- Sign the revision, not the workflow state. Part number, revision, change summary, effectivity.
- Record delegation as a signed act. If someone releases on another's behalf, that is a fact worth capturing.
- Verify at the point of manufacture. So an unsigned revision cannot be worked to.
- Retain to the programme's life. Which exceeds the PLM system's.
Terms used here
- Revision release
- The act authorising a specific drawing revision for manufacture.
- Configuration control
- The discipline ensuring what is built matches what was authorised, and that changes are approved.
- Effectivity
- The serial numbers or date range a revision applies to. A release without it is ambiguous.
Frequently asked questions
Does this require replacing our PLM? No. The receipt is produced at the release step and sits alongside the PLM record. The PLM remains the system of record for configuration.
How does this handle model-based definition? The model file is hashed, and the viewer configuration used for review can be captured in the render field. That is more than any current system records.
Is absence delegation really that common? Ask your engineering managers rather than your procedures. The procedures prohibit it almost universally, which is why it is undocumented rather than absent.
What about supplier-released items? The same structure applies across the boundary, using the cross-boundary access and delegation mechanisms described elsewhere in this series.
Why isn't a PLM workflow state sufficient? Whoever can set the field can authorise manufacture, and delegation, administrators and integrations all produce the same record.
What should the signature cover? Part number, revision, change summary and effectivity — the facts a later investigation needs.
Where should it be verified? At the point of manufacture, so an unsigned revision cannot be worked to.
Where this fits in Manav
Manav binds the authorising individual to the exact record being released or approved, and produces a receipt a prime, a government customer or an auditor can verify without access to your systems.
Sources and further reading
- Configuration management standards for defense programmes.
- Programme quality assurance requirements addressing engineering release.
- PLM vendor documentation on approval workflows and delegation.
- CISA — known exploited vulnerabilities and incident reporting
- NIST SP 800-171 Rev. 3 — Protecting CUI