Datasets

A dataset is a collection of rows that a Play can read, transform, and return. Each row represents an item such as an account, contact, or source event. Columns hold its input values and the results computed during the run. Datasets connect batch input to reviewable output. A CSV can supply 100 accounts, a Play can research each account, and the resulting dataset can retain the original domain beside the evidence, qualification decision, and reason. The same result can be viewed in the web app or retrieved through the CLI and API.

​

Sources and columns

A Play can create a dataset from a CSV, an array of records, another dataset, or rows returned by a supported tool. The selected Play defines which fields it expects. For example, a work-email batch may require first name, last name, and company domain. Mapping CSV headers connects the file’s actual column names to those expected inputs. An authored dataset stage adds computed columns. A column can format existing data, classify a record, call a tool, or use a scalar child Play. Later columns can use earlier results from the same row. This makes the relationship between an input and its derived values visible. The computed result can be an object rather than a single text value. Keeping the full result beside a selected field preserves evidence for later review. An accepted email address and the response that explains its source are useful for different questions.

​

Maps and row identity

A map applies the same transformation to each row. Filters select rows, and slices select a portion of a dataset. A Play can combine these operations with computed columns to produce the next stage of work. Row identity determines whether two records count as separate work. For current CSV authoring, each original source-row position identifies an occurrence. Two rows with the same domain remain separate input records, even when all their visible values match. Filtering and mapping preserve that source identity. A custom Play can explicitly choose business-key identity when deduplication is intended. Previously admitted Plays retain the identity rules of their authoring contract. A business ID in your own columns remains useful for reconciling input records, outputs, and destination records.

​

Concurrent work and row failures

Deepline can process independent rows concurrently. Provider calls still follow their rate limits and runtime pacing, so a large file does not send every request at once. Row concurrency and provider capacity control different parts of the work. By default, an error in one mapped row does not stop its siblings. Deepline retains the failed row’s error and fields that completed before it failed. The map reports partial failures separately, and failed rows do not enter its successful output dataset. A Play can instead select fail-fast behavior when continuing would be inappropriate. If every executed row fails, the run fails rather than reporting an ordinary partial result. Retained row errors help identify the cause and recover the existing work.

​

Retained rows and run results

Deepline persists dataset row work in Runtime Sheets. The run’s dataset catalog identifies the durable datasets that are available, including intermediate datasets the Play does not return as its final output. The web app can display these rows and computed columns while the run progresses. A run can return a small summary alongside one or more datasets. Its status response carries dataset references, counts, and previews. The complete row set is retrieved separately, so a large batch does not become one enormous status response. In Play code, a dataset handle provides asynchronous access to its rows without requiring the whole dataset in memory. Run-scoped exports retrieve rows associated with that run. Querying the current Database table is a different operation. When later work overwrites a shared table row, an older run view does not become a permanent history of every previous value. Data that needs its own business history belongs in an explicitly designed working table.

​

Results and acceptance

A completed row can contain an accepted value, a valid no-result response, or evidence that needs review. Execution status alone does not establish business accuracy. A contact lookup may complete successfully while returning no email that satisfies its acceptance rule. For example, a 100-row file might produce 75 accepted addresses, 20 no-result responses, and five failed rows. Those outcomes explain what happened to all 100 inputs. Treating only the accepted addresses as the whole batch would hide the unresolved work. Retained dataset values also differ from reusable tool-call results. Freshness and call-reuse rules govern whether a later operation can reuse a completed response. A visible value in a Runtime Sheet does not itself make another provider call free.

​

Datasets and other storage

A dataset describes row processing and results. The Database stores working records that multiple runs can use. A connected destination such as a CRM receives changes through its own action contract. Exporting a dataset to CSV does not update either destination. Use CSV input for the file workflow, Build a Play for dataset authoring, and Run Plays and view results for inspection and exports.