How do you compare branch reports that define completion differently?
Format: Article.
Check what the words mean before you compare totals. Match each branch's status to a shared meaning. Keep cases you cannot match in their own group. Add only records that meet the same rule. “Complete” may mean work ended, the office closed a file, or staff removed an item from a queue.
Do not rank branches from those labels alone. A branch that records supervisor acceptance may look slower than one that records a worker's submission. The difference may be the measurement, not the work.
Ask what event the number represents
Ask what makes the completed count go up in each report. Who may record that event? What proof do they need? Check whether the report counts requests, tasks, visits, or cases. One request may hold several tasks. Do not add a request count to a task count as if they meant the same thing.
NIST's AI Risk Management Framework calls for records of test cases and measures. It also calls for checking whether the measures still fit and the controls still work. [S08] It is not a branch reporting standard. The metric dictionary below is a list of what each measure means. We propose it as a tool to use before AI drafts a comparison.
Do not use AI to guess a mapping from similar column names. Ask the report owner to confirm it against real records and the actual query or export definition.
Create this metric dictionary
| Dictionary field | What to record |
|---|---|
| Metric name and version | Plain name, owner, and date this definition applies |
| Unit counted | Request, task, visit, or case with a stable identifier |
| Operational completion | Exact event that establishes the agreed work is finished |
| Administrative closure | Exact event that closes the office record |
| Unknown state | Records missing evidence or lacking a reliable mapping |
| Period and cutoff | Time zone, event date used, and extraction time |
| Inclusion and exclusion | Canceled, duplicate, reopened, transferred, or test records |
| Source and verification | Report definition, export reference, and reviewer |
| Revisions | How later corrections affect previously issued totals |
Keep the shared meaning beside each local field. A “closed date” may show only when staff closed the office record. That is administrative closure. It may not show when the actual work ended, called operational completion. If that date is missing, mark it unknown. Do not copy the close date into its place.
Set a rule for reopened work before you compare reports. You might show files closed this month beside cases still open at cutoff. Label both counts. Say if you remove reopened cases from a count. If you count unique cases, do not count the same one twice.
Apply a comparable-report gate
Use three outcomes for each proposed comparison:
- Comparable: the reports count the same thing, for the same period, under the same rules. The sources support that match.
- Comparable after a stated change: source records support a change that a reviewer can check.
- Not comparable yet: a needed definition or record is missing.
Each change needs a reason, source, and owner. A branch file may include test records that staff can clearly identify and remove from the count. But one total with no source rows cannot tell you which closed files mean the work was done.
Keep the old report beside the changed result. Do not replace a branch's past count just to make a shared screen look neat. Gather only source rows you may see. A central report does not give you access to every client's files.
Hypothetical example: the same label, different events
A fictional service company compares Branch River with Branch Hill. River marks a task complete when the worker submits the work report. Hill marks it complete after a supervisor accepts that report. Both exports use a column named “Completed.”
The reporting lead does not publish a league table. Instead, the lead asks River for acceptance records and Hill for submission records. Where both events exist, the reports can show submitted work and accepted work as separate measures using a shared period rule.
Some old River records have no sign-off event. Mark them unknown in the accepted-work report. Do not count them as failures or assume they passed. Do not drop them without saying so. Show the owner the gap instead of a claim about how well the branch worked.
Check the first combined report by hand
Choose cases that test what the count means. Include normal finished work, a reopened task, a canceled request, and a transfer. Add a record close to the cutoff time. Trace each from source to final group. These proposed tests are not a benchmark or a sample that proves the whole set is correct.
Have each branch owner approve the field matches. Have the shared report owner approve the comparison. If meanings change later, save a new version of the dictionary. Say whether you recalculated old reports. Explain changed meanings before claiming that the work got better or worse.
Core Agentic can discuss a custom tool to draft reports with clear source meanings and human checks. It is not a finished enterprise reporting product. We would agree on each data link, any use of cloud services, and who may see shared records.
Book a Demo to discuss a branch comparison your team can defend record by record.
Sources
- NIST: AI RMF Core - AIRC.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.