Safe Workflow Lab

1) The problem: a workflow diagram is not safety evidence

A workflow can look correct on paper and still fail when retries, stale approvals, automation, conflicting states and real side effects interact. Testing those behaviors against live content or publishing endpoints creates avoidable operational risk and makes failures hard to replay.

This lesson builds Safe Editorial Workflow Lab Harness v1: an offline synthetic environment that exercises transitions, approval/revision binding, role boundaries, idempotency, fault injection, audit trails and a side-effect firewall before any real release action is considered.

Core rule: the lab may simulate failure realistically, but it must not be capable of producing a live side effect.

2) Lesson boundary

COM-019 owns the Safe Workflow Lab. COM-018 owns Client Approval States and Revision Branching; COM-020 owns Guided Onboarding and Progressive Disclosure. This lesson does not redesign those adjacent contracts. It tests bounded inputs derived from them.

The lab also does not create production credentials, publishing authority, billing authority, tenant mutation or customer-system access. Its output is replayable evidence for human release review, not release authority itself.

3) Mental model: Fixture → Event → Assertion → Replay → Human Review

Preserve this sequence for every run:

1. versioned synthetic fixture;
2. explicit initial state;
3. deterministic event sequence;
4. actor role and transition contract;
5. expected and actual state;
6. approval bound to the correct revision;
7. blocked side-effect mode;
8. idempotency key for retries;
9. explicit fault injection;
10. audit events and assertions;
11. replay reference;
12. bounded result for human review.

4) Why synthetic fixtures matter

A fixture is more than sample data: it is a reproducible snapshot of the conditions that define a run. If inputs, workflow version, event order or revision change without being captured, the next failure is no longer comparable to the first one.

Each fixture therefore carries its own identifier, synthetic item, workflow version and evidence reference. Real customer identifiers, tokens, API keys and production endpoints are forbidden. That limitation is part of the safety contract, not a weakness of the lab.

5) Provenance: what, who and which activity?

W3C PROV-O defines Entity, Activity and Agent as starting-point concepts for provenance. In this lesson, that model is used narrowly as a provenance pattern: a fixture or artifact can be an Entity, a transition execution can be an Activity, and an actor/test runner can be an Agent.

PROV-O does not itself prescribe workflow safety, idempotency or release gates. Those are MAKNOW design decisions. The limited use here is traceable lineage for runs and evidence.

6) Separate platform automation from authority

Current Contentful documentation shows that workflows can define steps and connect them to rules/actions, notifications, tasks and automations. That is a FACT about a platform capability, not architectural authority for MAKNOW.

An automation passing a validation task therefore does not gain permission to publish. Local contracts, revision binding, assertions and the human release gate must still pass. Vendor capability and release authority are different things.

7) The side-effect firewall

Inside the Safe Workflow Lab, side_effect_mode must be BLOCKED or an equivalent strict no-op. Even when every assertion passes, the evaluator must not publish, send real email, trigger payment, call an external webhook or mutate a live CMS.

A safe pattern is to replace live adapters with fakes, omit real endpoints entirely, convert external actions into synthetic events, block any LIVE_* mode or production credential, and retain release authority outside the lab.

8) Idempotency and retry

Retries are normal; duplicate side effects are not. If the same transition executes again, an idempotency key must bind it to the already-known operation. Without that protection, a retry can duplicate an approval event, notification or transition.

The lab explicitly replays one transition twice. If idempotency protection is removed, the result must not be success; it becomes BLOCKED_IDEMPOTENCY or an equally bounded state.

9) A stale approval is not a valid approval

Approval must bind to a specific revision. If revision r17 was approved and the item later changes to r18, reusing the old approval is unsafe. The lab must detect this mismatch deterministically.

Trust in the reviewer is not the repair. Evidence is the repair: approval_revision_ref must match the active revision in the fixture. Otherwise the run remains stale/blocked until new review evidence exists.

10) Fault injection and audit completeness

A useful lab intentionally injects failures. At minimum, test: a live side effect, a stale approval revision, duplicate replay without idempotency, a failed event omitted from audit, expected/actual mismatch, and missing decisive evidence.

Every failure must be visible in the audit trail and reconstructable through replay. Hiding a failed event makes the result incomplete even if the final state looks correct, because the decision can no longer be audited faithfully.

11) Evidence contract and state vocabulary

The artifact has 22 fields: lab_run_id, fixture_set_id, workflow_version, synthetic_item_id, initial_state, event_sequence, actor_role, transition_id, expected_state, actual_state, approval_revision_ref, evidence_fixture_ref, side_effect_mode, idempotency_key, fault_injection, retry_count, audit_event_ids, assertion_result, replay_ref, failure_class, owner, evidence_ref.

Eighteen are critical to the bounded decision. Practical states include READY_FOR_HUMAN_RELEASE_REVIEW, HOLD_MISSING_EVIDENCE, BLOCKED_SIDE_EFFECT, BLOCKED_STALE_APPROVAL, BLOCKED_IDEMPOTENCY, BLOCKED_ASSERTION, PARTIAL_AUDIT_GAP and BLOCKED_SCOPE.

12) Lab and transfer: an optional legal-review branch

The offline lab contains eight fixtures. Each fixture exposes six key invariants, while an internal oracle executes 48 deterministic assertions. There are no network calls, credentials or customer records.

Transfer challenge: regulated pages gain an optional legal-review branch. Two conditions must both hold: regulated content cannot become release-ready without the required legal evidence, and non-regulated content must not be forced through legal review.

Bind the branch to content_class and explicit evidence rather than applying it globally. The baseline result is not the oracle; the changed fixture must be recomputed independently.

13) Summary and pass condition

A Safe Workflow Lab makes failure replayable, traceable and incapable of producing live side effects. A run is only ready for human release review when critical evidence is complete, side effects stay blocked, revision binding is valid, retries are idempotent, expected/actual states agree, the audit trail is complete and a replay reference exists.

The lesson output is not a publication. It is an auditable evidence package from which a human reviewer can reconstruct the next decision.

References and freshness

• Contentful Help Center, Workflows / Workflow steps / Workflow automations — rechecked 2026-09-15.
• W3C, PROV-O: The PROV Ontology — foundational Recommendation, rechecked 2026-09-15.
• Fixture rules, the side-effect firewall, idempotency gate and human release authority are MAKNOW DESIGN choices, not claims attributed to those external sources.