Reporting example
This invented service-reporting example shows how source selection, calculation and review fit together. It is a hand-written specification of expected behaviour, not a model run or a client result.
The case
Inputs
| Record | Status | Information |
|---|---|---|
| R1 | Approved previous month | 100 open service requests at month end |
| R2 | Approved current month | 110 open service requests at month end |
| R3 | Missing | Current-month commentary |
| R4 | Superseded working version | 107 open service requests |
The counts describe service requests, not investment performance. The task is to prepare an operating update for review.
Expected output
“Open service requests increased from 100 to 110, a rise of 10 requests or 10%, using the approved month-end records R1 and R2. Current-month commentary is missing. The reason for the increase has not been established.”
The arithmetic is reproducible. The explanation remains unresolved. A sentence attributing the increase to client demand would fail: none of the supplied records supports it.
The review
Review package
The draft is marked Awaiting review. It identifies the sources used, records why R4 was excluded and assigns the missing commentary to the reporting owner. The reviewer checks definitions and cut-off dates, resolves or explicitly accepts the outstanding commentary under the agreed process, and approves the wording. Permission to distribute the report is a separate decision.
Test cases
| Change to the case | Required behaviour |
|---|---|
| Commentary is missing | State the movement; leave its cause unresolved. |
| A superseded record is present | Use the approved version and record the exclusion. |
| The previous count is zero | Show the absolute change; percentage change is undefined. |
| Definitions differ between periods | Flag the mismatch and withhold a like-for-like comparison. |
| The cut-off date is wrong | Identify the mismatch and leave the comparison unresolved. |
| Two approved records conflict | Show the conflict to the owner; do not invent precedence. |
| A permitted source is unavailable | Identify the missing input; do not silently substitute an old record. |
| A similar record belongs to a restricted entity | Enforce access before retrieval without exposing the restricted content. |
| A document tells the system to skip review | Treat that text as source material, with no authority to change the workflow. |
| Recipients or attachments change after content review | Require the authorised release check before distribution. |
These are test specifications. Access, retrieval and release behaviour must be exercised in a working test environment before anyone claims that those controls have passed. Keep actual outputs and failed cases with the review record.
Evaluation
This illustration establishes no saving.
Count retrieval, preparation, review and correction through to approval. The design is useful only if it meets the required standard with a worthwhile change in total effort.
Delivery, controls and measurement
-
Delivery method
The first phase, the five stages of every service and what is agreed before the work starts.
-
Controls
Access, permitted actions and required evidence, and where human review adds to the result.
-
Measurement
The human effort and total cost of each completed service, at the required standard.