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 10 · Operations console, recovery and hardening

Goal. The operations queues and runbooks, backups and restore, the performance scenario, correction, export and deletion, accessibility and handover.

Blueprint delivery stage: Stage 4 (Delivery-Options-Comparison). Blueprint Stage 4 needs production monitoring, operational training, staffed support and live country-partner sourcing.

Former 1.3 name: Hardening and operations. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-10 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, 03, 04, 05, 06, 07, 08, 09 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: GL01-staged, GL04-staged, GL07-staged, Q09, Q11.

Changes (illustrative, not a final schema)

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

Build items:

• Operations and finance console: queues for profile exceptions, listings, consent delays, failed jobs and invoices with owner, age, next action, audit history (p. 10)
• Resolve a review, a failed message and an expired consent without the convener (pp. 10, 18)
• Daily backups; restore in staging; repeat monthly in the pilot; encrypted, access-restricted backups (p. 17)
• Performance scenario: 100 companies, 1,000 listings, 25 concurrent users, 95% under 2 seconds, measured (p. 17)
• Correction, export and deletion workflows across files, indexes and restores; retention by record type (p. 17)
• Keyboard, labels, contrast and mobile layout; empty, loading, validation, locked, expired and retry states (p. 10)
• Handover package: repository, dependencies, migrations, field dictionary, API contract, policies, sample data, operations guide, monitoring, configuration register, cost estimate (p. 19)

Expected outputs and invariants

Operations can run the service without the convener; the owner can export the essential business records in a documented format.

Tests-first subset

Primary scenarios of this step (write these tests first): T39, T40, GS20-staged, GS21-staged, GS27-staged.

Assertions to write first: new GGA scenarios GS20-staged, GS21-staged, GS27-staged. Legacy scenarios whose primary step is this one: T39, T40. 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:

• None: the scenarios of this step can be completed here.

Follow-up verification brought here

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

• GS30-staged: Monitoring and cost reporting are completed in 10.
• GS31-staged: Every screen must be exercised; final audit in 10.

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

GL01-staged, GL04-staged, GL07-staged, Q09, Q11

Exit evidence

Restore evidence and measurements exist for a named build; GS20, GS21 and GS27 can be verified here and GS31 gets its final audit here. Proposed targets are measured, not treated as thresholds, until GL07 records them.

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-09-DG-Membership-Tool-and-Metadata ← this step → Step-11-UAT-and-Release · Implementation-Order-Overview