Content Workflow States

1) Why Draft / Done / Published are not enough

Editorial teams often use familiar labels such as Draft, Done and Published, but those labels alone do not say who may move an item, which evidence is required, where rejection returns, or how far automation may go. If an AI rewrite job finishes and the item moves straight to Published, task completion has been confused with release authority.

This lesson builds Content Workflow State Machine v1: a bounded auditable state machine with explicit transitions, actors, permissions, evidence, human gates, rework and audit events.

Core rule: completing a task is not permission to cross a workflow boundary; each transition needs its own authority and evidence.

2) Lesson boundary

COM-017 owns Content Workflow States. COM-016 owns Asset Provenance and COM-018 owns Client Approval States and Revision Branching. This lesson does not absorb client revision branching or asset provenance.

It also does not create live publication, billing changes, tenant mutation or legal authority. The output is an evidence-backed model and synthetic offline lab.

3) Mental model: State → Transition → Actor → Permission → Evidence → Audit

For every transition, the reviewer should be able to answer: where did the item come from, where is it going, what transition is being executed, which actor role is acting, was permission granted, what evidence is required, is a human gate mandatory, where does rejection return, and which audit event records the change?

When decisive evidence is absent, the system should not guess success. HOLD and BLOCKED are valid typed outcomes.

4) Separate external facts from MAKNOW design

Current Contentful documentation shows that Workflows can define content-development steps, control who may change workflow steps, and attach actions such as notifications, tasks and AI actions. Some steps may also be configured to auto-complete. Those are product facts.

They do not imply that automation should own approval or publication authority. Human-gate placement, state names and the transition matrix in this lesson are MAKNOW design rules.

5) State is not task status

current_state must represent operational workflow meaning rather than the status of one job. The bounded baseline path is:

INTAKE → DRAFT → REVIEW → APPROVAL → PUBLISH_READY → PUBLISHED

with the repair loop:

REVIEW → REWORK → REVIEW

A successful AI rewrite may prepare evidence or route work for review; job success alone is neither APPROVAL nor PUBLISHED.

6) Make the transition contract explicit

Every state change names transition_id, from_state and to_state. Any edge outside the permitted matrix becomes BLOCKED_INVALID_TRANSITION.

This prevents shortcuts such as DONE → PUBLISHED: Done is neither publication evidence nor an authorized state in this bounded machine.

7) Role is not permission

actor_role describes a function; permission_check proves whether that actor may execute this specific transition. An Editor can have edit rights while lacking release rights.

Therefore permission_check=DENIED must yield BLOCKED_PERMISSION, even when the role name sounds appropriate. UI access and seniority are not permission evidence.

8) Separate human gates from automation boundaries

In this lesson, entering Approval and the final transition to Published are human-authorized boundaries. Automation may draft, validate, notify or route work, but it may not silently cross those human gates.

If automation_action executes the approval transition directly, the result must be BLOCKED_AUTOMATION_AUTHORITY even when the automation technically succeeded.

9) Rejection needs a real return path

Review is not only a success path. When the result is REJECTED or CHANGES_REQUESTED, the workflow needs a specific rejection_reason and rework_ref so the item can return to repair.

Removing this route creates a workflow that displays states but cannot operationalize failure. The bounded outcome should remain BLOCKED_TRACEABILITY until rework evidence exists.

10) Audit events are part of the transition

Every state mutation needs an audit_event_id and evidence_ref. If the state changes but the log only says “job completed,” a reviewer cannot reconstruct who acted, with which permission or on what evidence.

Missing audit evidence must remain HOLD_MISSING_EVIDENCE, not a fabricated success state.

11) Lab: eight fixtures and 48 assertions

The lab is fully offline, synthetic and contains no credentials or real tenant data. Eight fixtures each test six deterministic invariants for 48 assertions total.

Cases cover baseline approval, automation bypass, rejection without rework, DONE → PUBLISHED, an audit gap, permission denial, controlled publication and conditional legal review. The goal is not merely a green baseline; each failure must expose the exact contract it violates.

12) Transfer: require Legal Review only where needed

The transfer scenario makes Legal Review mandatory for one content class but not for others. A weak design either omits the new gate everywhere or forces every item through it.

The bounded design uses an explicit condition: when legal_review_required=true, Approval is blocked until legal_review_passed=true. Other content classes keep the ordinary route. The new control therefore has scope rather than becoming global friction.

13) Summary and pass criteria

Passing COM-017 means constructing Content Workflow State Machine v1 with explicit permitted transitions, actor, permission, required evidence, human gates, rejection/rework and audit events. You must also reject shortcuts such as automation-owned approval, permission bypass and Done=Published.

The final artifact is not publication authority; it is a bounded auditable decision model.

References and freshness

• Contentful Help Center, Workflows — rechecked 2026-09-15.
• Contentful Help Center, Workflows steps management — rechecked 2026-09-15.
• Contentful Help Center, Workflow automations — rechecked 2026-09-15.
• Human approval/publication gates, state vocabulary and conditional legal review are MAKNOW DESIGN, not vendor requirements.