Status, evidence, and business outcome have different scopes
Run status answers whether execution is queued, progressing, waiting, or terminal. Step and row outcomes narrow the location of work. Logs describe recorded context. Retained tool results supply the available response evidence. A completed handler can return no match. A failed run can have useful retained intermediate data. Neither the headline status nor one log message is a complete inventory of the business result. The compact response summarizes execution. Dataset rows and full retained results have separate retrieval paths. Their absence from a small status payload does not mean no work occurred.A partial failure illustrates the difference
Imagine a Play that researches an account, accepts a routing decision, and submits a CRM task. The task request times out. Research may have completed, while the external action’s outcome remains uncertain. The useful questions are separate: which version made the decision, which source supplied the evidence, whether the write was attempted, and whether the destination now contains the intended task. Restarting all work without those answers can repeat both usage and external effects. Deepline run evidence helps answer the execution questions. The destination’s supported read or idempotency contract is needed to resolve its state. A successful provider request is not a substitute for that verification.Structured context connects related facts
Recorded step identity, severity, source, attempt, and custom scalar context allow queries to identify specific work. The CLI and SDK can query retained logs or events, count matches, and summarize supported fields. Those queries describe retained records. They cannot reconstruct expired history or observations that were never recorded. An exact retained count is not necessarily a complete historical count of every business event. Likewise, provider and operation filters match recorded activity evidence. They should not be interpreted as an independently complete invoice of every possible source call.Retained payloads have boundaries
Available saved tool results can include sanitized inputs, scrubbed responses, and observed request evidence under their contract. Some evidence types are unavailable or have different retention. Older results can lack fields now recorded by newer execution paths. Unavailable details should remain unavailable, not become guessed values. Credentials and internal provider billing fields are removed from customer evidence. The retained response is not necessarily the original HTTP bytes. A process that needs durable field provenance must deliberately preserve the appropriate accepted evidence in its customer data. Runtime retention alone is not an indefinite business archive.Usage and operational health are separate evidence
A missing result does not establish a zero charge. A missing or pending usage record does not establish that no execution occurred. Recorded billing outcomes answer that question under the applicable contract. A source-access failure also differs from a defective business rule. A stream with no recent rows may have no matching events, a narrow scope, or a delivery problem. Diagnosing the correct layer prevents an operational issue from silently changing the acceptance rule.Apply this understanding
- Inspect and export a run.
- Run logs and events: query grammar, payloads, and retention.
- Production integration: recover observation and reconcile writes.
- CRM provenance: persist the evidence behind an accepted field.