LearnPortfolio CapstonesCapstone: Delivery ETA Prediction

⚙️HardMLOps & Deployment

Capstone: Delivery ETA Prediction

Ship a delivery-delay warning service with as-of features, versioned policy gates, baseline evidence, and monitored fallback.

17 min read

Learning path

Step 80 of 178 in the full curriculum

Design an Automated Support Agent Capstone: Product Ranking

Personalize this lesson

Adapt explanations and teaching visuals to your background and preferred voice.

Two hours after pickup, order O-201 is still in transit. The product question isn't "what minute will it arrive?" It's whether the service may show a delay warning, stay on normal tracking, or send the case to review because the evidence is stale.

Design an Automated Support Agent ended on a controlled action: reply, refuse, or hand off with evidence an operator can replay. Keep that habit for a conventional prediction service.

The service doesn't issue refunds or change carrier routing. It returns a risk score at a pinned prediction time with one of three actions: normal_tracking, warn_customer, or manual_review.

Pin the decision before you fit a model

Use one decision moment: two hours after first carrier pickup. Use one label: delivery after the promised end-of-day. A stored late_risk without those two pins can't be replayed, compared, or gated later.

Contract field	Pinned value
prediction event	two hours after first carrier pickup
label	delivered after promised end-of-day
score output	`late_risk` between zero and one
displayed action	warn only when the threshold passes and the evidence is fresh
unavailable data action	route to `manual_review`, no narrow ETA claim

This isn't a minute-accurate arrival clock. You score late-delivery risk at pickup plus two hours, then let a versioned policy gate decide whether a customer-facing warning is allowed.

The feature bundle includes route distance, service tier, origin backlog, scan age, weekday, and carrier code. Every field has to be rebuilt from data that both occurred and arrived by prediction time. Batch and Streaming Feature Pipelines already required event_time <= prediction_time and ingested_at <= prediction_time. Feast's historical retrieval does the same kind of point-in-time join: it scans backward from each entity timestamp up to the feature view's TTL, then joins the latest eligible row.^{[1]Reference 1Point-in-time Joinshttps://docs.feast.dev/getting-started/concepts/point-in-time-joins}

Diagram showing Carrier events as of pickup + 2h, Feature bundle v1 freshness checked, Delay model v1 risk score, and Policy gate evidence + score. — Carrier events as of pickup + 2h, Feature bundle v1 freshness checked, Delay model v1 risk score, and Policy gate evidence + score.

A high score never overrides a stale scan. The gate checks evidence first, then the threshold.

The portfolio artifact can follow this layout. The cells in this lesson prove policy, freshness, and the release receipt with frozen scores. Fitting train_booster.py under a time split stays in the training lab; don't claim you shipped a trained booster from this harness alone.

text

eta-prediction/
  data/
    feature_contract.json
    train_snapshot_manifest.json
  training/
    baseline.py
    train_booster.py
    evaluate_slices.py
  artifacts/
    delay_model_v1.json
    threshold_policy_v1.json
    metrics_v1.json
  service/
    api.py
    schemas.py
  monitoring/
    drift_window.py
  tests/
    test_point_in_time_features.py
    test_warning_gate.py

Prove the snapshot uses past events only

Pickup is 2026-05-01 10:00 UTC, so the pinned score time is noon. Order O-201 has three carrier scans. Work the two clocks by hand before writing a filter.

Scan	Event time	Ingested at	Known at noon?
`in_transit`	11:00	11:03	yes: both clocks are before 12:00
`hub_scan`	11:30	12:30	no: the event happened, but it arrived late
`carrier_delay_posted`	15:00	15:03	no: the event is still in the future

As-of grid for order O-201 at noon. The in_transit scan has event time 11:00 and ingest 11:03 in the 11:00 cell, so it is admitted. The hub_scan event at 11:30 sits left of the 12:00 cutoff while its ingest at 12:30 sits right of cutoff, so it is rejected as a late arrival. The carrier_delay event at 15:00 is entirely after noon and is rejected as a future event. — Event time left of noon isn't enough. `hub_scan` happened at 11:30, but it only becomes known at 12:30, so the noon row has to ignore it. The admitted scan is `in_transit` at 11:00, which makes `scan_age_hours` equal to 1.

The feature builder keeps the latest scan that passes both clocks. Scan age is then $t_{\text{pred}} - t_{\text{event}}$ for that admitted row: noon minus 11:00 is one hour.

The first receipt should fail if either leakage form sneaks in: a future event, or a pre-noon event that arrived after scoring.

01-scan-event-contract.py

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone
from math import isfinite

BASE_TIME = datetime(2026, 5, 1, 10, tzinfo=timezone.utc)

def at(hours: float) -> datetime:
    return BASE_TIME + timedelta(hours=hours)

@dataclass(frozen=True)
class ScanEvent:
    order_id: str
    event_time: datetime
    ingested_at: datetime
    status: str

@dataclass(frozen=True)
class FeatureRow:
    order_id: str
    prediction_at: datetime
    scan_age_hours: float | None
    backlog_age_hours: float | None
    tier: str
    feature_contract_id: str = "eta-features-v1"

@dataclass(frozen=True)
class ScoredRow:
    features: FeatureRow
    late_risk: float

SCAN_EVENTS = [
    ScanEvent("O-201", at(1), at(1.05), "in_transit"),
    ScanEvent("O-201", at(1.5), at(2.5), "hub_scan"),
    ScanEvent("O-201", at(5), at(5.05), "carrier_delay_posted"),
]

print("scan_events:", len(SCAN_EVENTS))
print("statuses:", [event.status for event in SCAN_EVENTS])

Output

scan_events: 3
statuses: ['in_transit', 'hub_scan', 'carrier_delay_posted']

The filter is two inequalities, not "the latest row in the table." event_time asks whether the world had already changed. ingested_at asks whether this service had already learned it.

02-as-of-admission-filter.py

def scans_known_by(order_id: str, prediction_at: datetime) -> list[ScanEvent]:
    return [
        event for event in SCAN_EVENTS
        if (
            event.order_id == order_id
            and event.event_time <= prediction_at
            and event.ingested_at <= prediction_at
        )
    ]

def latest_scan_known_by(order_id: str, prediction_at: datetime) -> ScanEvent:
    admitted = scans_known_by(order_id, prediction_at)
    if not admitted:
        raise ValueError("no scan available at prediction time")
    return max(admitted, key=lambda event: (event.event_time, event.ingested_at))

prediction_at = at(2)
admitted_scan_statuses = {event.status for event in scans_known_by("O-201", prediction_at)}
selected_scan = latest_scan_known_by("O-201", prediction_at)
print("prediction_at:", prediction_at.isoformat())
print("admitted:", sorted(admitted_scan_statuses))
print("selected:", selected_scan.status)

Output

prediction_at: 2026-05-01T12:00:00+00:00
admitted: ['in_transit']
selected: in_transit

03-build-feature-row.py

feature_row = FeatureRow(
    order_id="O-201",
    prediction_at=prediction_at,
    scan_age_hours=(prediction_at - selected_scan.event_time).total_seconds() / 3600,
    backlog_age_hours=2,
    tier="expedited",
)
feature_score = ScoredRow(feature_row, late_risk=0.62)

assert selected_scan.status == "in_transit"
assert admitted_scan_statuses == {"in_transit"}
assert feature_row.scan_age_hours == 1
print("selected_scan:", selected_scan.status, selected_scan.event_time.isoformat(), selected_scan.ingested_at.isoformat())
print("ignored_late_arrival:", SCAN_EVENTS[1].status, SCAN_EVENTS[1].event_time.isoformat(), SCAN_EVENTS[1].ingested_at.isoformat())
print("ignored_future_scan:", SCAN_EVENTS[2].status, SCAN_EVENTS[2].event_time.isoformat(), SCAN_EVENTS[2].ingested_at.isoformat())

Output

selected_scan: in_transit 2026-05-01T11:00:00+00:00 2026-05-01T11:03:00+00:00
ignored_late_arrival: hub_scan 2026-05-01T11:30:00+00:00 2026-05-01T12:30:00+00:00
ignored_future_scan: carrier_delay_posted 2026-05-01T15:00:00+00:00 2026-05-01T15:03:00+00:00

The 15:00 scan is useful when the true outcome arrives. It can't help a model that scores at noon. Neither can hub_scan: it occurred before noon but landed in the log afterward. Keep this test next to the feature builder so both leakage forms show up before anyone fits a tree.

Route scores through a versioned policy

A production late_risk comes from a trained artifact fit under a time split. Gradient Boosted Trees in Production is the right place to fit that candidate: boosted trees are a defensible choice for this kind of table, and XGBoost was designed as a scalable system for sparse tabular learning.^{[2]Reference 2XGBoost: A Scalable Tree Boosting System.https://www.kdd.org/kdd2016/papers/files/rfp0697-chenAemb.pdf} It still has to beat a rule baseline on the action policy, not on a model metric alone.

This harness keeps selected features separate from frozen scored output so you can grade policy and receipts without waiting on a booster fit. The response always emits a versioned trace: model, observed and expected feature contracts, threshold policy, prediction time, and freshness fields. An operator can replay why a customer saw a warning, or why a mismatched request fell back.

Freshness is part of the action contract. The latest carrier scan and the origin-backlog snapshot both have to be present, finite, non-negative, and recent enough. A missing contract version, invalid score, or invalid feature routes to review before the score can trigger a customer-facing message.

04-release-policy-contract.py

@dataclass(frozen=True)
class ReleasePolicy:
    threshold: float
    max_scan_age_hours: float
    max_backlog_age_hours: float
    model_id: str
    feature_contract_id: str
    threshold_policy_id: str

POLICY = ReleasePolicy(
    threshold=0.40,
    max_scan_age_hours=24,
    max_backlog_age_hours=8,
    model_id="delay-model-v1",
    feature_contract_id="eta-features-v1",
    threshold_policy_id="eta-threshold-v1",
)

def score(
    order_id: str,
    scan_age_hours: float | None,
    backlog_age_hours: float | None,
    tier: str,
    late_risk: float,
    feature_contract_id: str = "eta-features-v1",
) -> ScoredRow:
    return ScoredRow(
        FeatureRow(order_id, prediction_at, scan_age_hours, backlog_age_hours, tier, feature_contract_id),
        late_risk,
    )

def response(scored: ScoredRow, action: str, reason: str) -> dict[str, object]:
    row = scored.features
    return {
        "order_id": row.order_id,
        "action": action,
        "reason": reason,
        "late_risk": scored.late_risk,
        "prediction_at": row.prediction_at.isoformat(),
        "scan_age_hours": row.scan_age_hours,
        "backlog_age_hours": row.backlog_age_hours,
        "model_id": POLICY.model_id,
        "feature_contract_id": row.feature_contract_id,
        "expected_feature_contract_id": POLICY.feature_contract_id,
        "threshold_policy_id": POLICY.threshold_policy_id,
    }

print("policy:", POLICY.threshold_policy_id, "threshold=", POLICY.threshold)

Check evidence first, then the score. O-201 is fresh, late_risk is 0.62, and the threshold is 0.40, so it should warn. A stale or malformed row shouldn't.

05-freshness-and-route.py

def invalid_age(value: float | None) -> bool:
    return value is None or not isfinite(value) or value < 0

def input_issue(row: FeatureRow) -> str | None:
    if row.feature_contract_id != POLICY.feature_contract_id:
        return "feature_contract_mismatch"
    if invalid_age(row.scan_age_hours):
        return "invalid_scan_age"
    if invalid_age(row.backlog_age_hours):
        return "invalid_backlog_age"
    if row.scan_age_hours > POLICY.max_scan_age_hours:
        return "stale_scan_features"
    if row.backlog_age_hours > POLICY.max_backlog_age_hours:
        return "stale_backlog_features"
    return None

def route(scored: ScoredRow) -> dict[str, object]:
    issue = input_issue(scored.features)
    if issue is not None:
        return response(scored, "manual_review", issue)
    if not isfinite(scored.late_risk) or not 0 <= scored.late_risk <= 1:
        return response(scored, "manual_review", "invalid_late_risk")
    if scored.late_risk >= POLICY.threshold:
        return response(scored, "warn_customer", "late_risk_threshold")
    return response(scored, "normal_tracking", "below_threshold")

print("O-201 route:", route(feature_score)["action"], route(feature_score)["reason"])

06-policy-case-matrix.py

policy_cases = [
    feature_score,
    score("O-202", 3, 2, "standard", 0.25),
    score("O-203", 31, 2, "standard", 0.81),
    score("O-204", 4, 12, "standard", 0.75),
    score("O-205", 4, 2, "standard", float("nan")),
    score("O-206", 4, None, "standard", 0.75),
    score("O-207", float("nan"), 2, "standard", 0.75),
    score("O-208", -1, 2, "standard", 0.75),
    score("O-209", 4, 2, "standard", 0.75, "eta-features-v0"),
]

for scored in policy_cases:
    result = route(scored)
    print(scored.features.order_id, result["action"], result["reason"])

trace = route(feature_score)
print("release_tuple:", trace.get("feature_contract_id"), trace.get("model_id"), trace.get("threshold_policy_id"))

Output

O-201 warn_customer late_risk_threshold
O-202 normal_tracking below_threshold
O-203 manual_review stale_scan_features
O-204 manual_review stale_backlog_features
O-205 manual_review invalid_late_risk
O-206 manual_review invalid_backlog_age
O-207 manual_review invalid_scan_age
O-208 manual_review invalid_scan_age
O-209 manual_review feature_contract_mismatch
release_tuple: eta-features-v1 delay-model-v1 eta-threshold-v1

Orders O-203 and O-204 are the design result you want a reviewer to see. A high model score isn't authority to message a customer when the evidence is stale. O-205 through O-209 apply the same rule to a malformed score, a missing freshness field, an impossible age, and a contract mismatch: unreliable evidence reaches review, not a narrow ETA claim.

Publish evidence against the rule baseline

The release gate has to test the action policy, not only the fitted score. First fit a rule such as hours_since_last_scan >= 18. Then compare the candidate on the same time-ordered train, validation, and test splits. The holdout below uses later shipments with known outcomes.

A missed expedited warning costs 150 fixture units, a standard miss costs 60, and a false warning costs 8. Those are local teaching values, not universal business constants. Predict the ledger before you run it: the 18-hour rule never sees expedited late order E-301 (scan age 5), so it should pay 150. The candidate warns on that row, and it also warns on on-time E-304 (late_risk 0.58), so it should pay 8.

Holdout warning-cost ledger for four fresh orders. The 18-hour scan-age rule misses expedited late order E-301 and pays 150 fixture units. The candidate warns on E-301, E-302, and on-time E-304, so it pays 8 for one false warning and records zero expedited misses. — The cost drop isn't "the model is more accurate." The 18-hour scan-age rule misses expedited late `E-301` because its scan is only five hours old. The candidate catches that miss and pays one cheap false warning on `E-304`.

Required release rows:

Gate	Requirement
no feature leakage	replay test excludes post-prediction and late-arriving scans
expedited shipments	no missed warning in the required validation slice
expected warning cost	better than the rule baseline
feature freshness	stale scan or backlog returns fallback
API schema	model, feature, threshold, and freshness trace emitted

07-holdout-warning-cost.py

@dataclass(frozen=True)
class HoldoutCase:
    row: ScoredRow
    delivered_late: bool

holdout = [
    HoldoutCase(score("E-301", 5, 1, "expedited", 0.78), True),
    HoldoutCase(score("E-302", 20, 2, "standard", 0.64), True),
    HoldoutCase(score("E-303", 4, 1, "standard", 0.12), False),
    HoldoutCase(score("E-304", 3, 2, "standard", 0.58), False),
]

def warning_cost(case: HoldoutCase, warn: bool) -> int:
    if warn and not case.delivered_late:
        return 8
    if not warn and case.delivered_late:
        return 150 if case.row.features.tier == "expedited" else 60
    return 0

def baseline_warn(case: HoldoutCase) -> bool:
    row = case.row.features
    return input_issue(row) is None and row.scan_age_hours is not None and row.scan_age_hours >= 18

def candidate_warn(case: HoldoutCase) -> bool:
    return route(case.row)["action"] == "warn_customer"

print("holdout rows:", len(holdout))
print("baseline warns:", [case.row.features.order_id for case in holdout if baseline_warn(case)])

08-baseline-vs-candidate-cost.py

baseline_cost = sum(warning_cost(case, baseline_warn(case)) for case in holdout)
candidate_cost = sum(warning_cost(case, candidate_warn(case)) for case in holdout)
expedited_misses = sum(
    case.row.features.tier == "expedited" and case.delivered_late and not candidate_warn(case)
    for case in holdout
)
fallback_reasons = {row.features.order_id: route(row)["reason"] for row in policy_cases[2:]}
print("baseline_cost:", baseline_cost, "candidate_cost:", candidate_cost, "expedited_misses:", expedited_misses)

09-release-gate-checklist.py

trace_keys = {"feature_contract_id", "expected_feature_contract_id", "model_id", "threshold_policy_id"}
freshness_trace_keys = {"prediction_at", "scan_age_hours", "backlog_age_hours"}

# Multi-row point-in-time audit: every admitted train feature must land before prediction_at.
train_feature_events = [
    {"order_id": "O-201", "ingested_at": at(1.05), "prediction_at": at(2), "split": "train"},
    {"order_id": "O-210", "ingested_at": at(0.5), "prediction_at": at(2), "split": "train"},
    {"order_id": "O-211", "ingested_at": at(3), "prediction_at": at(4), "split": "holdout"},
]
train_max_event = max(
    event["ingested_at"] for event in train_feature_events if event["split"] == "train"
)
holdout_prediction_times = [
    event["prediction_at"] for event in train_feature_events if event["split"] == "holdout"
]
pit_ok = all(
    event["ingested_at"] <= event["prediction_at"] for event in train_feature_events
) and all(train_max_event < prediction_at for prediction_at in holdout_prediction_times)

release_gates = {
    "replay_excludes_unavailable_scans": admitted_scan_statuses == {"in_transit"},
    "multi_row_point_in_time_snapshot": pit_ok,
    "lower_cost_than_rule_baseline": candidate_cost < baseline_cost,
    "zero_expedited_misses": expedited_misses == 0,
    "stale_scan_falls_back": fallback_reasons["O-203"] == "stale_scan_features",
    "stale_backlog_falls_back": fallback_reasons["O-204"] == "stale_backlog_features",
    "invalid_score_falls_back": fallback_reasons["O-205"] == "invalid_late_risk",
    "missing_backlog_falls_back": fallback_reasons["O-206"] == "invalid_backlog_age",
    "invalid_scan_age_falls_back": fallback_reasons["O-207"] == "invalid_scan_age",
    "negative_scan_age_falls_back": fallback_reasons["O-208"] == "invalid_scan_age",
    "feature_contract_mismatch_falls_back": fallback_reasons["O-209"] == "feature_contract_mismatch",
    "versioned_trace": all(trace.get(key) for key in trace_keys),
    "freshness_trace": freshness_trace_keys.issubset(trace),
}

print("release_gates_pass:", all(release_gates.values()))

10-publish-release-receipt.py

receipt = {
    "bundle_id": "delivery-risk-v1",
    "evaluation_snapshot": "eta-holdout-2026-05",
    "previous_bundle": "delivery-risk-v0",
    "baseline_cost": baseline_cost,
    "candidate_cost": candidate_cost,
    "expedited_misses": expedited_misses,
    "release_gates": release_gates,
    "candidate_decision": "candidate_for_shadow" if all(release_gates.values()) else "hold",
}

print("bundle:", receipt["bundle_id"], "rollback:", receipt["previous_bundle"])
print("cost:", {"baseline": receipt["baseline_cost"], "candidate": receipt["candidate_cost"]})
print("release_gates_pass:", all(receipt["release_gates"].values()))
print("candidate_decision:", receipt["candidate_decision"])

Output

bundle: delivery-risk-v1 rollback: delivery-risk-v0
cost: {'baseline': 150, 'candidate': 8}
release_gates_pass: True
candidate_decision: candidate_for_shadow

That receipt isn't a production blessing. It says this frozen candidate is worth shadow traffic: no leaked events, visible versions, cheaper than the 18-hour rule on the holdout fixtures, and every stale or invalid path falls back.

The 0.78 / 0.64 / 0.12 / 0.58 scores stay frozen so the policy math doesn't move under you. You still need a trainer that can produce scores from a time-split table. Fit a small logistic model on the same three fields, then lock the probabilities. Don't retune after you open the holdout.

11-fit-then-freeze-scores.py

import numpy as np
from sklearn.linear_model import LogisticRegression

train_X = np.array(
    [
        [4.0, 1.0, 0.0],
        [20.0, 2.0, 0.0],
        [5.0, 1.0, 1.0],
        [3.0, 2.0, 0.0],
        [22.0, 1.0, 1.0],
        [2.0, 1.0, 0.0],
        [18.0, 3.0, 0.0],
        [6.0, 1.0, 1.0],
    ]
)
train_y = np.array([0, 1, 1, 0, 1, 0, 1, 1])
model = LogisticRegression(random_state=0, max_iter=200).fit(train_X, train_y)
holdout_X = np.array(
    [
        [5.0, 1.0, 1.0],
        [20.0, 2.0, 0.0],
        [4.0, 1.0, 0.0],
        [3.0, 2.0, 0.0],
    ]
)
frozen = model.predict_proba(holdout_X)[:, 1]
print("frozen holdout scores:", [round(float(score), 3) for score in frozen])

Output

frozen holdout scores: [0.659, 1.0, 0.311, 0.134]

This cell only shows you can fit scores. The earlier receipt still owns 0.78 / 0.64 / 0.12 / 0.58, so a solver upgrade can't rewrite the cost ledger. In the portfolio repo, write fitted probabilities into delay_model_v1.json and keep train_booster.py as the path that created them.

Operate the service after release

Each score should emit one row immediately: request timestamp, feature version, model version, threshold version, feature freshness, score, action, and later the delivery label. Immediate monitoring catches nulls, stale scans, error rate, and score-distribution shift. Delayed monitoring waits for labels, then computes missed-warning cost, calibration by score bucket, and slice performance. Monitoring Predictive Models separates those two clocks; this capstone should keep them separate in the portfolio artifact too.

Promotion should move a production alias from delivery-risk-v0 to a separately evaluated delivery-risk-v1. Google Cloud's MLOps guidance treats model validation as a comparison against the current or baseline model before promotion, and treats retraining as a pipeline that produces a new candidate rather than a silent overwrite of live serving.^{[3]Reference 3MLOps: Continuous Delivery and Automation Pipelines in Machine Learning.https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning} A triggered retraining job creates evidence. It doesn't rewrite the alias. Keep rollback available by retaining the prior alias target.

Submission checklist

Artifact	Reviewer should verify
feature contract	every field has type, timestamp boundary, and missing policy
training manifest	time split and dataset fingerprint exist
baseline comparison	candidate improves declared cost without required-slice misses
service API	stale inputs fail to a safer route
monitoring plan	input checks and delayed label metrics are distinct
rollback plan	prior artifact and threshold remain deployable

Practice: break the release contract

Use the runnable examples as a small release harness. Change one input at a time, predict the result, then rerun.

Move hub_scan ingestion from at(2.5) to at(1.75). Which scan should the as-of builder select?
Change O-204 backlog age from 12 to 7. Which action replaces manual_review?
Replace float("nan") with 1.4 for O-205. Why should the service still refuse the score?
Raise threshold from 0.40 to 0.80. Which expedited gate fails?
Remove threshold_policy_id from response(). Which release gate catches the incomplete trace?

Practice answer sketches

Next Step

Continue to Capstone: Product Ranking

You can now ship a scored action with time-safe features, a versioned policy, and a receipt that only grants shadow traffic. Ranking adds a new failure mode: the list you show becomes the data you later treat as truth, so eligibility and exposure logs matter as much as the scores.

PreviousDesign an Automated Support Agent

Share this article

X Facebook LinkedIn Bluesky Reddit Hacker News Email

References

Point-in-time Joins

Feast Contributors · 2026 · Official documentation

https://docs.feast.dev/getting-started/concepts/point-in-time-joins

XGBoost: A Scalable Tree Boosting System.

Chen, T. & Guestrin, C. · 2016 · KDD 2016

https://www.kdd.org/kdd2016/papers/files/rfp0697-chenAemb.pdf

MLOps: Continuous Delivery and Automation Pipelines in Machine Learning.

Google Cloud. · 2026 · Official documentation

https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

Discussion

Questions and insights from fellow learners.

Discussion loads when you reach this section.

Capstone: Delivery ETA Prediction

Pin the decision before you fit a model

Prove the snapshot uses past events only

Route scores through a versioned policy

Publish evidence against the rule baseline

Operate the service after release

Submission checklist

Practice: break the release contract

Practice answer sketches

What changes when `hub_scan` ingestion moves from `at(2.5)` to `at(1.75)`?

What changes when `O-204` backlog age falls from `12` to `7`?

Why does score `1.4` still route `O-205` to review?

Which gate fails when threshold moves from `0.40` to `0.80`?

Which gate fails when response trace drops `threshold_policy_id`?

Mastery Check

Discussion

What changes when hub_scan ingestion moves from at(2.5) to at(1.75)?

What changes when hub_scan ingestion moves from at(2.5) to at(1.75)?

What changes when O-204 backlog age falls from 12 to 7?

What changes when O-204 backlog age falls from 12 to 7?

Why does score 1.4 still route O-205 to review?

Why does score 1.4 still route O-205 to review?

Which gate fails when threshold moves from 0.40 to 0.80?

Which gate fails when threshold moves from 0.40 to 0.80?

Which gate fails when response trace drops threshold_policy_id?

Which gate fails when response trace drops threshold_policy_id?

Mastery Check

Discussion

What changes when `hub_scan` ingestion moves from `at(2.5)` to `at(1.75)`?

What changes when `O-204` backlog age falls from `12` to `7`?

Why does score `1.4` still route `O-205` to review?

Which gate fails when threshold moves from `0.40` to `0.80`?

Which gate fails when response trace drops `threshold_policy_id`?