Skip to main content
Every task tracebloc supports has a dataset template: the exact folder layout the data ingestor expects, a labels or data CSV in the right shape, a ready-to-edit ingest.yaml, and the list of checks the ingestor runs before a single row is stored. Pick your task below, lay your data out the same way, and follow Prepare Data to run the ingest.

Templates by task

How the templates fit together

Every template follows the same three steps. The task pages only spell out what differs.
  1. Stage the files on the shared data volume of your secure environment. Inside the ingestor they appear under /data/shared/; how to get them there is covered in Prepare Data.
  2. Write ingest.yaml from the task page. The top of the file is identical for every task; the category field names the task and decides which folders, columns and checks apply.
  3. Run the ingest once per split — once with intent: train and once with intent: test, each with its own table name:
The ingestor validates the whole dataset first, then copies files, stores rows and registers only metadata with the platform. Raw data never leaves your infrastructure. If any check fails, nothing is stored.

Where files must live

For tasks with one file per sample (images and text), the ingestor reads every file from a fixed subfolder name next to the others: images/, annotations/, masks/, texts/ or sequences/. It derives the dataset root from the folder you name in ingest.yaml (the parent of images:, texts:, and so on), so keep the subfolders side by side and spelled exactly like that:
Tabular and time-series tasks have no per-sample files: the CSV named in csv: is the whole dataset.

The ingest.yaml contract

These fields are shared by every task. Task-specific fields (images, texts, schema, target_size, …) are explained on the task pages.

Rules that apply to every CSV

  • The file must be valid UTF-8 without NUL bytes. Excel users: save as CSV UTF-8.
  • Surrounding whitespace in header names is stripped; duplicate header names are rejected.
  • The label column you configure is matched case- and whitespace-insensitively (Label satisfies label: label).
  • Tasks with one file per sample need a column named exactly filename (lowercase). Its value may include the file extension or not: cat1.jpeg and cat1 both resolve to images/cat1.jpeg when the configured extension is .jpeg. A value that already ends in .jpeg, .jpg, .png, .xml, .txt or .text (any case) is used as is.
  • The manifest must contain at least one data row, and at least one referenced file must exist.
  • String labels have surrounding whitespace stripped before storage. Only a label that is missing from the record is stored as NULL; an empty or whitespace-only label is stored as the empty string "". The NA tokens below apply to schema columns only — in a label column that is not declared in schema, an empty cell is "" and NA or null is a genuine class value.
  • The id column in the sample CSVs is not stored unless you declare it in schema — and you cannot declare it under that name. These column names are reserved by the ingestor and must not appear in schema: id, created_at, updated_at, status, data_intent, data_id, filename, extension, annotation, ingestor_id. The label column is not declared in schema either — label: names it.
  • Column names may be at most 64 characters. Any other character is allowed.

Checks every ingest runs

Task-specific checks are listed on each page. These run for every task:

Label policy for regression-class tasks

Tabular regression, time-series forecasting and survival analysis have a numeric target, and the platform must never receive raw target values. Their label therefore needs the object form with an explicit policy:
bucket replaces each value with one of 64 stable hash buckets in the metadata sent to the platform only. The rows stored in your secure environment keep the raw value, which is what training reads. A missing target is reported as bucket -1. passthrough sends raw values and is only appropriate when you have cleared that with your compliance owner.

SQL types for schema

VARCHAR(n), CHAR(n), TEXT, INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, FLOAT, DOUBLE, DECIMAL(p,s), NUMERIC(p,s), BOOLEAN, BOOL, DATE, DATETIME, TIMESTAMP, TIME, BLOB, LONGBLOB. Type names are case-insensitive. A near-miss (INTERGER) is rejected with a “did you mean” hint. Every declared column is checked against its type across the whole file: non-numeric values in numeric columns, values over a VARCHAR length, inf, integers outside the 64-bit range and unparseable dates all fail the ingest. In schema columns, empty cells and exactly these tokens are stored as NULL: NA, N/A, n/a, NULL, null, None, none, NaN, nan, <NA>, #N/A. The match is case-sensitive — Null, NONE, NAN or #n/a are ordinary values and fail the type check in a numeric column.

Next steps

Need help?

Email [email protected].