Stage History and Breaches

Stage history records how long a case spent at each point in its lifecycle. It is what turns a set of deadlines into an understanding of where time actually goes.

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

Why stage history matters

When a statutory deadline is missed, the useful question is not who had it at the end but where the time went. A case that breached at twenty days having sat unallocated for twelve has an allocation problem, not a caseworker problem. Without stage history, the investigation is a reconstruction from memory.

Breaches

A breach is recorded rather than inferred, so it can be reported on, explained and counted. Record the reason where one exists — an obligation breached because the complainant did not respond is a different thing from one breached because nobody picked it up, and a count that conflates them is not useful to anybody.

Reporting

Obligations and their stage history are queryable like any other datastore, so a performance return showing responses within statutory timescales is generated rather than assembled. That is usually the immediate reason a service adopts obligations at all.

Use it to change the process

The pattern to look for is a single stage consuming most of the window. That is where the intervention belongs — adding a reminder two days before the deadline does not help if the case spent three weeks waiting for a decision that took ten minutes.