Introduction

Scenario: Supply-chain leadership wants an early-warning forecast of which suppliers and shipments are at risk of disruption, and they have handed you a trusted joined dataset to turn into a defensible modeling problem. Before anyone trains a model, you must frame the prediction target and build a feature-engineered, labeled training dataset with a held-out test split.

This unit is where a vague business ask, 'predict supply-chain disruption', becomes a concrete, supervised modeling problem with data you can actually train on. In Foundry, a model is an artifact for inference (machine learning, forecasting, optimization, physical models, or business rules), but no model exists yet; your job is the upstream work every later unit depends on. You will profile the trusted joined dataset, decide what 'disruption' means as a learnable target, and produce a feature dataset whose columns are the model inputs (features) and whose label column is the prediction target. You will then carve out a held-out test split so the model can later be evaluated on rows it never saw during training.

The decisions you make here are framing decisions, and they are stickier than code. Is disruption a binary event (disrupted vs. not) or a continuous risk score? What is the prediction horizon, are we forecasting risk for the next shipment, the next week, the next quarter? What metric defines success, and what threshold makes the model good enough to operationalize? These choices flow downstream: the label you engineer becomes the column a ModelAdapter's api() will declare in Unit 2, the metric you pick becomes the MetricSet a Modeling Objective records in Unit 3, and the eventual DisruptionRisk band you populate on Ontology objects in later units must be derivable from the target you define now. Get the target wrong and every downstream artifact inherits the mistake.

The feature dataset and its train/test split are first-class Foundry datasets, so they are verifiable through the Datasets v2 API: Get Dataset confirms a path resolves to a real dataset (rid + name), Get Dataset Schema confirms the expected feature and label columns exist, and reading the table confirms there are actually labeled rows. The completeness checks for this unit confirm existence and schema, not the correctness of your feature logic or the quality of your labels, that judgment is yours and belongs in the problem-framing brief you write at the end. By the close of the unit you will have a labeled feature dataset, a held-out test split, and a one-page brief stating the target, horizon, and success metric, which together are the ready-to-train foundation for the rest of the course.

Capability focus: Problem framing (target/horizon/metric); feature engineering; labeled dataset + train/test split; row-presence confirmation. · Artifact: A feature-engineered, labeled training dataset with a held-out test split, plus a problem-framing brief.

Key concepts

Companion video

1. 1

   Feature dataset resolves with the expected schema

   Build the feature dataset as a Foundry dataset whose schema carries the engineered model inputs alongside the prediction target. Profile the trusted joined supply-chain data first, then engineer feature columns and the label column into a single output dataset, ensuring at minimum that supplier_id, on_time_rate, and disruption_label are present with sensible types. This check is structural: Get Dataset (Datasets v2) on the feature-dataset path returns a rid + name to confirm the dataset exists, and Get Dataset Schema confirms the expected feature and label columns are present. Note the honest limit, the API confirms the columns exist and resolve, not that your feature engineering is correct or that on_time_rate is computed the way you intend; that correctness lives in your framing brief and in later evaluation.

   not startedinstance check

   Run check

   Confirms the feature dataset resolves with the expected feature + label columns.

2. 2

   Train/test split materialized as two datasets

   Materialize a held-out test split so the model can later be evaluated on rows it never saw during training, following the same split-before-training practice the Code Repositories model-training tutorial uses. Derive two datasets from the feature dataset, a training dataset and a test dataset (for example an 80/20 split), and write each to its own path. The check confirms both the train and test split datasets resolve via Get Dataset (existence-only): each path returns a rid, proving the two split datasets exist. Be honest about what is NOT verifiable, no read API exposes the split ratio or the random seed, so the 80/20 proportion and reproducibility of the split are your responsibility to document, not something the platform can confirm.

   not startedinstance check

   Run check

   Confirms the train and test split datasets both resolve with a schema.

3. 3

   Label/target column present and non-empty

   Confirm the label/target column is not just present in the schema but actually populated, because a column with zero rows is not a usable training target. Verify that the feature dataset's label column exists and that the dataset has rows (row count > 0) by reading the table. The check uses Get Dataset Schema to confirm the label column is present and a table read to confirm at least one labeled row exists, together establishing that a usable target is materialized. The limit to state plainly: row presence confirms a usable label exists, it does NOT confirm label quality, correct class balance, or that the disruption_label was derived correctly; those are judgments you defend in the framing brief, not facts the API can return.

   not startedinstance check

   Run check

   Confirms the label dataset has rows (a usable label exists, not just a schema).

4. 4

   Problem-framing brief defines target, horizon, and success metric

   Write the one-page problem-framing brief that pins down the modeling decisions the rest of the course inherits. State the prediction target explicitly (binary disruption event vs. a continuous risk score), the prediction horizon (e.g., next shipment, next week, next quarter), the success metric (e.g., AUC, precision, or RMSE), and the acceptance threshold that would make the model good enough to operationalize; note how this target maps to the DisruptionRisk STRING band that later units populate on Ontology objects. This step is MANUAL and self-attested by design: no Foundry read API can inspect a written brief, parse a target definition, or evaluate whether your chosen metric and threshold are appropriate, so the platform cannot confirm it and a reviewer must. Treat the brief as a contract, the metric and threshold you write here are exactly what a Modeling Objective's MetricSet will be judged against in Unit 3.

   not startedself-attested

   Mark complete

   Self-attested: the brief states the prediction target, time horizon, and success metric.