Give every item a stable identity

Map each input to its output

Give every logical item your agent must reconcile a stable identifier before submission. For one run, the relationship should be unambiguous:

input item ID → quote-bound job ID → returned item outcome

Keep your own mapping from the item identifier to the business record and submitted job. Array position is not an identity. Prefer opaque identifiers over email addresses, account numbers, or sensitive case references, and keep the real-record mapping under your organization's access controls.

Keep item, job and request identities separate

1. Identify the logical item and the immutable source revision used for this run.
2. Put an item identifier inside the encrypted input only in the form the workflow's input schema accepts.
3. Record the relationship between that item, its artifact and the quote-bound job ID. Keep the returned admission identity with the same record.

The public LithiJobV1.input object contains source and public_bounds. It does not accept a generic item_id_field or snapshot field. Do not add those fields to the control request merely because your local data uses them.

You own the protected identity mapping. Your agent defines the expected output and reconciliation checks using opaque item IDs. Keep any protected reverse map outside its reasoning context; provide only the permitted evidence needed to join a result. The Compute Kit can prepare and seal the declared input, Lithi processes the approved work, and your agent checks the returned identity, schema and coverage.

Join through the returned job ID

Read batch result metadata from GET /v1/batches/{id}/results. Each result projection carries job_id; use that ID to find the corresponding entry in your own mapping.

Inside an encrypted result with several rows, use the identity field declared by that result format. Do not assume that a row keeps its input position unless that exact contract guarantees it.

Page boundaries, partial availability, failures, and delivery timing can all make a positional join wrong. Sorting by arrival time does not repair a missing identity.

Reject missing or conflicting identities

Check uniqueness before submission. Two genuinely different records need distinct identities, even when their content looks alike. A source key plus a stable occurrence or revision can distinguish repeated business records when that matches your data model.

When ingesting results, detect duplicate job or item IDs instead of allowing a dictionary assignment to silently overwrite an earlier outcome. An identical replay and conflicting result evidence are different cases; retain both observations when they conflict.

Keep item identity separate from request idempotency

An item can remain the same business record across multiple deliberate evaluations. Those evaluations are different work intents with their own quote, approval and job identity. A transport retry of one submission keeps the original body and idempotency key. Do not mint a new request key merely because an item has not appeared in your result list.

Close gaps before using the output

Compare expected item identities with observed outcomes. Read the original job's state and events for any missing result. Missing evidence is unresolved, not a successful result and not proof that the item was never attempted.

Resolve uncertain submissions using safe retry and reconciliation steps. Share only safe item and job references when support is needed.