38. Signed software/test execution and result packs
Fail build scheduling, controlled operation execution and as-built capture closed unless exact baseline software, signed artifact hashes, test procedures/adapters/parameters and compiled results have the required independent attributable decisions.
Purpose
Fail build scheduling, controlled operation execution and as-built capture closed unless exact baseline software, signed artifact hashes, test procedures/adapters/parameters and compiled results have the required independent attributable decisions.
Manufacturing Engineer, different Product Engineer, different Quality Engineer, different Production Manager, exact executing Production Operator, different Quality Inspector and a separate downstream as-built Quality Inspector
DESIGN v1 CI-SW 1.0.0 + LOAD_SW + FINAL_TEST → MEP-… v1 rejected → v2 technical/quality/release signed → version + SHA-256 execution → MER-… v1 rejected → v2 Quality accepted → as-built enabled.
Before you begin
- Flow 31 MBOM and Flow 27 manufacturing plan are current and independently released
- Routing has exactly one SOFTWARE_LOAD per active released baseline SOFTWARE/FIRMWARE CI
- Routing includes at least one INSPECTION or TEST operation
- Every artifact/procedure/evidence document version is same-site, within classification and CLEAN
- All definition and downstream result/as-built authorities are different named users where required
Signed identity, adapter and authority boundaries
A signature is an attributable authenticated workflow decision over immutable source and definition/result SHA-256 fingerprints plus controlled evidence. Flow 32 does not claim PKI document signing.
Every exact baseline SOFTWARE/FIRMWARE CI must appear once and map to one released SOFTWARE_LOAD operation. The server freezes CI/reference/version, CLEAN artifact document hash, target and verification method.
Every released INSPECTION/TEST operation must appear once with one CLEAN procedure, MANUAL_JSON_V1 or AUTOMATED_JSON_V1 adapter and unique parameters. Numeric parameters require an objective lower or upper limit.
A different Product Engineer technically approves the manifest, a different Quality Engineer approves procedure/adapter control and a third Production Manager releases. No actor may perform an adjacent decision.
Build scheduling requires the current released pack. SOFTWARE_LOAD accepts only its exact expected version plus signed artifact SHA-256; INSPECTION/TEST accepts exact parameter coverage and released units.
Only a Production Operator who executed at least one exact controlled operation may compile the latest passing executions. Measurements, software identity and adapter type must exactly match immutable source evidence; automated adapters require an external record identity.
A different Quality Inspector accepts unchanged result fingerprints before as-built capture. That accepted-result reviewer is included in prior authorities, so another named inspector must review downstream as-built evidence.
Flow 32 never issues a machine command or changes safety state, Engineering/Quality source records, current_stock, stock_ledger, custody, Assembly, physical identity, procurement, payroll or accounting.
Procedure
- 1
Create execution-pack v1 from one exact released plan with every software and test operation covered; select CLEAN artifact/procedure/evidence versions.
- 2
Submit as Manufacturing Engineer, reject as a different Product Engineer, retain v1 and author corrected v2.
- 3
Technically sign v2 as Product Engineer, quality-sign as a different Quality Engineer and release as a third Production Manager only while all hashes/fingerprints remain unchanged.
- 4
Schedule and execute in released order; record exact version + artifact SHA-256 for software and exact released parameters for tests.
- 5
After every operation passes, compile result v1 as an exact executing operator, reject independently, retain it, create v2 and obtain Quality acceptance.
- 6
Prove as-built was blocked before acceptance and use a separate Quality Inspector for downstream as-built review; audit all zero-authority witnesses.
Expected result
- Scheduling fails without a current RELEASED/APPROVED pack
- Baseline software/firmware and SOFTWARE_LOAD coverage is exactly one-to-one
- Every inspection/test has exact CLEAN procedure, adapter and parameter control
- Technical, Quality and Production definition decisions are independently attributable
- Rejected definition and result versions remain immutable
- Software version/hash and test measurements fail closed on mismatch
- Automated results retain immutable external record identity
- Only an exact executing operator compiles results and cannot accept them
- As-built requires accepted results and another downstream Quality reviewer
- No machine, safety, Engineering, Quality-source, inventory, custody, Assembly, identity or accounting record is changed