Chapter 3 · Resolve and operate

Paved roads, multi-tenancy, and cost boundaries

A good platform standardizes safety and evidence while keeping workload-specific choices visible and reversible.

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

A late feature silently corrupts every downstream prediction.

This chapter moves from find repeated journeys to expose tenancy economics. 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

Attribute queue time, accelerator hours, storage, and failures to owners and enforce fair, workload-aware limits.

Evidence

Verify the behavior illustrated in training-job.yaml, 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 paved road is a supported path that makes the safe thing easier: a standard training job, feature definition, deployment contract, and observability bundle. It succeeds when teams can move quickly without every workload being forced into the same shape.

Platform defaults should encode common controls—identity, lineage, secrets, retries, resource requests, tests, and rollback—while exposing documented escape hatches. Mandating one tool for every modality creates shadow infrastructure; offering only primitives makes every team rebuild reliability poorly.

Multi-tenancy turns noisy-neighbor risk into a product concern. Quotas, priority, admission control, isolation, and chargeback make contention visible. Cost boundaries should connect spend to an owner and useful unit such as trained example, successful prediction, or accepted token, not merely report a shared monthly bill.

Keep in view
  • lineage
  • golden paths
WORKED PATH

Follow the reasoning before touching the code.

  1. 01

    Find repeated journeys

    Study how teams actually train, publish, backfill, and serve; standardize high-frequency pain rather than hypothetical platform features.

  2. 02

    Encode guardrails

    Ship templates with resource limits, lineage, security, tests, telemetry, and rollback already wired, plus a reviewed escape path.

  3. 03

    Expose tenancy economics

    Attribute queue time, accelerator hours, storage, and failures to owners and enforce fair, workload-aware limits.

yamltraining-job.yaml
apiVersion: ml.example/v1
kind: TrainingJob
metadata:
  owner: ranking-team
spec:
  image: registry/train@sha256:02ab
  dataSnapshot: features/2026-08-28
  resources:
    gpu: 1
    maxRuntime: 4h
  retryPolicy: idempotent
  costCenter: marketplace-ranking

A golden-path request makes ownership and boundaries explicit

READ THE EXAMPLE

What to notice

  • The request exposes immutable inputs and accountable ownership without requiring each team to wire the underlying scheduler.
  • A maximum runtime and explicit GPU request create admission and cost boundaries before the job starts.
YOUR TURN Pause and predict before revealing the answer.

A research workload needs a custom distributed runtime unsupported by the template. What should a healthy paved road do?

Need a hint?

Balance safety and autonomy; an exception should not mean an invisible, permanent fork.

Check your reasoning

Offer a documented escape hatch with equivalent identity, security, cost, and telemetry controls, assign an owner, and use repeated exceptions as evidence for whether the road should expand.

Bring forward

Lessons 1, 2, 3, 4 in this course.

03 · Formal treatment

Connect the chapter to the course’s quantitative spine.

A good platform standardizes safety and evidence while keeping workload-specific choices visible and reversible. 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: A good platform standardizes safety and evidence while keeping workload-specific choices visible and reversible. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.

  1. 01

    Turn “Find repeated journeys” into a written invariant and a failing test.

  2. 02

    Promote training-job.yaml from illustration to a versioned implementation with representative fixtures.

  3. 03

    Use “Expose tenancy economics” as the release checkpoint: Attribute queue time, accelerator hours, storage, and failures to owners and enforce fair, workload-aware limits.

  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%
01What should offline and online features share?
02What should incompatible schema change do?
03Why constrain event and availability time?
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.

Course production assignmentLocal mini ML platform