What If an AI Batch Finishes After the Business Deadline?

Separate a finished AI request from a still-valid business result. Review late batches, changed inputs, fallback decisions and uncertain downstream effects.

A finished request can arrive too late to use

An AI batch that succeeds after a dispatch cutoff has produced an output, not necessarily a usable dispatch decision. The application must decide whether the original task is still open, whether its input snapshot remains applicable and whether another process has already made the decision. Provider success cannot answer those business questions.

This matters when asynchronous AI supports a pricing review, a shipment exception or an operational briefing. A cheap batch may be appropriate for preparing next week's analysis and inappropriate for deciding a shipment that closes in twenty minutes. The issue is not simply latency. It is what the system does with a result after the opportunity to act has changed.

The shipment records and times below are synthetic teaching examples. They are not customer results, provider benchmarks or a service-level promise. The proposed acceptance contract is an application design to review with the process owner, not evidence that any provider enforces your company's cutoff. Keep provider processing status, business acceptance and external effects as separate records.

Distinguish the provider window from your deadline

Claude's batch-processing documentation describes independently processed requests, per-request outcomes, result matching by custom identifier and partial results after cancellation. It also documents a provider processing window. Those properties help collect and reconcile outputs; they do not define a shipment cutoff or prove that a result remains useful when retrieved.

AWS's asynchronous Lambda configuration separately defines queue event age, retry settings and handling of discarded events. Event age limits how long queued work is retained. It is not an application-wide promise that a business effect finishes within that age. Our engineering inference is to keep queue and provider limits separate from the business acceptance condition.

Define which event the business deadline governs. Is the recommendation required before review starts, must the owner approve it before a cutoff, or must the destination commit an action before that cutoff? These contracts need different controls. Finishing generation before the deadline does not satisfy a destination-commit requirement when review and transmission still take time.

Use an authoritative time basis and record the boundary comparison. For the illustrative contract below, the application may accept a recommendation only when its trusted acceptance time is strictly before the stored cutoff. A result arriving exactly at the cutoff is late. This is a chosen policy, not a universal convention. If clock uncertainty could change the decision, hold it for review instead of inventing precision.

Work through a batch that loses its decision window

Suppose shipment S24 needs an exception recommendation before 15:00 UTC. The application submits analysis at 14:20 against inventory snapshot V8 and policy R3. The recommendation is advisory: it cannot itself reserve stock, send a shipment instruction or change a customer commitment.

At 14:45 the operator uses the agreed fallback and closes the decision with plan M2. The batch succeeds at 14:52, but the polling worker does not retrieve it until 15:06. The provider output may be internally consistent. It still cannot replace M2 under the proposed contract, because the decision is closed and the acceptance window has passed.

Do not fix this by trusting a generated field that says “completed at 14:52.” A model-produced timestamp is not authoritative processing evidence, and even a genuine provider timestamp would not prove acceptance by the application before 15:00. Decide which timestamp matters, then obtain it from the appropriate trusted system.

The result can remain useful for a permitted retrospective comparison. Label it as a late recommendation against V8/R3, not a current instruction. The analyst can compare it with M2 without reopening the shipment. If the business wants a new decision, create a separately authorized task with current evidence and a new acceptance window rather than silently extending S24's original deadline.

Bind every result to the task it actually analyzed

Keep a manifest connecting the business task, provider request, attempt, input snapshot and acceptance rule. Match results using a verified request identifier, never by file row position or arrival order. An identifier supplied in the output needs to resolve to the application's own manifest; an unknown identifier must not choose an arbitrary business record.

Record why an attempt was issued and whether it supersedes an earlier attempt. Two generations for S24 can produce different recommendations without either being entitled to overwrite the other. A retry for a transient error is not permission to change inventory V8 to V9 while retaining the old approval or accepted-decision status.

Validate the response shape and the domain conclusion independently. A parseable response can still refer to the wrong shipment, omit a material constraint or use obsolete inputs. Acceptance requires both content checks and current workflow checks. Keep a failed content check distinct from a late result so operators know whether the model output was defective or the decision window was missed.

Do not assume that inputs remain valid merely because the elapsed time is short. A stock allocation can change seconds after submission. The owner must decide whether the task deliberately analyzes a historical snapshot or requires fresh facts before use. For a current operational action, validate the required facts at the protected acceptance boundary and again at any separately governed dispatch boundary.

Use an acceptance worksheet, not a green batch badge

The worksheet applies the synthetic strict-before-cutoff policy. It is a proposed test artifact, not production execution evidence. Each row needs an observed attempt identifier, input revision, trusted acceptance time and resulting business state. A global batch status is not enough when individual tasks have different cutoffs or dispositions.

| Result condition | Business acceptance decision | Evidence required | | --- | --- | --- | | Valid result accepted at 14:59 while task remains open | Eligible for the next separately authorized step | Matching manifest, current inputs and protected acceptance record | | Valid result first accepted at 15:00 or later | Do not accept under this cutoff policy | Trusted acceptance time and explicit late disposition | | Result arrives after fallback M2 closed the task | Do not replace the settled decision | Existing decision identity and unchanged settled state | | Result uses V8 but the task requires current V9 | Hold for a fresh or explicitly historical decision | Input revision mismatch and owner-approved disposition | | Earlier attempt may already have caused an external effect | Reconcile before another dispatch | Original operation identity and complete destination evidence |

Implement the local acceptance decision so competing workers cannot independently accept different results for the same open task. Merely checking that the task is open and then writing later leaves a race with the fallback process. Use a protected state transition appropriate to the data store, and require every writer to participate in the same contract.

That local transition does not make a later destination effect atomic with the database. Preserve an accepted intent separately from its dispatched and confirmed states. If destination completion before cutoff is mandatory, establish a destination-supported condition or a bounded alternative the owner accepts. Otherwise say explicitly that your control governs local acceptance or dispatch, not remote completion.

Cancellation and retries must preserve what already happened

Requesting batch cancellation is not proof that all work stopped or that no result exists. Retrieve and classify the provider's actual per-request outcomes. In the application, independently prevent canceled or closed tasks from accepting new recommendations. A cancellation button should not erase the manifest needed to recognize delayed results.

If the original batch could invoke server-side tools or cause effects through another integration, an expired result is not proof of no side effect. Prefer generation-only analysis for this advisory example and keep writes in a separately controlled path. For a broader workflow, collect relevant effect receipts and reconcile uncertain attempts before dispatching a replacement. Do not assume a missing output file establishes remote absence.

Retry only work that still has a valid business purpose. Use the remaining window after queue wait, expected generation, required review and dispatch, rather than a fresh timeout for each attempt. A retry can be technically valid yet consume the time the operator needs for fallback. Define who activates fallback and what happens to late outputs afterward.

Preserve the cost of late, canceled and superseded work in the task's economics. A lower provider price does not necessarily mean lower cost per accepted decision when most outputs arrive too late. Compare the complete path, including review, fallback and reconciliation, against the same acceptance criteria. This is a measurement recommendation, not a claim that batch processing is inherently unsuitable for operational systems.

Test the boundary before widening batch use

Start with a local clock-controlled harness and fabricated records. Inject results just before, exactly at and after the cutoff. Close the task through fallback while the acceptance worker is paused. Change the required input revision during that pause, deliver two attempts out of order and repeat the same result. The expected state must come from the declared contract, not whichever worker happens to finish first.

Keep a negative control that accepts every provider-success result regardless of task state. The harness should detect its incorrect replacement of M2; otherwise a passing hardened version is weak evidence. Use inert dispatch adapters and check attempted operations as well as final rows. These tests should not send shipment instructions or contact customers.

Measure accepted-on-time tasks separately from provider successes. Record late arrivals, content failures, fallback settlements and unresolved effects without treating them as interchangeable. A dashboard can show a high batch success rate while the operational process repeatedly misses its window. Use the task manifest as the denominator so missing results do not vanish from the metric.

For permission timing, read approval expiry for AI actions. For dependency interruption and backlog recovery, use the AI provider-outage rehearsal. Ampity's agentic workflow services and backend systems work can help define acceptance and recovery around a real process. The worksheet is available to use independently; contact is optional.