Document processing

The job

A finance team receives invoices as uploaded documents. Staff need searchable fields, a classification, and a clear exception queue before the result reaches their accounting system. Completion means each document is published or has a visible reason for needing review.

The same pattern fits claim intake, partner forms, and catalog documents. The extraction and classification services differ, but each application needs to know which work is complete and what remains.

The flow

An upload starts a document run. A tool extracts text and fields. Another step classifies the document and checks its required data. The result goes to an outside system, and document events update a status view for staff.

Review is an extension you add. Put an approve() call before publication when your rules require a reviewer; the run waits for the decision event without holding a worker. The runnable tutorial publishes without a review step.

Use stable document identifiers to correlate review input with the right run. Define what a corrected submission means: resume an existing review or start new processing for a new document version. That is an application decision.

The difficult moment

The worker dies after extraction finishes but before classification completes. The completed extraction step result is memoized. A replacement can use it and continue with the unfinished work, instead of calling the extractor again.

If the worker dies while extraction is still in progress, that step has no completed result to reuse. It can run again. Publication also needs an idempotency key accepted by the destination when a repeat submission would create duplicate accounting records.

Ironflow’s role

Durable tool calls separate extraction, classification, and publication into recoverable steps. A durable wait can hold a review without holding a worker. Events record the document facts your application emits, and a projection can derive a queue of processing, waiting, and completed documents.

Your application supplies the OCR/model provider, document validation, access rules, and destination integration. Enable recording if you want an inspectable execution timeline for debugging how a particular document reached its result.

Implementation sketch

This is an illustrative flow:

1. Receive a document event with its ID and storage reference.
2. Extract text and fields in a durable tool step.
3. Classify the result and validate required fields.
4. If you added review, wait for it with approve() when your rules require it.
5. Publish with a stable destination idempotency key.
6. Emit completion and update a document-status projection.

Starting point

• Survive a crash includes a runnable extraction/classification/publication example and a worker-kill drill. Its tools simulate OCR and classification; human review is an extension to build.
• Step primitives explains durable calls and correlated waits for external input.
• Projections shows how to derive the staff-facing document queue from your application events.