What Is a Workflow Receipt?

Zambo link shape and a real request

A workflow receipt Zambo link should accept a request that names the ordered steps or session being inspected and return a record that commits to those steps. The exact API contract belongs to the service exposing it. A caller should read the Zambo link documentation rather than guessing a field name. For a session-based workflow, a request may look like this:

curl -fsSL https://zambo.dev/api/v1/sessions/SESSION_ID

Use a real session identifier supplied by the workflow. Do not copy the example as if it were a live record. The response commonly contains a workflow identifier, ordered step references, a root commitment, timestamps, and a status. A trimmed illustrative response is shown below. It is not a receipt and it does not assert that this session exists.

{
  "workflow_id": "example-only",
  "steps": [{"receipt_id": "step-1"}, {"receipt_id": "step-2"}],
  "root": "sha256:example",
  "status": "recorded"
}

How to review the response

First check that the workflow identifier belongs to the task under review. Next confirm that the steps are ordered and that every referenced receipt can be resolved. Recompute the root from the exact step commitments using the documented procedure. If a step is missing, changed, or unavailable, the workflow is incomplete. A root value copied from the response is not independent verification. The reviewer must obtain the underlying values again or mark the check unresolved.

What a workflow receipt proves

A workflow receipt can commit to the set and order of receipts that the workflow record names. It can help a reviewer see whether the recorded path contains a missing step or changed commitment. It does not prove that the workflow's goal was achieved, that the inputs were truthful, or that an outside system retained a side effect. Keep outcome checks separate. For a standards-oriented field and fixture reference, see the conformance page.

Failure handling

Transport errors, expired sessions, an unknown identifier, and an invalid root are different results. Report them separately. A timeout means the reviewer does not yet have evidence. It is not proof that the workflow failed. An invalid commitment is a verification failure. A valid commitment with an incorrect tool result is a valid record of an incorrect observation. This vocabulary helps incident responders avoid collapsing all uncertainty into one red status.

Practical adoption

Start with a short workflow whose steps are already individually observable. Store each step receipt before constructing the root. Preserve the exact bytes used by the commitment process. Generate the workflow summary only after the step references are available. Give reviewers a way to retrieve the workflow and its steps without asking the agent to narrate them again. Then test missing, reordered, and changed steps before relying on the feature for consequential work.

A workflow receipt is most useful when it makes review faster without hiding detail. The root gives the reviewer a compact consistency check, while the step receipts preserve the evidence needed to understand a disputed action. If the system cannot retrieve a step, say so. If it cannot establish the outside outcome, say so. Clear limits are part of the receipt's value.

Operational review checklist

Before relying on an automated action, identify the exact claim that matters and the system that can independently confirm it. Preserve the request reference, execution reference, timestamp, scope, and observed result. If a payment, entitlement, workflow root, or outside state is involved, retain that reference separately. This prevents a single status line from carrying more meaning than the evidence supports. It also gives support and incident teams a common vocabulary when a caller reports that something did not happen.

Verification should be repeatable by someone who did not operate the workflow. A reviewer should be able to retrieve the record, compare its identifier and timestamp, inspect the tool and scope, check the committed bytes or output hash, and then compare the result with the owning system. If the record cannot be retrieved, label the result unavailable. If the record verifies but the outside state differs, label the execution and outcome separately. Do not rewrite a historical record after a retry. Add the retry as a new event and preserve the relationship.

Privacy belongs in the design from the beginning. Public evidence should contain only the fields needed to support the stated claim. Credentials, private prompts, customer records, wallet secrets, and confidential payloads should remain under the controlling system's access rules. A digest is an integrity value, not a universal privacy guarantee. Reviewers should document redactions and keep a restricted cross-reference when a public identifier must be connected to a private account or transaction.

These distinctions are useful whether the workflow is free, paid, synchronous, or asynchronous. They do not depend on a promise that automation is infallible. The strongest implementation says what the record proves, what another system proves, and what is still unknown. Use the public receipt verifier for the receipt portion, then follow the owning system's process for authorization, billing, delivery, or correctness.