Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.

Step 03 · Policy pipeline, roles and isolation harness

Goal. The central policy service, the role set, privileged-access controls and the harness that proves tenant and role isolation.

Blueprint delivery stage: Stage 2 (Delivery-Options-Comparison).

Former 1.3 name: Policy pipeline and isolation harness. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-03 label stay valid.

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, 02 as needed by the table in Dependency-and-Regression-Table; the strict prerequisite is the previous step’s exit evidence. Policy-independent scaffolding may start after the overall start conditions; decision-dependent behaviour and its final oracle stay blocked until the named authority decides. Proposed defaults are recommendations, never prerequisites. Blocked decisions: GQ03-staged, GL01-staged, Q02, Q07, Q08, GL03-staged.

Changes (illustrative, not a final schema)

Sources: Blueprint pages cited per item (GGA-Requirement-Register).

Build items:

• Central policy check on every request, export, file download and background action; deny by default (pp. 3, 17)
• Role set: visitor, registered company, eligible owner or colleague, approved partner, operations, finance, technical administrator, convener (p. 3)
• Three-company canary fixture with canary data in every owned record and file; role-by-route-by-company matrix (pp. 12, 13, 17)
• Indistinguishable denial: 404 where existence must stay private (p. 15)
• MFA for privileged staff; logged exceptional technical access; reason required for sensitive overrides and exports (pp. 3, 17)
• Database row policies tested with the real application role while keeping application checks (p. 17); race-injection harness (p. 18)

Expected outputs and invariants

A changed company, record or file ID exposes nothing; finance cannot read capability files; a non-finance user cannot record a settlement; role changes apply on the next request.

Tests-first subset

Primary scenarios of this step (write these tests first): T02, T26, T27, T28, DG22, GS05-staged, GS17-staged, GS26-staged.

Assertions to write first: new GGA scenarios GS05-staged, GS17-staged, GS26-staged. Legacy scenarios whose primary step is this one: T02, T26, T27, T28, DG22. Each follows its replacing GS scenario; the 1.3 text is history (Scenario-Dispositions).

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 Blocked by that decision; no oracle is invented.

Deferred integration checks

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

• T02: needs step 04, 06, 09 (through GS17).
• T26: needs step 04, 05, 06, 08, 09 (through GS05, GS17).
• T27: needs step 04, 06, 09 (through GS17).
• T28: needs step 04, 06, 09 (through GS17, GS26).
• DG22: needs step 04, 06, 09 (through GS17, GS26).
• GS05-staged: needs step 05, 06, 08. Enforcement on discovery (05), pitch (06) and registration (08).
• GS17-staged: needs step 04, 06, 09. Routes are added in 04, 06 and 09; extend the matrix each time.

Follow-up verification brought here

Scenarios (of any step) that can only be completed or rechecked once this step exists:

• None.

Decisions GGA must settle (dependent behaviour stays blocked until the named authority decides)

GQ03-staged, GL01-staged, Q02, Q07, Q08, GL03-staged

Exit evidence

The isolation harness runs on a named build against every route that exists; routes added later extend the matrix (GS17 stays open until steps 04, 06 and 09).

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