Process learning

Define process states that tell people what happens next

A process state describes the condition of work, the evidence needed to enter it and the action permitted next. Clear definitions stop a finished draft from being mistaken for checked, approved or completed work.

Read the state reference

By Kevin Maguire

Keep each state definition beside the evidence that permits it.

Choose a state from the condition of the work

A state dictionary gives each label one meaning. A transition matrix adds the permitted moves between labels. Together they prevent “done”, “waiting” and “blocked” from hiding different evidence or approval conditions.

The reference below illustrates the distinctions in this method. Match the exact codes and completion requirements to the process you use; these labels are not a universal external standard.

State reference: condition and permitted next action
State	What it means	What happens next
Not started	Work has not begun. The scope and owner may be assigned, but there is no completed work to check.	Begin the assigned work after its prerequisites are available.
Active work	The assigned work is being produced or repaired.	Submit a reviewable version with its sources; do not skip the required checks.
Checking	A defined version is being checked against its requirements.	Record the test results and any failure before choosing the next state.
Ready for handoff	Required checks and approvals have passed, and the recipient can inspect the version, evidence and unresolved items.	Transfer only through the agreed handoff conditions.
Awaiting human approval	The work has passed its required checks, but a required human decision is still outstanding.	Wait for the named approver; passing checks alone does not grant permission.
Complete	All completion conditions for the agreed scope have been met, including required approval and handoff.	Preserve the accepted version and the event that would reopen review.
Failed checks	A check has identified a defect in the submitted work or evidence.	Repair the smallest affected unit and repeat the relevant checks.
Blocked	A dependency prevents the next required action.	Name the dependency, its owner and the evidence needed to resume.
Needs another check	A previously accepted record may no longer be supported after a source, scope or version change.	Recheck affected assertions and dependent work before relying on the old result.
Evidence deferred	A specific evidence requirement remains unresolved and has an explicit condition for later review.	Keep the gap visible; do not treat deferred evidence as a passed check.
Not applicable	A requirement does not apply to the stated scope, for a recorded reason.	Retain that reason and its scope; reopen the question if the scope changes.

Do not allow a direct move from NOT_STARTED to COMPLETE. Work must pass the required checks and meet the approval and handoff conditions even when the resulting prose or code appears finished.

An open folio holding source notes and page instructions beside an owner badge and checklist. — A handoff needs its source record, responsible owner and review conditions.

Give every state an observable entry and exit

A useful definition tells another contributor how to recognize the state without asking what the label was meant to imply. Define the operational condition, the evidence that permits entry and the action that permits exit.

Identity and meaningGive the state a stable name or code and a plain language definition. Distinguish the state of the work from a reviewer’s confidence in it.
Permitted transitionsName valid predecessors, prohibited shortcuts and any checks, approval, dependency or repair needed for the next move.
Evidence and scopeAttach the source, observation date, applicable market or version, uncertainty and any condition that changes the decision.
ResponsibilityName the accountable owner, reviewer or approver, unresolved dependency and next valid destination. A state without a responsible person cannot explain who should act.

A finished draft can still fail its checks

Consider a fictional editorial process. A draft has finished its writing stage, but a source does not support one of its factual claims. Calling the draft complete would hide the failed evidence check and allow the unsupported claim into schema and publication.

The reviewer records FAILED_VALIDATION for the affected draft version, identifies the claim and source, and assigns the repair. The writer removes or corrects the claim, or obtains evidence that supports it. The repaired unit returns for checking. A successful check can open the next permitted approval or handoff; it does not erase the earlier finding.

If the repair depends on a source that is not yet available, record the blocking dependency and who can resolve it. Do not replace the failure with “complete” because the next team is available. Mark dependent schema or publishing work for another check when it relied on the disputed claim.

Two reference binders beside page drafts and a separate paper record held by an amber clip. — A completed draft can remain on hold when its evidence fails review.

Keep failure, blocking and exceptions distinct

A failed check means a test did not pass.The record should identify the defect and the review that found it. The next action is a repair and an appropriate retest.
Blocked means a dependency prevents progress.The dependency may follow a failure, but it explains why the repair or next action cannot proceed. Identify what must change before work resumes.
Deferred evidence remains unresolved.Record the missing evidence and condition for later review. Deferral does not support a stronger claim or authorize work that requires that evidence.
Not applicable needs a reason.Explain why the requirement falls outside the current scope. An exception is not a convenient way to bypass a failed requirement.
A new check reopens a previous decision.A changed source, version, scope or identity can invalidate a formerly accepted result. Preserve the old version and identify which dependent work needs another check.

Navy and cobalt folders beside a website model, magnifying glass and amber token. — Carry the reviewed version and its evidence into the next responsibility.

Test the dictionary before a handoff

Collect the labels people already use.Include briefs, active work, review, approvals, publishing and monitoring. Look for one label being used for different conditions.
Define the conditions and permitted moves.Write entry and exit rules as observable events. Include prohibited transitions so completion cannot bypass review.
Try the awkward cases.Walk a failed draft, stale source, missing dependency, deferred requirement and partially applicable task through the proposed states.
Review the complete record.Accept a definition only when its meaning, transition rules, evidence scope and responsible owner are all explicit. Confirm that required rights, permission and human approvals are still represented.
Transfer the accepted version.Carry the dictionary, source state, review date, unresolved items and next responsibility into the handoff. A failed, unsupported or stale record must not silently become an input to later production.

Questions about process states

When is a state dictionary useful?

Use it when people, agents or systems exchange work and an informal label could hide a different operational condition. The benefit is a shared meaning and a reviewable next action.

Are checks the same as human approval?

No. A check tests a defined requirement; human approval authorizes a decision when the process requires a named person to make it. Keep both conditions explicit.

What should a state record preserve?

Keep the definition, entry and exit evidence, permitted transitions, accountable owner, version, review state and next valid move together. Do not detach a state label from its supporting record.

What happens when only one unit fails?

Repair the smallest failing unit and repeat the affected check. Recheck dependent work where the failure changes its inputs, instead of rebuilding unrelated material.

Does a completed state prove an external outcome?

Completion describes work within the stated process and scope. It does not guarantee rankings, indexing, traffic, rich results, citations or other platform decisions.