40. Governed MES evidence adapters and receipts
Admit exact automated external evidence into signed Flow 32/33 results only through a released ingest-only contract, immutable receipt, independent Quality decision and single-use binding.
Purpose
Admit exact automated external evidence into signed Flow 32/33 results only through a released ingest-only contract, immutable receipt, independent Quality decision and single-use binding.
Manufacturing Engineer, different Product Engineer, different Security & Compliance Officer, different Production Manager, Production Operator and different Quality Inspector
MEP-… / FINAL_TEST AUTOMATED_JSON_V1 → MES-… v1 rejected → v2 technical/security/release signed → MER-… Quality accepted → exact result consumes receipt once.
Before you begin
- Flow 32 execution pack or Flow 33 acceptance campaign is current, released and contains an AUTOMATED_JSON_V1 binding
- Every definition, transition and receipt evidence version is same-site, within classification and CLEAN
- Profile author, technical reviewer, security reviewer and releaser are different named users
- Receipt importer and Quality verifier are different named users
Ingest-only contract, immutable receipt and replay boundaries
EXECUTION_TEST binds one released execution-pack parent plus operation code; ACCEPTANCE_PHASE binds one released campaign plus current phase type. Source version, definition SHA-256, exact parameters and units are frozen.
Direction is server-fixed to INGEST_ONLY and contract version to MES_EVIDENCE_JSON_V1. The profile exposes no callback URL, credential, arbitrary mapping, outbound command or service-account authority.
A different Product Engineer performs technical review, a different Security & Compliance Officer assesses the bounded transport/evidence posture, and a different Production Manager releases. Rejection retains an immutable version for author replacement.
The server canonicalises exact source, binding, target, external record ID, observation time, result and measurements, then stores payload and receipt SHA-256 fingerprints. External record identity is unique per profile version.
A different Quality Inspector accepts or rejects unchanged receipt fingerprints. FAIL cannot be accepted; a rejected receipt is never revised and a corrected external run requires a new external record.
When a released MES profile exists, Flow 32/33 must cite the exact accepted receipt. Target, external ID, time, result, parameter values/units and fingerprints must match; the successful immutable result consumes it once and replay fails.
Flow 34 sends no external command/message, changes no machine/safety state, customer delivery, Engineering/Quality source, current_stock, stock_ledger, custody, Assembly, physical identity, product-unit status, procurement, payroll or accounting record.
Procedure
- 1
Create profile v1 for an exact released automated binding and attach CLEAN definition evidence.
- 2
Submit, reject v1 in technical review and retain it; create v2 and obtain independent technical, security and Production release signatures.
- 3
As Production Operator, ingest one exact PASS receipt for an eligible build or exact acceptance phase, retaining its external ID and canonical hashes.
- 4
As a different Quality Inspector, verify the unchanged source and payload and accept it.
- 5
Create the corresponding Flow 32/33 result using exactly the receipt external ID, observation time, result and measurement payload; inspect its consumption reference.
- 6
Attempt a replay or mismatched payload and confirm it fails; audit all six authorities and every zero-control witness.
Expected result
- Only current released automated sources can be bound
- Profile lifecycle is DRAFT → TECHNICAL_REVIEW → SECURITY_REVIEW → RELEASE_REVIEW → RELEASED or REJECTED
- Technical, security and Production decisions are separately attributable
- Receipt payload and source fingerprints are immutable
- Quality verifier differs from importer and cannot accept FAIL
- Released profiles make an accepted exact receipt mandatory downstream
- Each accepted receipt is consumed at most once
- No command, message, delivery, source, inventory, custody, Assembly, identity or financial state changes