Learn/Evaluation/Lesson 2
Chapter 1 · Frame the decision

Labels, availability, and leakage

Train on what the system knew then, label with what became known later.

65–90 min4 key conceptsReviewed 26 Aug 2026
01 · Production proposition

An ETA model improves RMSE while increasing missed-delivery cost.

This chapter moves from draw the clocks to admit only mature labels. We will make the idea concrete in a small code example before placing it back inside a production system with a declared latency, cost, and operator-capacity budget.

Decision

Build the dataset from decisions whose outcomes were complete and available by the immutable snapshot.

Evidence

Verify the behavior illustrated in cutoff_safe_training.sql, then measure decision utility, slice reliability, and system latency.

Failure consequence

ROC-AUC alone on 0.1% prevalence hides unusable precision and an impossible review queue. An unsafe release must degrade to a named baseline or the last known-good version.

02 · Guided chapter

Build the idea one layer at a time.

Historical training rows must impersonate the moment a real prediction was made. Anything learned later is evidence for the label, not permission to rewrite the past.

Event time says when something happened; availability time says when the prediction system could know it. A status recorded for 09:55 but delivered to the warehouse at 10:10 cannot be used for a 10:00 decision.

Labels have their own maturity window. A seven-day outcome should enter training only after seven days plus reporting delay, while every feature remains bounded by the original cutoff. Keeping these clocks separate prevents subtle future information from leaking through joins.

Keep in view
  • prediction cutoff
  • censoring
  • temporal splits
  • PR curves
WORKED PATH

Follow the reasoning before touching the code.

  1. 01

    Draw the clocks

    For each row, declare cutoff time, outcome horizon, label-ready time, and dataset snapshot time.

  2. 02

    Constrain both feature times

    Require feature event time and availability time to be no later than the decision cutoff.

  3. 03

    Admit only mature labels

    Build the dataset from decisions whose outcomes were complete and available by the immutable snapshot.

sqlcutoff_safe_training.sql
WITH eligible AS (
  SELECT p.order_id, p.customer_id, p.cutoff_time, o.was_late
  FROM prediction_rows AS p
  JOIN outcomes AS o USING (order_id)
  WHERE p.cutoff_time <= :snapshot_time - INTERVAL '7 days'
    AND o.available_at <= :snapshot_time
)
SELECT e.order_id, e.was_late, f.balance_usd
FROM eligible AS e
LEFT JOIN LATERAL (
  SELECT a.balance_usd
  FROM account_events AS a
  WHERE a.customer_id = e.customer_id
    AND a.event_time <= e.cutoff_time
    AND a.available_at <= e.cutoff_time
  ORDER BY a.event_time DESC, a.available_at DESC
  LIMIT 1
) AS f ON TRUE;

Join mature outcomes while keeping account state cutoff-safe.

READ THE EXAMPLE

What to notice

  • The outcome may arrive after cutoff because it is the supervised target, but it must be mature by snapshot time.
  • The feature subquery rejects a backfilled account event that describes the past but was unavailable at the decision.
YOUR TURN Pause and predict before revealing the answer.

An account event has event_time 09:50, available_at 10:05, and cutoff 10:00. Should the join use it?

Need a hint?

Both temporal inequalities must hold.

Check your reasoning

No. It happened before cutoff but became knowable five minutes afterward, so using it would leak future system knowledge.

Bring forward

Lessons 1 in this course.

03 · Formal treatment

Connect the chapter to the course’s quantitative spine.

Train on what the system knew then, label with what became known later. The cost-aware threshold selection below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.

Formal treatment
C(t)=cFN FN(t)+cFP FP(t)C(t) = c_{\mathrm{FN}}\,\mathrm{FN}(t) + c_{\mathrm{FP}}\,\mathrm{FP}(t)

Cost-aware threshold selection

Symbol, shape or unit contract
SymbolMeaning / shape / unit
tdecision threshold
FN, FPerror counts at t
c_FN, c_FPbusiness cost per error
Open derivation and numerical substitution

Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.

  1. Write the named inputs: t, FN, FP, c_FN, c_FP.
  2. Substitute one small, hand-checkable batch before vectorizing.
  3. Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c02(inputs)
assert is_finite(value)
04 · Deterministic lab

Change one assumption and make the tradeoff visible.

Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.

Exact computation

Cost-aware threshold

Move the cutoff over a fixed set of scored transactions.

Primary16 cost
Secondary4 caught
Diagnosis2 false alerts

Assumption: Fixed 12-event dataset; false positive costs 2 units and false negative costs 12.

Open nonvisual data table
ItemComputed stateInterpretation
0.92fraudreview
0.84fraudreview
0.76legitreview
0.68fraudreview
0.59legitreview
0.51fraudreview
0.43legitpass
0.37legitpass
0.31fraudpass
0.22legitpass
0.14legitpass
0.08legitpass
05 · Production implications

Trace the complete operating path.

Carry the chapter’s central idea into the system: Train on what the system knew then, label with what became known later. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.

  1. 01

    Turn “Draw the clocks” into a written invariant and a failing test.

  2. 02

    Promote cutoff_safe_training.sql from illustration to a versioned implementation with representative fixtures.

  3. 03

    Use “Admit only mature labels” as the release checkpoint: Build the dataset from decisions whose outcomes were complete and available by the immutable snapshot.

  4. 04

    Serve or materialize behind explicit a declared latency, cost, and operator-capacity budget.

  5. 05

    Join telemetry to mature outcomes and retain a rollback path.

Observability

Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.

Cost

Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.

Failure modes

ROC-AUC alone on 0.1% prevalence hides unusable precision and an impossible review queue. Add a detector, owner, mitigation, and stop condition for this class of failure.

Alternatives

Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.

06 · Check understanding

Explain the contract, not just the vocabulary.

Browser-graded checkpointPass ≥ 80%
01Why use a chronological split?
02What does a calibrated 0.8 mean?
03Why is “predict churn” incomplete?
07 · Apply in production

Late-delivery evaluation contract

Specify a cutoff-safe target, validation design, cost/capacity threshold, calibration report, uncertainty, and controlled experiment.

  • Decision and metric contract
  • Leakage-safe split tests
  • Threshold and calibration analysis
  • A/B guardrails and rollback
Open assignment and rubric
08 · Sources & next depth

Read primary material with a purpose.

09 · Production resolution

Return to the opening failure.

Store the decision contract, cutoff, split logic, threshold policy, uncertainty, and experiment design beside the model.

For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce a metric contract, leakage-safe validation, calibration analysis, and experiment plan.