The short answer

A Deepline Engine is a Play that manages a process with more than one step. It checks a record's current state, runs the Play for that state, and saves what happened. A state is a clear answer to the question, "Where is this record in the process?"

Imagine an account research process. An account starts as new. After research, it becomes researched. A person can then approve it as ready or send it to needs_review. These names are examples, not built-in Deepline states. Your team defines the states and the rules that move a record between them.

new → researched → ready
           ↓
      needs_review

The useful part is what happens between the labels. The Engine calls a transition Play to do the work, such as collecting evidence for one account. It saves the original input, the result, and the next state in Customer DB. The next step can read that saved result.

Why save the state?

A one-off script can research an account and return an answer. That is enough when the job ends there. A longer process must also answer different questions. Did research finish? Did a reviewer reject the account? Which version of the work produced the result? What happens if a run fails after saving its output?

An Engine makes those decisions visible. Each state has an input table and an output table. The output records what the step did and which state comes next. If the next step must wait for a person or a new event, the record can stay in its current state until that input arrives.

The Engine also uses a stable key for each record and transition. When a run retries, it can find the completed transition and repair a missing handoff without writing a second result. That matters when a provider call, database write, or run fails partway through a process.

What the Engine does, and what it does not do

The Engine decides which step runs next and stores the outcome. Each transition Play does one piece of business work. Customer DB keeps the records between runs. The Engine does not create a new kind of Deepline runtime. It uses Plays and the Database that Deepline already has.

An Engine also cannot decide your business rules for you. You must define what counts as ready, which states can follow needs_review, and when the process ends. If those rules are unclear, automating them only makes the ambiguity run faster.

Use an Engine when records move through several defined stages and the team needs to inspect or retry each move. For a single enrichment or report, one ordinary Play is usually enough. The Deepline Engines docs describe the state, table, and transition contracts in detail.