Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.

Step 04 · Opportunities, versions and approvals

Goal. Drafts, immutable versions, exact-version approval, publication, material revision.

Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.

Prerequisites

Steps 01–03. Policy-independent scaffolding may start only after the overall start conditions are met (statement of work, ready-to-start kickoff checklist, funded DG-owned accounts, region and identity provider chosen). Decision-dependent behaviour and its final oracle stay blocked until DG chooses the applicable rule. Proposed defaults are recommendations, never prerequisites. Any provisional synthetic exploration must be labelled reversible and unapproved and is not accepted production behaviour. Blocked until DG decides: approval binding and self-approval (Q02), material-field definition and stale-view rule (Q06). Policy-independent here: draft and version records and the live-version pointer.

Changes (illustrative, not a final schema)

Draft, immutable version and approval records; a live-version pointer; expected-version checks; an event emitted through the outbox helper for material revision.

Build items:

• Draft validation and sanitised rendering
• Immutable published versions and a live-version pointer
• Exact-version approval; self-approval for entitled owner/admin with audit
• Stale-edit rejection with expected version
• Material revision: V1 live while V2 reviewed; recommendation invalidation hook

Expected outputs and invariants

A contributor cannot publish; an edit after approval voids the approval; V1 stays live while V2 is reviewed and the pointer moves only on publishing the approved V2.

Tests-first subset

Primary scenarios of this step (write these tests first): T05, T08, T13, T14, T15, T21, T22.

Assertions to write first: T05 (publication and version visibility), T08 (validation and sanitised render), T13, T14, T15 (publication side), T21 and T22 (V1/V2 mechanics and race harness), T33 (verification for these mutations).

Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Pending decision; no oracle is invented.

Deferred integration checks

Scenarios whose primary step is this one but whose full variants need later components:

• T05 — needs step 05: Discovery by search and filters completes it.
• T08 — needs step 05: Search and detail rendering after approval.
• T13 — needs step 06: Formal interest submit bound to the approved version needs step 06.
• T14 — needs step 06: A stale approved send of formal interest or accept needs step 06.
• T15 — needs step 06: Interest-side returned work needs step 06.
• T21 — needs step 05, 06, 07: Recommendation refresh (05), EOI keeping V1 (06) and the safe change alert (07) complete it.
• T22 — needs step 05, 06, 07: Needs recommendations (05), EOI submission (06) and duplicate worker jobs (07).

Follow-up verification brought here

Earlier scenarios that can only be completed or rechecked once this step exists:

• T02 — Publish (04) and formal-interest submit, accept and message (06) rows complete the matrix; cells depending on pending Q02 stay Pending decision.
• T16 — Needs real publish/approve (04) and accept (06) commands to race.
• T27 — Applies entity by entity as drafts, search results and conversations are built.
• T33 — Verified for each real event-producing mutation as it is built; delivery in 07.
• T39 — Core screens exist only after those steps; measured at step 10 on the integrated build.

Decisions DG must settle (dependent behaviour stays blocked until DG chooses)

Q02, Q06

Exit evidence

Publication-side assertions reported on a named build. For T05, T08, T13, T14, T15, T21 and T22 only partial verification is possible until discovery, formal interest and the worker exist.

Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).

Navigation: Step-03-Policy-Pipeline-and-Isolation-Harness ← this step → Step-05-Discovery-and-Rule-Ranking · Implementation-Order-Overview