Data and Business Systems
Keep operational status separate from reporting definitions
A status tells operators what work can happen next. A reporting definition tells readers which records belong in a measure. Keep these models separate so a dashboard change does not silently alter workflow behavior.
Teams often stretch one status field to serve operators and management reports. A label such as complete may mean no more work is needed, a customer received a result, or a record qualifies for a chart. Those are different questions. Separate the operational state from the definition used to count and compare records.
Model the work first
Define states around actions and transitions. Ask what staff can do from each state and which event allows the next state. Avoid creating a new operational state merely because a report needs another grouping. A late request can remain in progress while a reporting rule classifies it as overdue.
Give state changes an event time and a reason where needed. OWASP distinguishes an event timestamp from the time the event is logged.[3] That distinction matters when offline work arrives later. Decide which timestamp represents the business milestone rather than automatically using ingestion time.
Write a measure as an explicit rule
For every important measure, state its unit, included population, exclusions, time boundary, and treatment of reopened records. Explain whether the report counts current states or events that occurred during a period. A request completed and reopened can produce different answers under those two definitions.
Recommend a named definition owner and a version when meaning changes. Preserve the ability to explain earlier results without claiming that a revised rule was always in force. Keep the mapping from operational events to reporting categories visible to both analysts and process owners.
Hypothetical example: a support completion chart
A hypothetical support team marks a request resolved when an agent finishes the proposed remedy. Management wants a chart of requests accepted by the requester. Instead of renaming resolved, the team records acceptance separately and defines the chart around that event.
Requests awaiting confirmation remain visible in operations. The chart explains its exclusion of unconfirmed remedies and the cutoff used for acceptance. This model adds a milestone and another definition to maintain, but it avoids making agents change workflow status just to satisfy a reporting convention.
Review differences before comparing results
Run example records through both the workflow and the reporting rule. Include cancellation, reopening, late events, and records with missing milestones. Ask a process owner and a report reader to explain each result in ordinary language. Disagreement reveals a definition problem before it becomes a performance argument.
Separation has a cost. More explicit definitions require ownership and testing. Do not create dozens of near-identical measures without a decision need. Prefer a small, documented set with clear names and a drill-through view that shows which records contributed. Place the definition beside the measure so a reader can check meaning without asking the application developer.
- Define actions allowed in each operational state.
- Specify the event and timestamp behind each measure.
- Document exclusions and treatment of reopened records.
- Name a reporting owner and definition version.
- Test boundary cases against visible contributing records.
