The manifest is the input agreement
A batch manifest fixes what a run expects to process. It gives each item a stable identity and identifies the process and policy used to interpret the input set. This makes missing, rejected, and completed work visible without relying on file ordering or directory contents that may change.
The example contains two logical input paths. They stand for files your own implementation would supply; they are not website downloads. A real deployment should resolve source references inside an authorized storage boundary rather than blindly fetching arbitrary user-supplied locations.
{
"schema_version": "1.0",
"manifest_id": "manifest-001",
"process": "documents.intake.v1",
"items": [
{
"item_id": "document-001",
"source": "inputs/document-001.txt",
"source_version": "1",
"expected_output": "outputs/document-001.json"
},
{
"item_id": "document-002",
"source": "inputs/document-002.txt",
"source_version": "1",
"expected_output": "outputs/document-002.json"
}
],
"policy": {
"validation": "required",
"on_ambiguity": "human_review",
"max_attempts": 3
},
"acceptance": {
"partial_delivery": false
}
}Download batch-manifest.json. The schema and policy values are illustrative. Add the integrity, retention, and authorization fields required by your actual workload before implementation.
Distinguish identity from position
item_id identifies the business item inside the accepted input set. It should remain stable when workers finish in a different order. source_version identifies which revision was accepted; a corrected source should create a distinguishable input version.
Keep source checksums or equivalent integrity evidence when your storage and workflow requirements call for them. Do not insert a fabricated checksum merely to make an example look complete. Compute it from the actual bytes under a documented algorithm and verify it at the relevant boundary.
Record one disposition per expected item
Each required item needs a final disposition: accepted output, explicit rejection, or unresolved status under the chosen contract. Keep reason codes and source references with failures so an operator can repair them without guessing which input produced the issue.
A retry should preserve the item identity and record a new attempt. A revised input or changed process interpretation should create a new versioned operation. These distinctions let consumers compare results without mixing recovery attempts and genuinely new work.
Reconcile before declaring success
Join results to inputs by item_id. Check for missing results, duplicate accepted dispositions, and unexpected item identifiers. Count accepted, rejected, and pending items against the manifest total. Interpret those counts using the manifest's partial-delivery rule.
{
"result_manifest_id": "results-example-001",
"run_id": "run-example-001",
"state": "succeeded",
"items": [
{
"item_id": "document-001",
"state": "succeeded",
"output": "outputs/document-001.json"
},
{
"item_id": "document-002",
"state": "succeeded",
"output": "outputs/document-002.json"
}
]
}Download result-manifest.json. In this example both required items succeed, so the related run status reports a succeeded run with a total of two accepted items.
Apply the pattern to different workloads
For images, each asset may require several named output variants. For files, one input can produce multiple accepted and rejected records. For model jobs, retain prompt, model, schema, and validation versions as appropriate to explain the result. Extend the manifest around the actual unit of acceptance.
Read the batch images guide, batch files guide, or local LLM guide for workload-specific decisions. The shared principle is simple: a completed batch accounts for the expected work, not merely the requests a worker happened to finish.