Chapter 2 · Build and stress

Orchestration, metadata, experiments, and registries

Orchestration moves work; metadata and registry gates turn that work into reproducible, promotable evidence.

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

A late feature silently corrupts every downstream prediction.

This chapter moves from make tasks replay-safe to gate registry transitions. 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

Require evaluation, schema, parity, security, ownership, and rollback evidence before a model changes stage.

Evidence

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

Failure consequence

A backfill uses corrected future knowledge and silently inflates offline AUC. 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.

A successful task graph is not yet a reproducible ML run. Orchestration orders work; metadata explains what happened; experiment tracking compares evidence; and a registry controls which exact artifact may advance toward production.

An orchestrator should make dependencies, retries, schedules, and failure boundaries explicit. Idempotent tasks write to run-scoped staging locations and publish atomically, so retrying cannot duplicate side effects or expose partial output. Backfills become named, observable runs rather than manual edits to shared state.

Metadata links each run to code, configuration, data, environment, metrics, and artifacts. An experiment tracker organizes comparisons, while a registry records lifecycle state and approval evidence. Registering the best metric alone is insufficient: the evaluation contract, signatures, compatibility, and rollback candidate must travel with it.

Keep in view
  • Airflow/Dagster
  • MLflow
  • lineage
  • golden paths
WORKED PATH

Follow the reasoning before touching the code.

  1. 01

    Make tasks replay-safe

    Give every output a run identity, validate it before publication, and make promotion an atomic state change.

  2. 02

    Capture inputs automatically

    Record immutable code, data, image, configuration, seed, and parent-artifact identifiers from the execution environment.

  3. 03

    Gate registry transitions

    Require evaluation, schema, parity, security, ownership, and rollback evidence before a model changes stage.

pythonrun_manifest.py
import hashlib
import json

inputs = {
    'code': 'git:7f31c2a',
    'data': 'sha256:84d9',
    'image': 'sha256:02ab',
    'config': {'seed': 17, 'split': '2026-07'},
}
payload = json.dumps(inputs, sort_keys=True).encode()
run_id = hashlib.sha256(payload).hexdigest()[:12]
print(json.dumps({'run_id': run_id, **inputs}, indent=2))

Create a content-addressed record for an orchestrated run

READ THE EXAMPLE

What to notice

  • Sorting keys makes the same logical manifest produce the same identity even if dictionary insertion order differs.
  • Metrics are deliberately absent from the run identity because they are outputs; declared inputs determine which execution is being reproduced.
YOUR TURN Pause and predict before revealing the answer.

If a retry has the same run_id but finds only two of four expected artifacts, what should it do?

Need a hint?

A run identity names an intended immutable result, not permission to accept partial state.

Check your reasoning

It should keep the incomplete state isolated, recompute or verify missing outputs, validate the complete bundle, and publish atomically only when all expected artifacts agree with the manifest.

Bring forward

Lessons 1, 2, 3 in this course.

03 · Formal treatment

Connect the chapter to the course’s quantitative spine.

Orchestration moves work; metadata and registry gates turn that work into reproducible, promotable evidence. The point-in-time feature lookup 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
fj(tp)=value⁡ ⁣(arg max⁡etevent(e))subject to tevent(e), tavailable(e)≤tpf_j(t_p) = \operatorname{value}\!\left(\operatorname*{arg\,max}_e t_{\mathrm{event}}(e)\right) \quad \text{subject to } t_{\mathrm{event}}(e),\,t_{\mathrm{available}}(e) \le t_p

Point-in-time feature lookup

Symbol, shape or unit contract
SymbolMeaning / shape / unit
jentity
t_phistorical prediction time
eeligible event
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: j, t_p, e.
  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_c17(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

Point-in-time freshness lab

Delay feature arrival and see which historical rows remain eligible.

h
Primary4/5 eligible
Secondary6 h watermark
DiagnosisWithin SLA

Assumption: Five events have fixed prediction cutoffs separated by six hours.

Open nonvisual data table
ItemComputed stateInterpretation
row 1cutoff +0hnot yet knowable
row 2cutoff +6heligible
row 3cutoff +12heligible
row 4cutoff +18heligible
row 5cutoff +24heligible
05 · Production implications

Trace the complete operating path.

Carry the chapter’s central idea into the system: Orchestration moves work; metadata and registry gates turn that work into reproducible, promotable evidence. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.

  1. 01

    Turn “Make tasks replay-safe” into a written invariant and a failing test.

  2. 02

    Promote run_manifest.py from illustration to a versioned implementation with representative fixtures.

  3. 03

    Use “Gate registry transitions” as the release checkpoint: Require evaluation, schema, parity, security, ownership, and rollback evidence before a model changes stage.

  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

A backfill uses corrected future knowledge and silently inflates offline AUC. 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 constrain event and availability time?
02What should offline and online features share?
03What should incompatible schema change do?
07 · Apply in production

Local mini ML platform

Specify idempotent events, a point-in-time join, shared feature definition, quality gates, lineage, and model registration.

  • Data contract
  • Late-event semantics
  • Feature parity design
  • Lineage/registry record
Open assignment and rubric
08 · Sources & next depth

Read primary material with a purpose.

09 · Production resolution

Return to the opening failure.

Make temporal correctness, ownership, lineage, reproducibility, and escape hatches the platform defaults.

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 traced batch/stream platform with orchestration, registry, lineage, and ownership.