Stages, Substages, and What “Done” Means

A stage in a workflow isn’t a free-form description. It’s a structured definition: entry conditions, work-required, completion criteria, and exit artefacts. That structure is what makes the engine deterministic.

Entry conditions

What needs to be true before an asset can enter the stage. For "testing": asset is in a warehouse zone of type "processing," receiving is complete, the device category has a defined test checklist. The platform won’t allow the entry transition if the conditions fail; it surfaces the failure with the specific reason.

Work-required

The action that has to happen during the stage. For testing: complete the test checklist for the asset’s category. For grading: assign all four sub-grades plus the overall. For erasure: complete the erasure tool run and import the report. The action surfaces as the next-action prompt on the asset detail and on the operator’s queue.

Completion criteria

What marks the stage done. For testing: every required defect-zone is checked, the functional and battery grades are populated. The platform doesn’t accept a "complete" toggle without the criteria being met; trying to advance an under-tested asset surfaces the gap.

Exit artefacts

What gets generated when the stage completes. For erasure: an erasure certificate per drive, a D0 status on the asset, an audit row. For grading: an audit row recording the grades and the criteria version, a status flip to "graded." Some artefacts are documents (PDFs); some are state changes; some are downstream entity creations (settlement rows, listings, etc.).

Manual override

An operator with the right role can manually advance an asset past a stage, with a reason recorded. Used for edge cases (asset arrived already-tested by the client, stage doesn’t apply). The override is logged; the audit trail records that the stage was manually completed rather than walked through.