Compliance operations

The rule changed. Which of your 40,000 cases are now wrong?

A sublimit moves, a statute updates, a policy form gets revised — and every decision made under the old rule is suddenly in question. Re-reviewing the backlog by hand doesn't scale, and a spreadsheet sample isn't an answer a regulator will accept.

A sweep re-checking 40,213 wind/hail claims in Texas against a revised policy. 28,406 processed so far, 41 determinations actually changed — those 41 surface for review; the rest stay closed, with the re-check on record.

Sound familiar?

The rule changed on a Tuesday, quietly

A sublimit moved, a jurisdiction updated a statute, a carrier revised a policy form. Nobody re-checks the backlog because nobody has a way to, so stale determinations sit untouched.

The honest answer today is a spreadsheet and a prayer

Someone opens a filter, guesses at which cases might be affected, and manually re-reviews a sample. Confidence in the result is exactly as high as the guess that produced the filter.

Re-reviewing everything by hand doesn't scale

40,000 cases at ten minutes each is over 6,600 hours of review for a change that affects a few dozen of them. Nobody has that budget, so most changes just don't get swept at all.

Why the usual fixes don't move the number

A one-off script someone writes for this specific change

It has no cost ceiling, no progress reporting, and no partial-failure handling — and it's rebuilt from scratch for the next policy change, because nothing about it was designed to be reusable.

Re-reviewing a random sample

A sample tells you a change probably affected some percentage of cases. It never tells you which specific cases — and "probably 2%" doesn't hold up when a regulator asks for the list.

Waiting for cases to resurface on their own

A stale determination doesn't send up a flag when the rule underneath it changes. It just sits there being wrong until a customer, an auditor, or bad luck finds it first.

A blanket re-run of every case, every time

Reprocessing all 40,000 cases for a change that only affects a few hundred burns budget for no reason and buries the handful of real changes in a wall of "nothing changed" noise.

How we solve it

01A Sweep is selector → task → cost ceiling

Target exactly the cases the change could plausibly affect — a peril, a state, a document type — run the same task against each, and cap spend before it starts.

selector: peril, state, typesame task as productioncost ceiling enforced

02Bitemporal documents make "as of the old rule" answerable

Each case's original run recorded its as_of date and the content hash of what it read — so "what would this look like under the new rule" is a real comparison, not a guess.

as_of pinned per runold vs. new, both real

03Review by exception, not by volume

Only cases whose determination actually changed surface for a human. The tens of thousands that didn't change stay closed, with the re-check on record.

changed → surfacedunchanged → stays closed41 of 28,406, not all 28,406

What you get on every document

A named, reviewable diff per changed case

Before and after determination, side by side, with the reason the change happened — not a re-review from scratch of a case that was already fine.

A cost ceiling that holds

The sweep stops at the budget you set, with partial-completion reporting — not an open-ended job someone has to babysit or kill by hand.

Every re-check is its own run

The reverse index from document to every run that read it is what makes "which cases does this change affect" answerable at all, not just a hope.

A defensible answer, not a sample

"These 41 cases changed, these 28,365 didn't" is a complete, reviewable answer for a regulator — not an extrapolation from a spot check.

The obvious objections

Build your first agent with Inteleto