> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Production checklist before you scale
description: >-
  The checks to work through before you run real volume: pinned versions,
  authentication, limits, approval, replay, cancellation, result verification,
  retention and a safe support path.
route: /docs/compute/jobs/production-checklist
page_id: docs-compute-jobs-production-checklist
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Teams moving a working Compute integration into production volume
voice: D
reader_question: What must I check before I run real volume?
primary_action: Run the failure tests before you raise volume
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-jobs-production-checklist-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need one workflow that has completed successfully at small size, and the identity your production code will actually use. Work through the checks in order, because each one assumes the previous one held.

Test the failures before you raise volume. A first failure at production size is the most expensive way to learn any of this.

## Pin what you depend on

Pin the workflow `id` and `version` your code submits. A floating version means the work can change shape without your release changing.

Pin the client. Each released client states its exact package name and version on its client page, so record the one you shipped. Log the contract release carried on every response envelope, so a later change is visible in your own records.

## Prove the identity and its limits

Confirm your production code uses a work key, and that the key holds only the work scopes it needs. Management scopes are never mintable on a work key, so finance, destination and identity administration stay with a separate identity.

Confirm the spend ceiling and the approval rule on the account. Confirm the workflow's maximum item count from its descriptor, and check that your quote repeats the same figure.

## Confirm approval is a real step

A quote never authorizes work. Approval is a separate act, and your production path must perform it deliberately rather than inheriting it.

Check who holds approval authority and what happens when they are unavailable. That answer decides whether a budget refusal at 2am stalls for minutes or for a day.

## Test replay, equivocation and cancellation

These three tests are short, and each one proves something your retry logic depends on.

1. Send the same request twice with the same key. Expect the prior result, not a second run.
2. Send the same key with a changed payload. Expect a refusal for equivocation.
3. Cancel a job that is genuinely running. Watch it move to `CANCELLING`, then read it again until it reaches a terminal state.

Run these in the sandbox first, then once on the real path before volume.

## Check results the way production will

Verify that `result-manifest.json` exists before you treat any bundle as complete. Part files are not a completion signal.

Reconcile the accepted, failed, abstained and missing counts against what you submitted. Check `provenance.json` against your input digests, and check that `verification.json` matches the quality preset you asked and paid for.

## Set retention, then a safe support path

Decide your retention before the first production bundle, not after. Result artifacts move through expiry and deletion, and the manifest records the retention that applied to that run.

Write down what your team may send to support: the request identifier, the job identifier and the receipt reference. Support never needs a payload dump, an API key, a signed URL or bank details, and nobody should be improvising that at 2am. Rehearse the whole checklist in [the sandbox](/docs/compute/sandbox/quickstart), and agree what a support message contains using [the safe evidence to share](/help/compute/support-evidence).