Skip to main content
A Play is versioned code that Deepline executes for a GTM task. It can research an account, resolve a work email, evaluate a lead, or prepare an update for a destination system. The important boundary is the business decision: what evidence is sufficient, what result is acceptable, and what happens when the work cannot produce that result. A Play gives that decision a source artifact and a run history. It does not make every data source correct or every external action safe. Those properties depend on the code, the tool contract, and the destination’s behavior.

​
A definition, a version, and a run answer different questions

The definition is the code being authored. A published version identifies a stable revision that other callers and triggers can use. A run applies admitted code to an input and records its progress and outcome. Suppose a lead-routing rule originally assigns accounts by country, then changes to named-account ownership. An old run and a new run can disagree without either execution being defective. Their version identities explain which rule each applied. Changing a draft does not replace a published version. A version does not freeze the external world. A provider can return newer data, and a CRM record can change between reads. Versioned code explains the logic used; source evidence and observation times explain the data that logic saw.

​
The execution graph makes work observable

Inside a Play, runtime primitives identify meaningful units of work. A step can record a scalar checkpoint. A tool call represents a provider-backed operation. A dataset organizes row-oriented work. A compatible scalar child Play can supply reusable logic through deepline.runPlay. These boundaries help distinguish where a failure occurred. A 100-row batch is not adequately described by one message saying that enrichment failed. Its row and step outcomes can reveal that some rows found a result, some had no match, and others encountered an error. Deepline’s authoring checks validate supported structure and contracts before execution. They cannot prove that an address belongs to the intended person or that a sales policy is correct. Those require domain validation and a representative pilot.

​
Durable execution and retries are different from exactly-once effects

Deepline can reuse a completed receipt when the call’s cache identity matches. Unfinished or failed work does not become a completed cache hit. Independent misses can execute independently, including overlapping invocations. That means a stable tool-call label is not a global lock against duplicate work. It also does not guarantee that a new run costs nothing. Refresh choices, inputs, authorization, and the relevant cache contract affect reuse. An external write needs a separate argument for safety. If a destination accepts an idempotency key, workflow code can preserve that key across retries. If the destination does not support one, the workflow may need reconciliation before another attempt. A timeout after submission is especially important: the action may have happened even though the caller did not receive an answer.

​
A trigger supplies the occasion, not another implementation

Manual calls, schedules, webhooks, and supported Database SQL listeners can start a Play. The trigger determines when admitted logic runs. The Play body determines what it does with the input. A webhook supplies an explicit input from another system. A SQL listener reacts to a matching changed row in a supported stream. A schedule is appropriate for work whose timing is known in advance. These entry points do not replace a Monitor, which owns the upstream event feed. The practical benefit is that a tested decision can acquire an automated entry point without being reimplemented in a second workflow engine. Trigger inputs still need to match the Play’s contract.

​
Execution success is only one layer of success

A completed run means the handler finished under the runtime’s contract. If the code returns an unresolved match as a normal result, that run can complete without finding the desired email. If it submits a CRM update, the business outcome also depends on how the code verifies that update. A useful output therefore distinguishes accepted results, legitimate no-results, and failures. The domain-specific acceptance rule belongs in the Play. The runtime does not infer the team’s definition of a qualified lead.

​
Continue learning