In this chapter
14.1 Move through evidence gates
A roadmap is a dependency and risk sequence, not a calendar decorated with milestones. The institution should know what must be learned or demonstrated before the next investment. Durations and budgets are agreed after scope and access are known. The proposed sequence begins with discovery, designs one authoritative journey, pilots it at one office, exercises recovery and expands only after the operating contract works. It preserves an explicit fallback during migration and does not treat data import as proof that business meaning survived.
14.2 Phased delivery
| Phase | Deliverable | Exit evidence | Accountable owner |
|---|---|---|---|
| Discover | Current map, evidence and approved definitions | Owners resolve authority and reporting rules | Business sponsor |
| Design | Boundaries, model, contracts and threat review | Normal, rejected and interrupted journeys explained | Architecture owner |
| Pilot | One office and one request type | Permission, concurrency, retry and reconciliation checks | System owner |
| Recover | Protected backup and restoration exercise | Approved recovery objectives demonstrated | System owner |
| Expand | Controlled rollout and handover | Support, coverage and freshness demonstrated | Business and system owners |
14.3 Migration and coexistence
Identify which source remains authoritative at every stage. Avoid a transition where two applications can approve the same request independently without a reconciliation rule. Plan reference mapping, data quality treatment, cut-over verification and a controlled way to pause or reverse expansion. Historical records may be incomplete. Record their provenance and limitations rather than manufacturing missing approvals. Decide how legacy evidence remains accessible and who may correct it.
14.4 Acceptance scenarios
| Scenario | Required observation |
|---|---|
| Lost response after commit | Retry retrieves the original result without new work |
| Stale approval | Changed content requires renewed review |
| Wrong organizational scope | Action is refused and evidence is retained appropriately |
| Worker interruption | Committed decision survives; deferred work resumes |
| Repeated input | Reporting total is not doubled |
| Late correction | Defined revision policy is applied and explainable |
| Restore | Known records, attachments and dependencies reconcile |
Acceptance tests require a known initial state and expected result. Keep records of version, environment, scope and observed behaviour. A demonstration on a laptop does not establish production capacity or institutional compliance.
14.5 Handover and closure
Handover includes operating responsibilities, access, runbooks, support expectations, unresolved risks and the next review trigger. The institution accepts the outcome against agreed evidence; completion does not erase open limitations. A delivery phase may be stopped if its assumptions fail. ZAF should make that decision legible before sunk cost turns a weak design into an irreversible commitment.