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 03 · Policy pipeline and isolation harness
Goal. The single request pipeline and the isolation/race harness, built before feature work depends on it. The harness is applied entity by entity as later steps create them.
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 and 02. 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: the revocation and in-flight boundary (Q07), the DG metadata allowlist (Q08), session and retention policy (Q09). Policy-independent here: the pipeline skeleton, the canary fixture and the race harness.
Changes (illustrative, not a final schema)
The request pipeline, the denial-response shape, session and link invalidation, the three-company canary fixture and the race-injection harness. No new business entities.
Build items:
- Pipeline: authenticate → resolve membership → authorise record → validate version/transition → commit mutation + event
- Safe denial shape (no existence leak)
- Session and saved-link invalidation on revocation
- Three-company fixture with canary text per private engagement
- Race-injection harness for approval, accept and revocation races
Expected outputs and invariants
Every enabled route passes through the pipeline; denials never reveal existence; revoked sessions and saved links stop working; the harness can race two commands.
Tests-first subset
Primary scenarios of this step (write these tests first): T16, T25, T27, T28, DG22.
Assertions to write first: T25 (session and saved-link part), T27 (harness on existing entities), T28 (negative boundary on existing DG roles), DG22 (existing routes), T16 (race mechanics on identity actions).
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:
- T16 — needs step 04, 06: Needs real publish/approve (04) and accept (06) commands to race.
- T25 — needs step 06, 07: Revoked access to engagement records needs 06; suppression of a queued email needs the worker (07).
- T27 — needs step 04, 05, 06: Applies entity by entity as drafts, search results and conversations are built.
- T28 — needs step 06, 09: Message bodies exist only after 06; the DG tool and metadata view (09) complete it.
- DG22 — needs step 06, 09: Needs engagement records (06) and the DG metadata view (09).
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- T01 — Re-check the safe-denial shape and audit once the pipeline exists.
- T37 — Needs actual identity, role and revocation behaviour (02, 03), protected DG admin operations with MFA (09) and an integrated recheck (11).
- DG25 — Safe-denial and audit re-check once the pipeline exists.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
Harness operational on the entities that exist at this step. For T16, T25, T27, T28 and DG22 only partial verification is possible here; their publish, accept, queued-email and message-body assertions need steps 04, 06, 07 and 09. No early gate here implies those later scenarios have passed.
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-02-Identity-Membership-Roles ← this step → Step-04-Opportunities-Versions-Approvals · Implementation-Order-Overview