The brief: make an approved decision traceable
A fictional institution operates a headquarters and six regional offices. Requests for operational expenditure move through spreadsheets, email and a small legacy application. Finance prepares a consolidated report by reconciling exports. Managers need to know what was requested, who approved it, which amount is authoritative and whether the report is current. The starting question is not which cloud or programming language to choose. It is where an institutional decision becomes authoritative, and how that decision remains explainable.
| Scenario constraint | Working assumption | Evidence needed before contracting |
|---|---|---|
| People and scale | 120 named users; 20 concurrent users; two engineers supporting the service | Access roster, representative traffic and support capacity |
| Connectivity | Branch connections may fail for several hours | Outage history, device and power assessment |
| Information ownership | Sensitive operational records remain under institutional control | Classification, hosting approval and retention decisions |
| Recovery | Candidate RPO: 24 hours; candidate RTO: 4 hours | Business impact assessment and successful timed restore |
| Reporting | Daily report by 09:00 Central Africa Time | Owner-approved definitions and reconciliation sample |
01 / Current state: follow one request
The sample journey is request → departmental review → finance approval → fulfilment → reconciliation. In this fictional baseline, each office assigns its own reference, email acts as the approval record and the report combines extracts taken at different times. A corrected spreadsheet can overwrite the version that an approver actually saw. These are deliberately constructed assessment findings, not observations about a named institution.
| Boundary | Authority today | Failure to investigate |
|---|---|---|
| Branch to reviewer | Spreadsheet and email thread | Duplicate reference, missing attachment or uncertain version |
| Approval to fulfilment | Copied status in legacy application | Action performed after approval was changed |
| Operations to reporting | Manual export and reconciliation | Late records and inconsistent reporting cut-off |
02 / Assessment: ask what can be proved
An assessment would sample completed and rejected requests, examine role permissions and compare a report to its source transactions. Interviews explain intended practice; records and tests show actual behaviour. A recovery claim needs a restored environment and an observed duration. An access policy needs negative permission tests, not only a list of roles. Unknowns stay visible rather than being assigned a reassuring score.
- Business owner: validate the approval path and exception authority.
- Finance owner: approve metric definitions, cut-off and reconciliation rules.
- System owner: demonstrate access boundaries, release history and restore procedure.
- Data owner: approve classification, permitted destinations and retention.
03 / Gaps: rank consequences before features
| Priority | Gap in this scenario | Consequence | First verification |
|---|---|---|---|
| P1 | No authoritative approval version | Execution may not match the approved request | Replay a changed request through approval and fulfilment |
| P1 | Restore procedure has not been demonstrated | An incident may prevent recovery within the business window | Restore an isolated copy and verify record completeness |
| P2 | Exports use different definitions and cut-offs | Management compares incompatible figures | Reconcile one known period using an agreed definition |
| P2 | Connectivity retries have no duplicate protection | A repeated submission may create two requests | Retry the same command after an ambiguous timeout |
04 / Principles: make the decision rules explicit
- One authoritative owner for each business fact; copies expose their source and freshness.
- Authorization and workflow transitions are enforced on the server.
- A submitted request records the version of the information being approved.
- A retry must not silently create a second business operation.
- Sensitive data placement and retention follow approved policy.
- Architecture complexity must fit the people who will operate it.
05 / Recommended architecture
Start with a modular application and a relational database. Keep workflow, authorization, operational records and reporting responsibilities explicit within the application. This preserves a single transactional boundary for approval changes without requiring the team to operate several independently deployed services. The choice is provisional: it follows the assumed team size and workload, rather than a rule that monoliths are always preferable.
The browser sends authenticated commands to an application API. The API checks permissions and the expected record version, then commits the approved transition, audit entry and any outbox event in one database transaction. An asynchronous worker handles notifications and builds report projections. Notification failure does not reverse an already committed approval. Consumers must tolerate duplicate delivery; an outbox alone does not establish end-to-end exactly-once processing.
An auditable workflow history is not automatically tamper-proof. Administrative access, database privileges, retention, export verification and backup protection still require design. Attachment storage is a separate access-controlled boundary; it is omitted from the simplified diagram, along with the identity provider and backup destination.
Connectivity is a consistency decision
Phase one preserves a local draft and clearly marks it as unsent when connectivity is lost. No offline approval or execution is treated as final. After reconnection, the client submits with a stable command identifier and expected version. If the request changed while disconnected, the server rejects the stale transition and asks the user to review the current version. Lost responses are reconciled by looking up the command identifier. Offline finalization would require an explicit conflict and delegation policy; it is not promised by adding a cache.
06 / Technology mapping
| Capability | Candidate mapping | Reason and operating obligation |
|---|---|---|
| Business workflow and API | Modular backend; final language selected with maintainers | Clear domain boundaries, permission tests and migration ownership |
| Transactional state | PostgreSQL | Constraints and transactions; test concurrency and restoration |
| Background work | Database outbox and a small worker | Recoverable retries, bounded batches, deduplication and visible failures |
| Attachments | Institution-controlled protected storage | Access checks, limits, retention and backup consistency |
| Deployment | Versioned containers on approved infrastructure | Document patching, secrets, rollback and recovery ownership |
| Reporting | Versioned read models and reconciliation jobs | Expose reporting cut-off, source coverage and rejected records |
07 / Decision records and trade-offs
| Decision | Alternative considered | Accepted cost | Revisit when |
|---|---|---|---|
| ADR-001: modular application first | Independent microservices | Shared release lifecycle; module boundaries need discipline | Separate teams or measured isolation/scaling needs justify the operational cost |
| ADR-002: asynchronous notifications | Send notifications inside the approval transaction | Delivery can be delayed; worker and retry operations are needed | A time-critical delivery requirement is demonstrated |
| ADR-003: drafts offline, approvals online | Allow final approvals offline | A branch cannot finalize during an outage | The institution approves conflict, delegation and reconciliation rules |
| ADR-004: daily reporting first | Streaming analytics platform | Up to one reporting cycle of delay | An agreed decision requires fresher data and the team can support it |
Kafka, Kubernetes and a separate warehouse are not phase-one requirements in this scenario. They may become appropriate when measured throughput, isolation, independent delivery or analytical history needs justify them. Adding them now would create operational responsibilities without answering the highest-ranked gaps.
08 / Verification and phased delivery
| Phase | Deliverable | Exit evidence |
|---|---|---|
| Discover | Approved current-state map, sample records and requirements | Named owners resolve the approval and reporting definitions |
| Design | Boundary diagrams, data model, threat review and decision records | Stakeholders walk through normal, rejected and interrupted journeys |
| Pilot | One branch and one request type | Permission checks, concurrent update tests, retry tests and reconciliation pass |
| Recover | Backup and restoration exercise | Timed restoration meets approved objectives and reconciles known records |
| Expand | Controlled rollout with operating handover | Support ownership, exception handling and reporting freshness are demonstrated |
A useful acceptance scenario submits the same request twice after a timeout and verifies that only one authoritative request exists. Another attempts to approve an outdated version and checks that the audit trail records the rejection without changing the approved state. A third pauses the worker, commits a valid approval and verifies that notification resumes after recovery. These checks test architectural promises rather than component installation.
09 / Executive insight
The recommended investment is an authoritative approval path and explainable reporting, delivered in small verifiable stages. The unresolved business decisions are data placement, retention, branch continuity policy and recovery objectives. No savings, fraud reduction, availability or throughput outcome can be claimed before a baseline and pilot exist. The architecture review produces an evidence-backed decision package; it does not replace institutional authority.