In this chapter
3.1 Separate observation, testimony and assumption
A useful current-state chapter explains how a finding was obtained. “Users say reporting is unreliable” is testimony. A sampled report that cannot be reconciled is an observation. An expectation that every branch has the same problem is an assumption. All three can guide discovery, but they have different evidential weight. The fictional baseline contains spreadsheets, email approvals, a legacy application and manual exports. No investigation of a real institution is implied. Candidate sample sizes and test windows must be agreed according to access, risk and the diversity of journeys rather than presented as a statistically representative audit.
3.2 Assess one complete transaction
Select a permitted sample of completed, rejected and changed requests. Reconstruct the submitted content, actor authority, approval version, fulfilment record and reporting inclusion. Note where the chain becomes uncertain. Capture minimal evidence with redaction and an agreed retention rule; copying an entire production database is not a default discovery activity.
| Evidence ID | Scenario observation or unknown | Classification | Next verification |
|---|---|---|---|
| EV-01 | Different office reference conventions | Constructed finding | Compare permitted reference samples |
| EV-02 | Approval version not linked to execution | Constructed finding | Trace one amendment through fulfilment |
| EV-03 | Backup success is reported, restore time unknown | Explicit unknown | Perform an authorized isolated restore |
| EV-04 | Branch interruption duration not measured | Explicit unknown | Review incident history and a connectivity sample |
3.3 Examine the system as operated
Map authentication, data stores, integrations, scheduled jobs, release procedure, backup locations and support responsibility. Include manual workarounds. A spreadsheet emailed after a failed export is part of the operating system even if it is absent from the software diagram. Evaluate access with positive and negative tests appropriate to the authorized scope. Review how configuration is changed, who can access secrets and whether a departed user can still act. Do not execute disruptive tests or extract sensitive records without an agreed test boundary.
3.4 Baselines before targets
| Dimension | Baseline to establish | Candidate method |
|---|---|---|
| Workflow time | Time between accepted request and final decision | Timestamp sample with exception reasons |
| Reporting quality | Missing, duplicate and unexplained records | Reconciliation of a known period |
| Recovery | Last recoverable state and restore duration | Isolated restore with record checks |
| Support | Repeated manual interventions and ownership gaps | Incident and release walkthrough |
A baseline describes the sample and its limitations. Do not convert a small demonstration into an institution-wide percentage. The output is a defensible starting point for decisions, not a maturity score designed to make the proposed solution look necessary.
3.5 Assessment package
Publish a redacted system inventory, journey trace, evidence register and open-question list to authorized stakeholders. Each finding references evidence or an explicit assumption. The system owner confirms factual accuracy; the architect remains responsible for the interpretation and recommendation. Unresolved disagreements remain visible in the decision record.