The Warranty Window
A proactive inspection policy mixes point-in-time health signals with delayed outcomes and current-state fields. Rebuild the decision clock before allocating 500 inspection slots.
- ROLE
- Reliability Program Analyst
- TIMEBOX
- 90–120 minutes
- COMPLEXITY
- Advanced / 4 of 5
- ROTATION
- Brief 11 of 16
The decision has already reached your desk.
After the firmware incident, Reliability proposes enrolling 500 assets in a proactive inspection program. A draft rule combines current asset state, a sampled health table and a 30-day failure label.
The failure outcome is now available for retrospective evaluation, but it was not available when each intervention would have been chosen. Current master data, installation corrections and work-order outcomes also contain information learned later.
The program team needs an eligibility rule that could actually run prospectively, an honest estimate of its operational burden and a recommendation to launch, shadow or redesign the policy.
Approve, modify or refuse a 500-asset proactive inspection policy and define the exact eligibility rule that may be run prospectively.
Predictors must have been knowable at each health snapshot’s generated_at. Use failure labels only after failure_label_available_at as evaluation outcomes; do not use current asset state, later installation corrections or eventual work-order results as simulated predictors.
Run the brief as a controlled assignment.
The workbench mounts only the listed source neighborhood and supplies neutral starter worksheets. It does not grade the conclusion or reveal the mechanisms planted in the larger assignment.
- Open the dedicated brief workspace and confirm the brief ID in the queue.
- Establish table grain, cutoff and control totals before joining or modeling.
- Make at least two distinct evidence moves and test a credible rival explanation.
- Leave the requested polished artifact, then export the workspace or portfolio package.
The source files are shared; the draft workspace is not. Changing to another full assignment drops brief mode deliberately.
Real tables. A deliberately bounded neighborhood.
These Parquet files already belong to Meridian’s public 96-table estate. Use the mounted schema.table names in SQL or Python; download links are provided for learners working in a local DuckDB environment.
GRAIN / One current asset-master record.
CAUTION / Current site, state and extract fields are not necessarily historical facts at a health-snapshot decision time.
GRAIN / One effective installation period for an asset.
CAUTION / Some removals are recorded late, so both effective and recorded clocks matter.
GRAIN / One sampled asset-health snapshot for a date.
CAUTION / Repeated assets and delayed 30-day outcomes require entity-aware, point-in-time evaluation.
GRAIN / One service work order in the incident neighborhood.
CAUTION / Completion, first-time-fix and final-resolution fields are eventual operational outcomes.
ANALYSIS CUTOFF / 04 Jun 2025 / 05:00 ET evaluation cutoff
Questions to pressure-test—not steps to copy.
These prompts define the analytical territory without prescribing an order, technique or conclusion.
- 01
Which snapshot rows have fully matured 30-day labels at the evaluation cutoff?
- 02
Which candidate fields were genuinely available at each simulated inspection decision?
- 03
Does a simple rule perform consistently by firmware, region, installation history and telemetry completeness?
- 04
Would the 500-slot policy identify future risk, missing telemetry or cases already visible to operations?
Leave work another analyst can review.
Artifact presence can be recorded; analytical quality remains a human judgment. A complete brief has evidence, reasoning and a decision—not merely executed code.
- 01Point-in-time cohort contract
Separate eligible predictors, matured outcomes, repeated entities and prohibited later facts.
- 02Retrospective policy evaluation
Report reach, event capture, false-positive burden and material subgroup slices at the operating capacity.
- 03Inspection eligibility rule
Produce a reproducible 500-slot rule and at least one transparent sensitivity or challenger.
- 04Reliability program decision
Recommend launch, shadow or redesign with an explicit evidence and monitoring boundary.
Review the reasoning after a real attempt.
The debrief does not contain an official answer. It identifies defensible analytical moves, common failure modes and questions a reviewer may use to challenge the handoff.
SPOILER-GATED REVIEW / REVEAL AFTER YOUR FIRST HANDOFF
DEBRIEF REVEALED / THIS MAY CHANGE HOW YOU APPROACH THE BRIEF
A delayed outcome becomes valid evaluation evidence only after it matures; that never makes it a valid predictor at the earlier decision time.
Defensible approaches
- Use generated_at as the simulated feature boundary and failure_label_available_at as the evaluation boundary.
- Resolve installation context as of each snapshot and keep current-state and eventual work-order fields out of the predictor set.
- Compare a simple, operationally legible rule with a challenger at exactly 500 selections and control repeated assets during evaluation.
Common traps
- Using the future failure label, current asset state or completed-work-order outcome in the selection logic.
- Treating repeated daily rows from one asset as independent validation entities.
- Reporting unconstrained discrimination while ignoring the 500-slot decision and telemetry-coverage selection mechanism.
Reviewer questions
- Could the proposed rule have run on the stated snapshot date?
- Are repeated assets and label maturity handled in the evaluation design?
- Does the rule find preventable risk rather than work already underway or merely missing telemetry?
CHALLENGE A COLLEAGUE
Pass the Brief
The link shares this spoiler-free briefing. It never includes your work, identity, or browser progress.SUGGESTED NOTEA mature failure label is valid evidence—but only on the correct side of the decision clock. I designed The Warranty Window from The Analyst.
