A status sentence is not a receipt: bind agent updates to the run that earned them

“Deployment complete” is easy to read and hard to examine. Which execution produced it? What action finished? Which configuration ran? Did every sub-operation succeed, or did the sentence compress partial work into a favorable summary?

A stronger operating pattern is to generate status text from retained execution receipts. The receipt is the primary record; the sentence is a projection for a particular reader. This is our proposed architecture, assembled from three useful but distinct specifications—not a receipt format defined by any one of them.

Give every state an execution address

OpenTelemetry supplies a practical structure for locating work. Its tracing specification defines a span as one operation with identifying context, start and end timestamps, attributes, timestamped events, links, and status. Child spans or events can represent sub-operations, and a completed span can carry Ok, Error, or Unset status (OpenTelemetry Tracing API).

That structure can anchor a compact receipt:

receipt_version: agent-run-receipt/v1
execution_id: run-7f31
operation_id: deploy-api
parent_operation_id: release-204
observed_result: failed
started_at: 2026-09-19T18:02:11Z
finished_at: 2026-09-19T18:04:37Z
observed_at: 2026-09-19T18:04:38Z
revision_digest: sha256:...
configuration_digest: sha256:...
input_digests:
  release_manifest: sha256:...
output_refs:
  deployment_event: evt-991
sub_operations:
  - operation_id: upload-image
    observed_result: succeeded
  - operation_id: update-service
    observed_result: failed
interpretation: service update rejected after image upload
integrity:
  statement_digest: sha256:...
  signature_ref: sig-113

The minimum useful field set is an implementation judgment:

• An execution ID and operation ID identify the run and the exact unit of work.
• Parent or link fields locate the operation within a larger workflow.
• Start, finish, event, and observation times distinguish when work occurred from when a reporter learned about it.
• An observed result records success, failure, partial completion, or an unresolved state without forcing all outcomes into a binary.
• Revision, configuration, and input digests identify what was executed.
• Output or event references point to retained evidence rather than copying every payload into the receipt.
• An interpretation field keeps a human or automated conclusion separate from observed fields.
• Integrity metadata gives a verifier something concrete to check.

SLSA provenance provides the model for binding an execution to inputs, resolved dependency digests, builder identity, outputs, invocation metadata, and start and finish times (SLSA Build Provenance). Applying that model to agent runs is a design choice, but it closes a common gap: a trace can identify an operation while still leaving the effective revision or configuration ambiguous.

Keep the unfavorable rows

A receipt model earns its value when failure and partial completion survive summarization. Consider three derived examples using the same schema.

Success

operation_id: publish-artifact
observed_result: succeeded
output_refs: [artifact:sha256:abc...]
interpretation: requested artifact was published

A status projection may say: “Artifact published by run run-81; output digest sha256:abc....” The receipt supports that narrow statement. It does not establish that the artifact is correct or useful.

Failure

operation_id: apply-migration
observed_result: failed
events: [migration-started, database-rejected-command]
interpretation: migration did not complete

The status becomes: “Migration failed in run run-82 after the database rejected the command.” It remains a failed operation even if cleanup later succeeds.

Partial completion

operation_id: deploy-release
observed_result: partial
sub_operations:
  - operation_id: upload-image
    observed_result: succeeded
  - operation_id: update-service
    observed_result: failed
interpretation: image retained; service revision unchanged

The projection becomes: “Release partially completed: the image uploaded, but the service update failed.” Calling the release “complete” because one child span succeeded would discard material execution state.

Partial is not one of the three OpenTelemetry span-status values described in the supplied specification excerpt. Here it is an application-level receipt result derived from child operations and events, while the underlying spans retain their native statuses. That distinction keeps the proposed reporting vocabulary separate from the telemetry standard.

Derive prose; do not accept it as evidence

A projection function can be deterministic:

status = render(
  operation identity,
  observed result,
  material child results,
  observation time,
  revision and configuration identity,
  unresolved interpretation
)

For each sentence, the renderer can include only claims mapped to receipt fields. If a conclusion depends on inference—such as attributing a failure to a configuration change—the sentence can label it as an interpretation and preserve the underlying observations beside it.

This suggests four useful rules:

1. Never promote a child success into a parent success without an explicit aggregation policy.
2. Preserve failed, skipped, unresolved, and partially completed children in the parent projection when they affect the reported outcome.
3. Treat missing configuration identity as missing evidence, not as permission to reuse the most likely revision.
4. Regenerate corrected status from an amended or linked receipt instead of silently rewriting the original record.

These are operating recommendations, not requirements stated by OpenTelemetry, SLSA, or RFC 9943.

Verification stops before truth does

Receipt integrity and statement truth are separate questions. RFC 9943 describes receipts that provide cryptographically verifiable proof that a signed statement was registered and checked for validity at registration time. It also leaves management, storage, and notification of later changes outside its scope (RFC 9943).

That boundary matters. A valid receipt can support the claim that a particular statement was registered and validated at that boundary. It does not, by itself, prove that every assertion inside the statement accurately describes the world. Likewise, a signed agent-run receipt can protect attribution and integrity without proving that an agent’s interpretation of an event was correct.

An operator reviewing a status update can therefore ask four different questions:

• Observed execution evidence: Do the referenced spans, events, outputs, and timestamps support the reported operation result?
• Configuration identity: Do revision, configuration, dependency, and input digests identify the execution that allegedly produced the result?
• Receipt integrity: Can the reviewer verify the statement’s digest, signer, and registration evidence under the chosen receipt system?
• Unverified interpretation: Which causal explanations, quality judgments, or broader conclusions extend beyond the recorded observations?

A green answer in one category does not fill an empty category elsewhere. Valid integrity metadata cannot repair a missing execution event. A complete trace cannot identify an unrecorded configuration. Neither one proves an interpretation merely because it appears in polished prose.

For teams designing or revising agent workflows, the practical next step is to select one consequential status sentence, trace every clause back to a retained field, and keep the receipt address beside the rendered update. That same evidence boundary can become part of how the workflow is designed in Build: status remains convenient for people without becoming detached from the run that earned it.