Return the gap, not the workflow.

A reviewer rejects one proof-of-address document. The applicant uploads a replacement. The workflow starts over: identity is checked again, the already approved bank statement returns to a queue, a second reviewer repeats work that was correct, and the customer watches every status move backwards.

That is not caution. It is a state model with only two ideas: complete and reset. A useful document resubmission workflow has a third operation: reopen the smallest part of the evidence graph that the new document can actually change.

This is narrower than the collection problem covered in our document collection portal article. A checklist tells you which documents to request and a secure link gets them into the system. Partial resubmission begins after a document has been evaluated and asks a different question: when one node is replaced, which prior decisions are still valid?

The workflow is a graph, not a folder

A folder view encourages a destructive mental model. The case contains four files; one file is wrong; therefore the case is wrong. But the decision was never made on the folder. It was made from claims and relationships: the name on an identity document matches the application, the address on a utility bill is recent enough, the account owner on a bank statement matches the applicant, and the totals reconcile.

Model those claims as nodes and the validations as edges. A document is one source of evidence, not the unit of approval. Replacing the utility bill invalidates its address and date claims, plus the checks that depend on them. It does not invalidate the identity document's authenticity result or the statement's balance extraction unless a declared dependency connects them.

This graph gives partial resubmission a precise boundary. The system does not preserve work because a status happens to say approved. It preserves work because the inputs, policy version and dependencies behind that approval have not changed.

Return a requirement, not a case

The customer-facing action should name the missing requirement and the reason it failed. “Resubmit your documents” forces the requester to rediscover the reviewer's decision. “Replace proof of address: issued more than 90 days ago” gives them one bounded task.

The return object should carry at least:

• Requirement identity — a stable requirement ID, not a filename or array position that changes when uploads are reordered.
• Failure reason — a machine-readable code plus customer-safe copy. Internal fraud signals stay internal; actionable quality failures do not.
• Accepted evidence — the allowed document classes, file constraints and date rules at the moment of return.
• Replacement scope — whether the new upload supersedes one document, one extracted claim or an entire requirement group.
• Expiry and attempts — when the return request closes and how repeated invalid submissions are handled.

The upload link is delivery plumbing. It can expire and be reissued without changing the return object. Treating the link as the workflow state couples a security control to a business decision and makes an expired URL look like a rejected requirement.

Approved evidence stays immutable

Preserving approved work does not mean leaving it editable. It means sealing the decision and its inputs. Each approved node needs a revision, the content hash of its source, the extraction result it evaluated, the policy version, the reviewer or automation identity, and the approval timestamp.

When the replacement arrives, the original evidence remains in the audit trail but leaves the active graph. The replacement becomes a new revision. No object is silently overwritten; otherwise the team can see that a requirement is approved but cannot reconstruct which upload was approved.

The distinction matters when two uploads arrive close together. A mobile retry may submit the same file twice. A requester may upload a second replacement before the first finishes processing. Content identity and revision preconditions turn those events into idempotent no-ops or explicit conflicts instead of two racing attempts that approve different sources.

Our article on audit trails for non-deterministic systems makes the same point at the model layer: a result without its versioned inputs is an assertion. Partial resubmission applies that discipline to workflow state.

Invalidation is a declared policy

The hard part is not putting a node back into review. It is deciding how far invalidation travels. That rule should be explicit, testable and visible to an operator.

The safe default is dependency closure: invalidate the replaced evidence, then walk every downstream edge. A risk policy can deliberately widen that closure. For example, replacing an identity document may require re-checking all documents whose owner was matched to the old identity. But widening is a policy decision, not a hidden side effect of a “reset case” button.

Policy changes are another input. An address approved under a 120-day rule may not remain approved after the tenant changes the limit to 90 days. The graph should distinguish replacement-triggered invalidation from policy-triggered reevaluation, because the requester did not cause the second one and should not receive misleading blame.

The state machine needs a merge point

Many workflows implement a return path but never define how it rejoins the forward path. The replacement finishes extraction, one validation passes, and the case remains stuck because the original aggregate step was consumed once and has no legal transition back.

A robust merge point recalculates readiness from current graph state. It asks whether every required node now has an active, approved revision and whether every required edge is valid under the current policy. It does not ask whether a particular sequence of events happened in the expected order.

That distinction handles late events. A webhook from the superseded document may arrive after the replacement is approved. Its revision is no longer active, so the event can be recorded and ignored. Without revision guards, the late result can move the case backwards or overwrite the replacement's status.

The same rule protects downstream delivery. A case-complete webhook should include a graph revision or completion version. Consumers can then reject a stale completion event if a later resubmission reopened the case. “Complete” is a fact about a particular revision, not a property that can never change.

Measure saved review, not fewer uploads

A partial return still creates another upload, so upload count is the wrong success metric. The value is in the work that does not repeat and the time the requester does not spend reconstructing the case.

• Reopened-node ratio — invalidated nodes divided by all previously approved nodes. A rising ratio means the dependency graph is too broad or the policy is resetting by habit.
• Preserved-review minutes — the measured handling time of approvals that remained valid. This is the operational value, not a guessed hourly saving.
• Return-to-ready time — from the return decision to a graph that is ready to continue, separated into requester wait and internal processing.
• Repeat-return rate — requirements returned more than once for the same reason. This exposes unclear instructions and weak pre-upload validation.
• Stale-event rejects — late callbacks refused because their revision was inactive. Zero may mean clean delivery; it may also mean revision guards are missing.

Pair those measures with completion rate rather than reading either alone. Our document AI completion-rate framework separates unique cases from repeated arrivals; partial returns are exactly where a raw upload denominator starts telling the wrong story.

The six-line design review

1. What stable requirement is being returned, and what customer-safe reason travels with it?
2. Which evidence revision becomes inactive when the replacement arrives?
3. Which downstream validations are invalidated, and where is that dependency policy declared?
4. Which approvals remain sealed, and can an auditor reconstruct their exact inputs?
5. How does the workflow rejoin the forward path when readiness returns?
6. What rejects late events from superseded revisions?

The humane version of a document workflow is usually the technically precise one. Ask for the one thing that is wrong. Preserve the decisions whose inputs did not change. Recompute the graph from evidence instead of replaying a sequence. Return the gap, not the workflow.