DCP exposes the Batch product contract before public execution: validate JSONL, create renter-scoped metadata records, inspect line-ledger proof, and read result-manifest gates. Worker execution, discounted settlement, and model batch-capability flags stay gated until evidence lands.
Batch inputs are normalized, hashed, capped by request and byte limits, and stored as renter-scoped metadata.
Each request line has custom id, endpoint, model id, checksum, lifecycle, usage, and future settlement fields.
Result metadata is only considered available when the completed batch has a result key and checksum proof.
Batch discounts and settlement stay off until worker execution and billing proof are enabled.
The next opt-in proof is DCP_BATCH_LIVE_PROOF_ALLOW=1 npm run proof:batch-live-execution; execution and discounts stay disabled until it passes with result and settlement evidence.
fig. 03 - batch validation to proof ledgerThe same readiness contract powers the renter Batch console. It lets developers build against stable endpoints while DCP keeps the expensive parts behind worker, result, and settlement gates.
curl -s https://api.dcp.sa/api/batches/readiness \
-H "Authorization: Bearer $DCP_RENTER_KEY"
curl -s https://api.dcp.sa/api/batches \
-H "Authorization: Bearer $DCP_RENTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"batch_id": "batch_support_triage_001",
"completion_window": "24h",
"input_jsonl": "{"custom_id":"ticket-001","method":"POST","url":"/v1/chat/completions","body":{"model":"qwen/qwen3-coder","messages":[{"role":"user","content":"Classify this ticket."}]}}"
}'This page packages the shipped contract like a Fireworks-style product without hiding the current state. The next backend slices are worker smoke, result artifact proof, settlement proof, then discounts.
Validate JSONL and create renter-scoped batch metadata records.
Future worker execution must prove every completed line before settlement.
Discounts remain false until the billing path is verified on completed result artifacts.