Portfolio Control
How do we monitor litigated cases off budget or off plan without reading every file?
Updated July 2026
You stop reading files and start watching exceptions. Define what off budget and off plan mean as thresholds, spend past authority, a stalled matter, a venue change, a demand spike, then let the system flag the matters that cross them. Instead of reviewing hundreds of cases, you review the handful that broke a rule. Oversight becomes exception-based, not file-by-file.
What does exception-based oversight actually mean?
It means you watch for the cases that break a rule instead of reading all of them. You set thresholds that define off budget and off plan, then the system surfaces only the matters that cross a line. A file behaving normally never reaches your desk. The exceptions do. Your attention goes to the small set of cases that actually need a decision.
- Set thresholds once: what counts as off budget and off plan for your program.
- The system watches every matter continuously against those rules.
- Only the matters that cross a threshold surface for review.
- Cases behaving normally stay silent, so your hour goes to the exceptions.
What thresholds flag a case as off budget or off plan?
The ones you can define from data you already track. Off budget is spend crossing a percentage of authority or a stage estimate. Off plan is a case that stalls, changes venue, sees a demand jump, or blows a key date. Each is a rule the system can watch continuously. When a matter trips one, it moves to the top of your review queue automatically.
| Threshold type | What trips it | The signal it catches |
|---|---|---|
| Off budget | Spend crosses a set share of authority or stage estimate | A matter running hot before anyone reads the invoices |
| Stall | No activity for a set number of days | A case going quiet, which often precedes trouble |
| Venue change | Matter transfers to a flagged jurisdiction | Exposure rising because of where the case now sits |
| Demand spike | Recorded demand jumps past a set threshold | A plaintiff anchor climbing before it hardens |
None of these require a prediction. They are counted conditions the system can check against every matter, so a rule you set once keeps watching long after a human review would have moved on.
Where do the signals come from without reading every file?
From the structured facts in the reports your defense counsel already file. CaseGlide's Case Clerk AI reads those status reports, not your email or work product, and pulls out venue, posture, spend, key dates, and status. Those facts feed the thresholds. So a venue change or a demand spike buried in a paragraph becomes a flag, without anyone reading the underlying file to find it.
- Defense counsel file status reports the way they already do.
- Case Clerk AI reads those reports only and extracts the structured facts.
- Those facts feed the thresholds you defined for off budget and off plan.
- A matter that crosses a line surfaces automatically, with the facts attached.
What happens when a case trips a flag?
It surfaces for a decision, with context attached. The matter moves to your review queue tagged with which rule it broke and the facts behind it: the venue, the spend, the posture, what changed. You are not hunting for the problem. You are deciding what to do about one the system already found. Most cases never flag, so your hour goes to the few that do.
- The matter surfaces tagged with the rule it broke, not as raw data to sift.
- The facts behind the flag come with it: venue, spend, posture, and change.
- You decide the action; the system does the finding.
- Everything quiet stays quiet, so the queue holds only what needs judgment.
Does exception-based monitoring miss quiet problems?
Only if your thresholds are wrong, which is why they are tunable. A case going quiet is itself a flag: no activity for a set number of days trips a stall rule. The risk is not the exception model. It is watching nothing at all, or watching everything and seeing none of it. Well-set rules catch the silent drifter that a file-by-file review, run monthly, would miss for weeks.
- A stall rule turns silence itself into a flag, so quiet cases are not invisible.
- Thresholds are tuned to your book, not fixed defaults.
- Too many flags means the rules are loose; too few means they are tight.
- The failure mode is not the model, it is watching everything and seeing nothing.
Common questions
How is exception-based monitoring different from a monthly case review?
A monthly review reads every file on a calendar, whether or not anything changed, which means it is always both too much work and too late. Exception-based monitoring runs continuously and surfaces only the matters that cross a threshold you defined. The difference is attention. A review spends your hour on hundreds of cases that are fine, in order to find the few that are not. Monitoring spends it only on the few that tripped a rule, the moment they trip it, so a venue change or a spend overrun reaches you in days rather than at the next scheduled read. Same oversight, a fraction of the time, caught earlier.
Catch a case going sideways early→What if a case is off plan but not off budget?
Then it should still flag. Off budget and off plan are separate rules, and a healthy program watches both. A case can sit inside its spend authority while quietly drifting: no activity for sixty days, a venue transfer, a demand that doubled. That is off plan even though the invoices look normal. Good monitoring treats each condition as its own threshold, so a matter surfaces whether it broke the budget, broke the plan, or both. The point is to catch the driver of a bad outcome early, and spend is only one of several drivers worth watching. A case bleeding money and a case going silent are both worth your attention, for different reasons.
Which cases are ready to settle→Can I set my own thresholds?
Yes, and you should. Thresholds are only useful when they match how your program actually runs, so they are meant to be set and tuned by you, not fixed defaults. Spend authority differs by line and matter size. What counts as a stall differs by case type. A venue that alarms one team is routine for another. You define the rules, watch how many matters flag, and adjust until the queue holds the cases that genuinely need a decision and not the noise. A threshold that flags everything is as useless as one that flags nothing, so tuning it to your book is the point, not a chore to skip.
Does this replace defense counsel judgment?
No. Monitoring decides what reaches your attention, not what to do about it. When a case flags, the judgment about strategy, settlement, or counsel assignment stays with your team and your defense firms. CaseGlide does not predict outcomes or recommend a number. It surfaces the matter, attaches the facts behind the flag, and puts the decision in front of a human faster than a file-by-file review would. The value is triage: making sure the cases that need judgment get it in time, instead of surfacing weeks later in a report nobody had the hours to read closely. The rules find the case; your people decide the case.
CaseGlide is the litigation intelligence platform for Fortune 500 legal departments and insurance claims organizations. It structures live litigation data from defense counsel into executive decisions: reducing defense spend, settling the right cases sooner, and shrinking litigated claim volume.
Next step · See it on your docket
See what your litigation portfolio is telling you
A 30 minute walkthrough on your own docket. No slides, no committee.