Chapter 2 · Engineer the system

Containers and configuration without surprises

A container is reproducible only when its image, inputs, configuration, and outputs all have explicit identities.

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

A churn notebook cannot be reproduced by the teammate expected to ship it.

This chapter moves from pin the runtime to record resolved values. 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

Validate configuration types and ranges, redact secrets, then write the complete effective configuration into the manifest.

Evidence

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

Failure consequence

A mutable data/latest path and unpinned dependencies create a different model from the same command. 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 container freezes the runtime, but it does not freeze mutable data, hidden defaults, or a tag that later points somewhere else.

Reproducible containers are selected by immutable image digest and receive all run choices through validated configuration. The image supplies software; mounted inputs supply data; neither should be silently rewritten during training.

A single resolved configuration should be logged after defaults and overrides are applied. Without that snapshot, an operator can know which YAML file was passed yet still not know the values the program actually used.

Keep in view
  • run manifests
  • schema contracts
  • golden inference
  • idempotency
WORKED PATH

Follow the reasoning before touching the code.

  1. 01

    Pin the runtime

    Run an OCI image by digest so the same reference cannot resolve to new operating-system or library bits.

  2. 02

    Mount immutable inputs

    Expose data and configuration read-only, and give outputs a separate run-scoped writable location.

  3. 03

    Record resolved values

    Validate configuration types and ranges, redact secrets, then write the complete effective configuration into the manifest.

bashreproduce.sh
set -euo pipefail
IMAGE='ghcr.io/acme/trainer@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
DATA='snapshots/churn-2026-08.parquet'
CONFIG='configs/baseline.yaml'
test -r "$DATA"
test -r "$CONFIG"
mkdir -p outputs/run-017
docker run --rm --read-only -v "$PWD/$DATA:/input/data.parquet:ro" -v "$PWD/$CONFIG:/input/config.yaml:ro" -v "$PWD/outputs/run-017:/output" "$IMAGE" train --config /input/config.yaml

Launch a pinned trainer with read-only declared inputs.

READ THE EXAMPLE

What to notice

  • The digest identifies image content; a friendly tag such as latest would not.
  • Read-only mounts make accidental mutation fail immediately instead of corrupting the evidence for later replays.
YOUR TURN Pause and predict before revealing the answer.

Which value in this launcher still prevents two simultaneous invocations from being safely independent?

Need a hint?

Look for a destination chosen by a human rather than derived from run identity.

Check your reasoning

The fixed outputs/run-017 path can collide; derive a unique run-scoped path from the manifest ID and publish atomically.

Bring forward

Lessons 1, 2, 3 in this course.

03 · Formal treatment

Connect the chapter to the course’s quantitative spine.

A container is reproducible only when its image, inputs, configuration, and outputs all have explicit identities. The content-addressed run identity 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
run_id⁡=SHA256⁡(code∥data∥image∥config∥seed)\operatorname{run\_id} = \operatorname{SHA256}(\mathrm{code} \mathbin{\|} \mathrm{data} \mathbin{\|} \mathrm{image} \mathbin{\|} \mathrm{config} \mathbin{\|} \mathrm{seed})

Content-addressed run identity

Symbol, shape or unit contract
SymbolMeaning / shape / unit
codesource revision digest
dataimmutable dataset digest
imageOCI image digest
seeddeclared random seed
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: code, data, image, seed.
  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_c01(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.

Simplified simulation

Reproducibility fault injector

Change how many declared inputs remain mutable and observe replay parity.

inputs
Primary72.0%
Secondary3/5 captured
DiagnosisManifest incomplete

Assumption: Each mutable input independently creates a 14-point replay risk.

Open nonvisual data table
ItemComputed stateInterpretation
input 1mutablereplay risk
input 2mutablereplay risk
input 3content-addressedverified
input 4content-addressedverified
input 5content-addressedverified
05 · Production implications

Trace the complete operating path.

Carry the chapter’s central idea into the system: A container is reproducible only when its image, inputs, configuration, and outputs all have explicit identities. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.

  1. 01

    Turn “Pin the runtime” into a written invariant and a failing test.

  2. 02

    Promote reproduce.sh from illustration to a versioned implementation with representative fixtures.

  3. 03

    Use “Record resolved values” as the release checkpoint: Validate configuration types and ranges, redact secrets, then write the complete effective configuration into the manifest.

  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 mutable data/latest path and unpinned dependencies create a different model from the same command. 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%
01Does reusing a seed make changed data reproducible?
02Why record an image digest?
03What makes a retry safe?
07 · Apply in production

Reproducible baseline package

Design a Docker-only workflow that validates data, trains, evaluates, serializes, performs golden inference, and emits complete lineage.

  • Run manifest and data contract
  • Raw-input golden parity test
  • Failure and retry runbook
  • Model card with residual nondeterminism
Open assignment and rubric
08 · Sources & next depth

Read primary material with a purpose.

09 · Production resolution

Return to the opening failure.

Reject promotion when any artifact lacks lineage, golden raw-request parity, or a failure-safe recovery path.

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 seeded, tested, packaged, versioned training workflow with a model card.