Skip to content
LyftData Docs

Runtime Evidence and Receipts

Runtime evidence answers a narrower question than “did the operation succeed?”: what did this specific product surface observe, and what does that observation actually prove?

LyftData can retain runtime artifacts, status records, signals, and operation-specific receipts. These records help operators inspect state across runs and governed automation without turning every response into an unqualified proof of an external effect.

Evidence levels

Section titled “Evidence levels”

Use this sequence when explaining an outcome:

Evidence What it proves What it does not prove
Intended definition The saved job or workflow describes the requested behavior That it was staged, deployed, or run
Staged or published record A selected definition entered the deployment lifecycle That an installed worker executed it
Placement or deployment record The control plane targeted work to a worker That the worker had capacity, connectivity, credentials, or a healthy target job
Observed runtime status The worker or control plane reported a bounded state That every downstream side effect completed
Runtime artifact A named worker/job/state producer persisted a resource at a recorded time That the payload is fresh, complete, or independently verified
External receipt The named external system reported the action described by that receipt Any effect outside the receipt’s explicit scope

A complete incident or audit record often needs more than one row: the intended definition, the deployed identity, runtime observation, and the final external receipt.

Runtime artifact identity

Section titled “Runtime artifact identity”

A runtime artifact is addressed by:

  • the worker that owns the state;
  • the job that produced it;
  • a state identifier and state kind; and
  • a resource key within that state.

The record also carries a version, update timestamp, optional checksum, and payload. That identity lets you ask whether a specific resource exists without confusing it with another job or worker.

List artifacts for a known state:

Terminal window
lyftdata runtime-artifacts list \
  --worker-id <worker-id> \
  --job-id <job-id> \
  --state-id <state-id> \
  --state-kind <state-kind>

Fetch one resource:

Terminal window
lyftdata runtime-artifacts get \
  --worker-id <worker-id> \
  --job-id <job-id> \
  --state-id <state-id> \
  --state-kind <state-kind> \
  --resource-key <resource-key>

The get command prints the stored payload as base64. Base64 is an encoding, not redaction or encryption. Do not paste the value into tickets, logs, chat, or an evidence bundle until you know its data classification.

Readiness checks are metadata-only

Section titled “Readiness checks are metadata-only”

Runtime-requirements checks can evaluate whether a state or resource key is present and, when a maximum age is supplied, whether it is stale. Their evidence includes identity, versions, checksums, timestamps, age, and resource references. The check deliberately omits payload bytes, base64 payloads, raw provider payloads, and secret values.

Read these statuses carefully:

  • satisfied means matching metadata exists within the requested age bound;
  • missing means the state or resource was not found, or was too old for the requested bound; and
  • unavailable means the artifact store could not be read.

“Satisfied” proves presence and freshness under the requested lookup. It does not validate the meaning of opaque payload bytes or prove an external effect.

Receipts

Section titled “Receipts”

A useful receipt identifies the operation, actor or caller scope, target, correlation or invocation identifier, outcome, and observation time. A provider receipt should also name the provider-side action or resource it confirms.

When reviewing a receipt:

  1. Match it to the exact invocation or deployment.
  2. Check that its target and environment are the ones you intended.
  3. Check whether the result came from LyftData, a source system, or the final external provider.
  4. Check freshness and whether later compensating or rollback activity exists.
  5. Preserve only the redacted fields required for the review.

Trigger dispatch acceptance is a good example of a bounded receipt: it proves the invocation message was accepted for dispatch. For a modern synchronous workflow, a correlated response-complete result proves that the target workflow reported a result through the typed response contract. A captured provider response can provide stronger external evidence, but only for the provider action described in that response. Historical trigger_response records belong to the retired response-slot compatibility path and should not be used as a template for new workflows.

Clear runtime artifacts safely

Section titled “Clear runtime artifacts safely”

Clear a single resource when possible:

Terminal window
lyftdata runtime-artifacts clear \
  --worker-id <worker-id> \
  --job-id <job-id> \
  --state-id <state-id> \
  --state-kind <state-kind> \
  --resource-key <resource-key>

Omit --resource-key only when the entire state should be removed. The CLI asks for confirmation because clearing state can reset a cursor, invalidate readiness, or cause a producer to rebuild data.

Before clearing:

  • record the exact state identity and why removal is required;
  • stop or pause the producer if it could immediately write the state again;
  • understand whether replay or duplicate delivery can follow;
  • export only the minimum redacted evidence you need; and
  • check backup and downstream retention separately.

After clearing, rerun the relevant readiness check and the producer’s bounded canary. Successful removal from the active artifact store is not proof of physical erasure from backups or external exports.

Section titled “Related reading”