Reconcile model batch results with the original request manifest

Choose one collection contract, not a generic batch promise

A consumer expects summaries for three fictional documents. If it attaches the first returned summary to the first submitted document, a changed result order can silently misassign content. A successful HTTP request or an ended batch cannot repair that mapping.

This guide selects Claude Messages Batches, using the current batch-processing guide and the results reference displaying API version 2026-10-21. The guide says results use the API version that created the batch. Our proposed profile therefore records that creation version explicitly; no installed SDK, account configuration or remote job was inspected.

The original worksheet concerns three bounded, text-summary intents, with tools and business actions excluded. All cases are PROPOSED_UNRUN. It adds collection correspondence and completeness to the separate single-job callback boundary, rather than implementing callbacks, retries or a provider client.

Keep provider facts and application rules separate

The results reference describes a JSONL response whose individual objects contain custom_id and result. Order is not guaranteed. IDs must be unique within the batch; the guide restricts them to 1–64 alphanumeric, hyphen or underscore characters. A line object is not the entire response.

The guide distinguishes succeeded, errored, canceled and expired. Its batch ended state means requests finished processing and results are ready. The request_counts fields tally processing and each outcome, with their sum matching the batch request total. Cancellation can leave already processed results.

Our stricter release rule requires a reconciled complete collection before admitting any new summary from that collection. This is an application choice, not a provider guarantee that every consumer receives exactly one valid record per item. No SDK iterator, transport-completion detection or parser behavior is established here.

Seal the request-to-task association before collection

Invent manifest M-A, associated with approved remote batch B-A and workspace W-A. Its expected IDs are R-A, R-B and R-C. Each entry binds one original document identity, revision, summary purpose, output ceiling and intended recipient. The protected association also records the selected creation API version and request configuration identity.

These are symbolic metadata labels, not created requests or actual provider identifiers. Manifest preparation and trusted batch-creation evidence are prerequisites. Do not reconstruct the manifest from result text or replace expected IDs with whatever appears in a retrieved collection.

An individual result’s custom_id is scoped to B-A through the trusted collection context. It cannot choose a workspace, document or operation. R-A in another batch is not the same task. Preserve the approved batch/workspace association throughout collection; a model-produced batch label or arbitrary result URL cannot select it.

Reconcile identity, category counts and collection coverage

Before matching, require supported evidence that the collection came from the approved batch retrieval and finished without an unresolved transfer or parsing failure. End-of-local-input alone is insufficient: a truncated collection can also stop producing records. The exact client and its completion/error evidence need separate verification before implementation.

For this proposed three-item profile, compare the received ID set with the sealed expected set. Require three records, three distinct expected IDs, no extras and no repeated IDs. Matching counts alone cannot catch R-A appearing twice while R-C is missing. Treat a conflicting repeat as a held collection, never a first-line or last-line overwrite.

Next require supported ended-state evidence, zero processing items and a terminal count total of three. Reconcile the collection’s outcome counts against the batch record: for example, two succeeded and one errored is a complete three-item disposition, not three successful summaries. Disagreement or unavailable count evidence stays unresolved. Counts support consistency; they do not authenticate results or substitute for coverage.

The positive case labels the returned order R-C, R-A, R-B, each succeeded once. Under the stated prerequisites, map each result to its own manifest entry, then apply that entry’s output and current-rights checks. The positional order becomes irrelevant. This is a proposed decision, not an observed successful batch.

Review eight inert collection cards

Expose the unresolved set without replaying work

Maintain separate collection states such as COLLECTING, HELD and RECONCILED, alongside each item’s recorded provider disposition and independent release decision. A fully reconciled mixed collection can truthfully report “two candidate summaries, one failed item.” An incomplete collection should name the unresolved IDs without guessing their outcome.

Do not automatically replay the whole batch when one item fails or collection coverage is unknown. Dispatch and cost recovery need their own authorization and accounting rules. Likewise, a succeeded result can contain unsuitable or incomplete content. Validate the complete bounded summary against its original acceptance criteria; never execute instructions returned inside it.

Coordinate the manifest revision and present item rights with result release through a supported design. A separate rights check followed by an unprotected disclosure can race revocation. Neither that coordination nor client memory, byte, line-count and duration enforcement has been implemented or tested here.

No provider batch, model, API, account, SDK, JSONL parser or join fixture was exercised for these cases. Keep minimized batch/manifest/item labels, disposition counts and review coverage rather than raw prompts or results in ordinary logs. Boundary is prelaunch; it does not claim a shipped batch reconciler. Its eight historical mock policy checks and separate synthetic JSON-export checks concern different behavior.