28. Deviation, concession and waiver governance
Govern bounded temporary permission without granting the Quality workspace baseline-release, stock-disposition, inspection, audit or external-message authority.
Purpose
Govern bounded temporary permission without granting the Quality workspace baseline-release, stock-disposition, inspection, audit or external-message authority.
Quality Engineer, two different QA Head users, Product Engineer, Configuration Manager, conditional Project/Contract Manager and Product Safety Manager, Auditor read-only
DEV-… scope v1 rejected → immutable v2 → engineering/configuration/conditional concurrence → final QA authorisation → exact application → independent verification → closure.
Before you begin
- Every named actor is active, same-site scoped and cleared
- The exact item revision, product baseline or configuration item is already approved/released/active
- Concessions already have a same-site/classification Flow 13 NCR
- Any material effect already has a matching approved MRB
- At least one same-site ACTIVE, CLEAN evidence version exists
Temporary-permission scope, exact authorities and non-authority boundaries
DEVIATION is bounded pre-use permission, CONCESSION requires an exact NCR for a known nonconformity, and WAIVER requires contract/customer authority and cannot carry material disposition.
Select one approved item revision, released product baseline or active configuration item. Its identifying facts are snapshotted into every immutable scope version.
Material effect is allowed only for DEVIATION/CONCESSION and requires one exact same-site/classification approved MRB whose proposed disposition matches the case type. Flow 22 never executes it.
QA scope and final QA are different users. Product Engineering and Configuration are always separate required reviewers. Contract/customer and Product Safety are required only when declared by the immutable scope.
Validity dates, optional quantity limit, effectivity, technical basis, risk, compensating controls and verification plan are frozen. Applications outside the validity dates are blocked.
Operational use cites an exact MRB execution, maintenance work order, inspection lot or the retained configuration source when that route is selected; text-only references remain explicitly non-authoritative routes.
The application recorder, author and final authoriser cannot verify the same application. Every pending application blocks closure.
Flow 22 creates zero notification deliveries and never changes items/baselines/configuration, MRB, inspection, maintenance, current_stock, stock_ledger or audit records.
Procedure
- 1
Create scope v1 as Quality Engineer from exact approved sources and CLEAN evidence; submit it and reject it as the first QA scope reviewer.
- 2
Create immutable scope v2 and pass it through separate QA scope, Product Engineering, Configuration, conditional Contract/Safety and final QA identities.
- 3
Record an application inside validity against its exact authoritative source; verify it as a separate QA user.
- 4
Request closure and close as a separate QA user only after all application verification gates pass.
- 5
Reconcile immutable source snapshots, versions, decisions, evidence and zero source-domain side effects as Auditor.
Expected result
- Lifecycle follows DRAFT → SCOPE_REVIEW → TECHNICAL_REVIEW → AUTHORITY_REVIEW → FINAL_REVIEW → ACTIVE → CLOSURE_REVIEW → CLOSED
- Rejected scope versions remain immutable
- Product Engineering and Configuration are mandatory distinct identities
- Declared contract and safety review cannot be skipped
- A concession requires NCR and material effect requires matching approved MRB
- Final QA differs from scope QA and every prior reviewer
- Every bounded application is independently verified
- Unacceptable residual risk cannot close
- Flow 22 creates zero notification deliveries and never changes configuration, inventory, ledger, MRB, inspection, maintenance or audit records
- Auditor mutation attempts are rejected