When a Long Analysis Stops Halfway

A question asked across forty documents is a different kind of operation from a question asked in a chat window. It is not one request that takes longer, it is hundreds of separate model calls that each have their own chance of timing out, erroring, or arriving slowly enough that something upstream gives up waiting. Over a long enough run, the probability that everything succeeds on the first attempt stops being close to one.

Which is why the interesting engineering question for document analysis at scale is not how fast it goes. It is what happens when part of it fails, because the naive answer, start again, is unacceptable once a run represents real time and real cost.

Why long runs break

Some documents are simply hard. A scanned PDF needing optical character recognition takes minutes rather than seconds, and a single pathological file in a set of forty can consume the budget the whole run was given. Some failures are external: a model provider has a slow minute, a rate limit is reached, a request returns an error that has nothing to do with your evidence or your question.

The failure mode that matters most is the one where a run is killed partway through by something outside it, a platform timeout being the usual culprit. At that moment the work already completed is real and correct, and the question is purely whether the system treats it as worth keeping.

Three things that make it survivable

The first is running the work in a background queue rather than inside the request that started it. Analysis proceeds whether or not anybody is watching the page, which means closing the tab is not an event and a browser refresh does not interrupt anything. It also means progress is a stored fact rather than something held in a connection.

The second is a per-source time budget. Each document gets its own allowance, so a single difficult file fails on its own terms and the remaining thirty-nine proceed normally. Without that boundary one scanned contract can take down an entire run, and the result is indistinguishable from the analysis simply not working.

The third is resuming rather than restarting. Completed cells are written as they finish, so an interrupted run can pick up from the boundary of what is already done instead of discarding it. That turns a killed run from a lost afternoon into a button, and it changes the economics of asking an ambitious question across a large document set.

Partial results are honest results

There is a governance dimension to this that is easy to overlook. A system that hides partial failure, by retrying quietly until something plausible comes back or by leaving a cell blank with no explanation, produces a grid that looks complete and is not. A reviewer reading it has no way to distinguish a genuine finding from an absence.

Showing which cells failed and why is more useful than a tidy surface, because it tells the reviewer where to look and what not to rely on. Cells that errored are also not charged, which is the correct behavior for the straightforward reason that a failed analysis has produced nothing worth paying for.

Qonera is the AI governance platform for professional teams, and the Evidence Base is built for runs that are long enough to be interrupted: queued in the background, bounded per source, resumable from where they stopped, and honest about which cells did not complete. How that fits the wider review and approval workflow is set out on the workflow page. Most of the difficulty in analyzing documents at scale is not the analysis, it is everything around the analysis continuing to work when one part of it does not.