1B. Workflow definition governance
Distinguish the complete read-only operational-flow catalogue from executable human workflow definitions, then create safe generic definitions or version protected codification and defence-inspection state machines without changing in-flight records or weakening code-owned safety callbacks.
Purpose
Distinguish the complete read-only operational-flow catalogue from executable human workflow definitions, then create safe generic definitions or version protected codification and defence-inspection state machines without changing in-flight records or weakening code-owned safety callbacks.
Tenant Administrator, DGQA Inspector, Auditor
Review all 40 code-owned operational flows, then inspect the two protected human workflow definitions. Optionally create ENGINEERING_CHANGE_REVIEW with DRAFT → IN_REVIEW → APPROVED / REJECTED, Materials Planner submission, QA Head decision, required notes and a different-person approval rule.
Before you begin
- Tenant Administrator is authenticated
- A separate DGQA Inspector can execute inspection-call transitions
- Only fictitious records are used
Configured workflow catalogue
A read-only register of all 37 implemented end-to-end business flows. These are code-owned domain behavior and safety invariants, not editable workflow templates.
The protected persisted state machines plus any tenant-created generic human workflow definitions. Seeing two protected definitions is expected and does not mean only two operational flows exist.
Live version-pinned state, instance counts and projected open transitions. Generic projections remain visible for governance even when no code-owned execution surface exists.
Shows only executable protected workflow tasks after permission, assigned role/user, site, clearance and maker-checker filtering. Module pages continue to show their own contextual actions; documentary flows and non-executable generic tasks are not presented as actionable notifications.
Not started → Draft → Submitted → Codified, with Reject and Reopen paths. SUBMIT retains the controlled-reference callback and CODIFY retains the NSN-assignment callback.
Called → Under inspection → Accepted or Rejected; a defect can route through Deviation or Concession pending, an MRB decision, and then controlled closure.
A tenant-scoped human workflow created from states, actions, roles, maker-checker dependencies and note/evidence requirements. It cannot run scripts, SQL, arbitrary endpoints, inventory postings or code-owned domain callbacks.
A new workflow or version is saved as DRAFT. Activation makes it authoritative for new instances and retires the prior active version; existing instances remain pinned to their original checksum and version.
Procedure
- 1
Open Administration → Workflow governance. In Operational flows, search the complete 41-flow code-owned catalogue and open the exact field-by-field handbook for one flow. Confirm the records are read-only and are not presented as generic templates.
- 2
Open Human workflow definitions. Inspect the lifecycle, visual map, active version, SHA-256 checksum, actions, roles, human controls, callbacks and version history for ITEM_CODIFICATION and DEFENCE_INSPECTION_CALL.
- 3
Open Instances & tasks. Compare live version-pinned instance state with projected tasks, and distinguish executable protected tasks from generic definition projections.
- 4
Select Create workflow. Enter the human-readable name, stable uppercase key and a purpose that explains when the workflow starts, the decision it governs and where it ends.
- 5
In States, keep exactly one initial state and select at least one terminal state. Add or remove intermediate states as required.
- 6
In Transitions, connect the states, assign the responsible role, select a directly preceding maker action when a different person must decide, and choose whether a note or controlled evidence is mandatory.
- 7
Review the visual map. Resolve duplicate keys, unreachable states, terminal-state exits, missing outcomes or broken maker-checker references, then save immutable version 1 as DRAFT.
- 8
Review the saved draft in Version history and activate it. Confirm it appears as a UI-created generic workflow and remains unable to invoke code-owned callbacks or alias operational actions.
- 9
For a protected built-in workflow, use the Advanced version editor only for a controlled new version. Attempt an unknown action, removed safety callback, unreachable state or outgoing terminal transition and confirm the server rejects it.
- 10
Create or transition an eligible protected record. Sign in as the assigned authorised user and confirm the header Action Centre shows the next executable task and opens the owning domain screen; confirm an out-of-scope, under-cleared, unassigned or maker-excluded user cannot see it.
- 11
Transition one existing instance and one newly created protected record; confirm the existing instance stays pinned while the new instance uses the active version, then inspect task and hash-linked transition evidence.
Expected result
- All 41 code-owned operational flows are visible separately from human workflow definitions
- Seeing two protected definitions is expected until a tenant deliberately creates a generic definition
- Only Tenant Administrators can create workflows or activate versions
- The visual designer creates a tenant-scoped generic workflow without JSON, scripts or callbacks
- Every saved workflow is connected, has one initial state, at least one terminal state and valid maker-checker references
- Exactly one version per workflow is active
- Active/retired definitions are immutable and in-flight instances remain version-pinned
- Codification reference/NSN and inspection MRB callbacks cannot be removed or reassigned
- The Action Centre is read-only, shows only executable protected tasks in the user's exact authority scope, and creates no notification delivery or business mutation
- Business status, workflow instance, task projection, transition hash and audit event commit atomically