# Your document pipeline should stop, not guess (https://riska.io/blog/document-pipeline-should-stop-not-guess)

_2026-08-05 · Riska Underwriting Team · feature_

When an intake pipeline cannot tell which product a submission belongs to, it has two options: rank the candidates and take the top one, or stop and ask. Riska stops. The run parks, a review opens on a real task list, and nothing reaches the policy record until a person has decided. Here is why that boundary is worth the interruption, and what it actually costs in practice.

## Key takeaways

- A pipeline that guesses at the ambiguous step does not remove the error, it moves the error downstream to where it is expensive to find and slow to unwind.
- Riska's intake runs eight named stages, and where a run halts is a setting. With auto-apply off, which is the default, it stops after the changeset and writes nothing to the policy record.
- When the reconcile stage cannot resolve which product a submission belongs to, the run parks at AWAITING_REVIEW and opens a review with a task attached, rather than picking the highest-scoring candidate.
- One bad attachment does not fail a submission. The per-file stages aggregate, so a scanned page that will not classify does not stop the other ten documents.
- A corrected run restarts from the stage that was wrong, not from the beginning, so fixing a product mapping does not mean re-parsing a fifty page loss run.

## The cost of a confident wrong answer

A submission arrives at 4:40pm with eleven attachments. Nine are the ones you expected. One is a page scanned at 150 DPI that could be anything. One is an ACORD 140 for a location the ACORD 125 never mentions.

Somewhere in the next two minutes a piece of software has to decide which product this submission belongs to, and it is not certain. Most intake pipelines resolve that by ranking the candidates and taking the top one. The run finishes. The record is created. Everything looks fine.

It looks fine until the quote comes back priced against the wrong program. By then the wrong answer has been copied onto a policy record, a document has been generated from it, and someone has sent that document to a broker. The two minutes you saved at intake cost a day to unwind, and the person who finds the error is the one you least wanted to find it.

The uncertainty was real. The problem is what the software did with it.

## Eight stages, and where a run is allowed to stop

Every [submission triage](/platform/submission-triage) run in Riska is the same eight stages, named on the run so you can see exactly where one stopped.

- **Classify**. Reads each file and decides what kind of document it is.
- **Product Classify**. Per file, proposes which product it belongs to.
- **Reconcile**. Takes those per-file proposals and resolves one product for the whole submission.
- **Extract**. Pulls the configured fields out of each parsed document.
- **Merge**. Combines the per-file values into one set.
- **Match Product**. Resolves which existing record this submission belongs to, and stops rather than choosing when more than one candidate matches.
- **Changeset**. Turns the merged values into a set of proposed writes.
- **Apply**. Commits those writes to the record.

The last two are the ones this argument turns on. Changeset produces the writes. Apply performs them. They are separate stages because the gap between them is where a person can stand.

### Two ways to handle an ambiguous submission

The difference is not whether the pipeline is uncertain. Both are. It is where the uncertainty surfaces, and who is holding it when it does.

| Question | A pipeline that guesses | A pipeline that stops |
| --- | --- | --- |
| Reconcile cannot pick a product | Takes the highest-scoring candidate and continues | Parks the run and opens a review |
| When the error surfaces | At quote or at bind, days later | At intake, in minutes |
| Who finds it | The broker, or the audit | The person who already owns the submission |
| Cost to unwind | Reverse the record, reissue the documents, explain the call | Pick the right product, resume the run |
| What the audit trail holds | A value with no author | A named decision with a timestamp |
| Time saved on a clean submission | The same | The same. A clean run never stops |

## Why the changeset is the boundary

Auto-apply is a setting on the pipeline, and it is off by default. With it off, a run halts after the Changeset stage. Every value the pipeline extracted is sitting in one reviewable object, each field carrying the document and page it came from, and none of it has touched the policy record.

That is a real boundary rather than a review queue bolted on after the fact. There is no partially written record to reconcile, no half-applied endorsement, nothing to reverse. Approving the changeset applies every operation together. Rejecting it leaves the record exactly as it was.

It also means the setting is yours to move. Turn auto-apply on for the document types where you have earned the confidence and leave it off for the ones you have not, so a clean renewal packet and a first submission from a new broker do not have to be treated the same way.

> **DEFINITION: Changeset**
> The complete set of writes a pipeline run produced, held in one reviewable object before any of it reaches the policy record. It is approved or rejected as a unit, so a record is never left half updated.

## What happens when a run cannot finish a stage

1. **The run parks where it stopped** Reconcile is the stage allowed to do this. When it cannot resolve a product from the per-file candidates, the submission moves to AWAITING_REVIEW instead of taking the top of the list.
2. **A review opens with a task attached** The work lands on a task list someone already looks at rather than in a queue nobody owns. The review is idempotent per submission and stage, so a workflow retry cannot open a second copy of the same question.
3. **One person makes one decision** The review asks only for the thing the pipeline could not determine, usually which product this is. Everything the run already worked out is still there and is not thrown away.
4. **The run resumes from where it stopped** Resolving the review signals the parked workflow, which continues into extraction with the product it was given. The stages before it do not run again.

## Restarting from the stage that was wrong

The other half of not guessing is being able to fix a run cheaply. A boundary that forces someone to look is only worth having if acting on what they saw is fast.

A run can be restarted from a chosen stage. Everything before it is rehydrated from the stored per-stage results rather than recomputed, and everything from that stage onward runs again. Correcting a product mapping does not mean re-parsing a fifty page loss run. Re-running extraction after a field mapping changes does not mean reclassifying eleven attachments.

That is what makes tuning [document intelligence](/platform/submission-triage) survivable. Change the mapping, restart from Extract, look at the changeset. The loop is minutes, and it costs one stage of compute rather than all eight.

None of this makes the pipeline more accurate. It makes being wrong cheap, which across a book of business is the more useful property.

## Questions we get asked

### Does every submission need someone to approve it?

No. Auto-apply is a per-pipeline setting, and with it on a run goes straight through to the record without stopping. It ships off because the first weeks of any intake configuration are the weeks you most want to see what the pipeline decided before it acts.

### What happens to the rest of a submission when one attachment will not classify?

Nothing. The per-file stages aggregate rather than fail. A page that cannot be classified is reported as a failed file on that run and the other attachments continue through the pipeline. Only a total failure of every file fails the submission.

### Can I re-run just the extraction step?

Yes. A run can be restarted from any stage. Everything before the chosen stage is rehydrated from its stored results and everything after it runs again, so re-extracting does not re-parse or reclassify the documents.

### How is this different from a confidence threshold?

A threshold still produces an answer and attaches a number to it, which leaves a person deciding what to do with a value marked 0.71. Parking the run produces no answer at all until someone supplies one, and the decision is recorded as theirs.

### Where do I see what a run actually decided?

Each stage writes a job record you can open. Classify, extract and the rest each list the file they ran against, their inputs and their outputs, and an extract job shows every field it pulled with the page it came from.