> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Understanding workflow evidence > How run status, logs, retained results, usage, and destination verification answer different operational questions. Workflow observability is the ability to explain what happened at the boundary where a process stopped being understandable. A single success counter cannot answer whether a source returned a valid value, whether a policy accepted it, or whether the destination received the intended change. Deepline exposes execution evidence. The business interpretation still depends on the Play's outputs and the team's acceptance rules. ## 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](https://deepline.com/docs/sdk-v2/calling-plays.md#inspect-and-export-an-existing-run). * [Run logs and events](https://deepline.com/docs/sdk-v2/run-events.md): query grammar, payloads, and retention. * [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md): recover observation and reconcile writes. * [CRM provenance](https://deepline.com/docs/guides/data-provenance-in-crm.md): persist the evidence behind an accepted field. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.