Chapter 25 · Operate the capstone as a reproducible, diagnosable robot service

Today in the field story

One problem, then the next

The final uncut demonstration begins with visible build and scenario identity, follows one complete mission, injects a predeclared fault, and ends in a terminal state. Timecodes point to logs, traces, metrics, trial rows, and rollback evidence; the video never replaces them. The failure analysis separates fact, inference, unknown, containment, correction, verification, and residual risk. These artifacts become Week 26's strongest portfolio and interview material precisely because weak cases and scope boundaries remain visible beside the result.

Why now: Hiring evidence is credible when a reviewer can trace claims to unedited operational proof.
Ignore today: Do not publish secrets, customer data, or a highlight reel without denominators.
Unlocks next: A capstone release and incident story ready for truthful career conversion.

Understand

Build the physical picture first

An honest capstone handoff resembles a museum evidence case: continuous footage, labeled artifacts, untouched failures, and a short claim card stating exactly what visitors may conclude.

An uncut demo is one continuous recording from declared preflight through task and terminal state, without removing waits, recoveries, or failures. Start by showing the build, model, configuration, scenario, clock, test area, and evidence identity in a readable way; then keep the robot, operator actions, and decisive external outcome observable. A continuous video reduces selective editing, but it does not prove what happened outside the camera, authenticate files by itself, or replace logs, independent measurements, and the full trial table.

Publish an artifact manifest beside the video. Include source revision, image and model digests, configuration and calibration hashes, hardware and environment identities, commands, 50-trial protocol and results, logs, metrics, traces, incident bundles, checksums, creation times, tools needed to read them, access limits, and retention. Redact credentials and personal or proprietary data through an approved copy while preserving protected originals. A future reviewer should be able to distinguish missing, withheld, corrupted, and not-applicable artifacts.

Write failure analysis in layers. Facts are directly observed records; derived measurements show their method and uncertainty; hypotheses explain facts but remain testable; experiments support or weaken each hypothesis; corrective actions change a named mechanism; regression evidence tests recurrence. Avoid a single convenient “root cause” when credible alternatives remain. Also report failures that were not repaired, changes that could not be retested, and whether a fix invalidated the frozen acceptance suite.

Close with scoped claims and a next decision. State which ladder levels ran, which 50-trial gates passed or failed, which conditions were held out, what recovery was demonstrated, and what was never verified. Link practical work to an interview narrative: requirement, risk, design choice, failure, evidence, correction, and remaining limit. A weak result presented completely can be stronger hiring evidence than a polished success whose build, retries, and omitted failures cannot be inspected.

Words you need

Name each idea precisely

Uncut demonstration: A continuous recording of the declared run whose waits, interventions, retries, recovery, and terminal outcome are not removed by editing.
Physical example:
The video shows preflight, mission M310, a 12-second perception wait, one failed grasp, recovery, and final rejected outcome in one timeline.
Artifact manifest: A machine- and human-readable inventory that names each evidence file, identity, purpose, checksum, format, access condition, and relationship to a claim.
Physical example:
Row T038 links video time 06:42, mission events, trace, camera recording, result JSON, build digest, and SHA-256 checksum.
Provenance: The recorded origin and transformation history that explains who or what produced an artifact from which identified inputs.
Physical example:
The latency table names the trace file, analysis script revision, clock, filters, units, author, and generated output checksum.
Hypothesis: A falsifiable proposed explanation for observed facts, explicitly weaker than a confirmed causal conclusion.
Physical example:
Side-light glare may have shifted the pose estimate; replay and a controlled lamp sweep are proposed to challenge that explanation.
Corrective-action regression: A permanent test that recreates the confirmed failure mechanism and demonstrates the fix without breaking relevant nominal behavior.
Physical example:
The recorded cancellation ordering enters SIL regression, while HIL reruns target scheduling and the original failed acceptance suite remains unchanged.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalReliability, denominators, and fleet rates

Production robotics requires rates, raw counts, time windows, and recoverable releases.

availability: healthy service time divided by scheduled timeUnit: percent
MTTR: mean time to recoverUnit: minutes or hours
incidents/robot-hour: normalized incident rateUnit: 1/hour

Five robots each run 8 h, giving 40 robot-hours.
Two incidents occur, so rate = 2/40 = 0.05 incidents per robot-hour.
Keep raw counts and categories; compare versions under the same window before deciding whether reliability improved.

Programmer analogy

Use familiar observability and incident response, but join logs to robot ID, physical context, bag replay, and software/model version.

Three incidents across 60 robot-hours gives what rate?

3/60 = 0.05 incidents per robot-hour.

Failure rate is

r_{\mathrm{failure}}=\frac{F}{N}=\frac{4}{50}=8\%.

Category counts must reconcile: $2$ grounding $+1$ timeout $+1$ grasp $=4$ failures. Success is the complement only when outcome categories are mutually exclusive and complete.

Publish a failed acceptance gate without hiding the repair

The frozen ACC-25-v1 suite contains a failure at T038 under right-side light. A later development replay suggests glare causes a pose shift, and a camera-exposure correction improves that case.

Keep the original 50-trial result and T038 artifacts immutable; assign checksums, access controls, and manifest links instead of replacing T038 with the successful development rerun.
Build a fact timeline from video, source images, pose estimates, action trace, joint state, external placement oracle, and operator record, including clock uncertainty and any missing contact measurement.
Write the glare explanation as hypothesis H1, list alternatives such as calibration drift and object movement, and define controlled experiments that change one factor while preserving other identified inputs.
Record the exposure correction as a new configuration identity, run T038 as development regression plus relevant nominal cases, and state that this evidence is post-acceptance rather than part of ACC-25-v1.
Record one continuous demonstration of the current build with visible preflight and terminal oracle, then link its mission identity and timestamps to logs and result files without calling that single run a 50-trial pass.
Publish a claim card: ACC-25-v1 rejected; right-light failure reproduced in development; candidate correction passed named regression; new frozen acceptance suite not yet run, followed by remaining unknowns.

Result

Reviewers see the rejected original evidence, the strength and limits of the glare hypothesis, the separate corrective regression, and the exact missing re-acceptance step.

What this proves

Honesty is an engineering feature: keep the event, label later work, and make the strongest claim that all artifacts support—never the claim a polished story needs.

Physical examples

Where this appears in real life

Science-fair robot that misses once

A one-take video shows nine correct sorts and one dropped foam block, followed by the student pointing to the exact run record instead of restarting the camera.

Look for:

Continuity makes the miss visible; the manifest, independent count, configuration, and failure analysis make the footage useful evidence rather than embarrassment.

Sealed flight-recorder handoff

Investigators receive original recorder data, a verified working copy, timeline, instrument definitions, custody record, and a list of unavailable measurements.

Look for:

Preserving originals, transformations, access, and missing channels lets later reviewers challenge conclusions without overwriting the event.

Hands-on exercise

Make the idea observable

Use the week's existing artifacts and a safe simulated or already authorized recorded run. Do not stage new hazardous motion merely to make the video look dramatic.

Record one continuous 60–120 second run showing evidence identity, preflight, command, robot or simulator behavior, operator interventions, independent terminal outcome, and final status.
Create a manifest for source, deployment, scenario, trial results, video, logs, metrics, traces, replay, analysis, and checksums; mark unavailable and restricted artifacts explicitly.
Reconcile every spoken or written claim with at least one artifact and add the tested build, environment, evidence level, sample count, threshold, and known limitation.
Choose the largest remaining failure and build a table of facts, derived measurements, hypotheses, disconfirming evidence, experiments, corrective actions, regressions, and unresolved alternatives.
Verify that originals are read-only, shared copies contain no credentials or prohibited data, transformations have provenance, and links can be opened using the documented tools.
Ask a reviewer to find one failure from the summary, reconstruct its timeline, recalculate one count, and explain what remains unverified; fix the package wherever that path breaks.

Observe

The review catches claims supported only by narration, videos with hidden setup, overwritten failures, broken artifact links, untracked analysis transformations, and corrections incorrectly presented as original acceptance.

Done when

The uncut run and manifest are mutually traceable, the 50-trial decision reconciles, the largest failure remains inspectable, and the final claim card contains no stronger statement than the evidence allows.

Build today

Build a SIL→HIL→hardware CI ladder with containers, diagnostics, fleet telemetry, rollback, failure replay, and a frozen 50-trial acceptance suite.

Evidence to save

DONE when the weekly ship note explains how “Publish uncut demos plus honest failure analysis” changed the build, what still fails, and the first task for next week.

Project gate

Gate 6 · Capstone passes its frozen acceptance suite and exposes failures instead of hiding them.

Common mistakes

Catch the wrong mental model

Wrong

Editing pauses and failed attempts out of a video labeled uncut.

Better

Keep one continuous timeline, show interventions and terminal status, and publish shorter edited highlights only as separately labeled navigation aids.

Wrong

Replacing original acceptance artifacts after a fix succeeds.

Better

Preserve the rejected run, version the corrective configuration and regression separately, and require a new frozen suite for any new acceptance claim.

Wrong

Writing a confident root cause from one correlation.

Better

Separate observations, measurements, hypotheses, alternatives, experiments, and causal conclusions; state inconclusive when evidence cannot distinguish credible mechanisms.

Job connection

How this becomes employable evidence

Deliver a production-readiness evidence pack to engineering, operations, customers, and incident reviewers; make operator-visible outcomes auditable, defend bounded claims, preserve failed acceptance, and show corrective regression without rewriting history.

Relevant target roles

Robotics Deployment, Integration & Validation Engineer
Robot Learning Deployment / Physical AI Integration Engineer
Robot HMI / Control & Monitoring Engineer
Robot Fleet Backend / Platform Engineer

Chapter 25 interview drill

Interview questions: Publish uncut demos plus honest failure analysis

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

Present a robot project whose frozen acceptance run failed one gate. Walk through the uncut evidence, artifact provenance, fact-versus-hypothesis analysis, correction, regression, and precise claim you would make today.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1What does an uncut demo add, and what does it not replace?

Model interview answer

It exposes continuity, waits, interventions, and outcome, but it does not replace artifact authentication, full trial counts, independent measurements, or off-camera state evidence.

Q2How should a successful post-fix replay appear in the acceptance report?

Model interview answer

As separately versioned corrective or development evidence; the original failed run stays intact, and re-acceptance requires a new frozen protocol execution.

Q3When may the report say root cause confirmed?

Model interview answer

When evidence demonstrates the causal mechanism, the targeted change removes it, relevant regression passes, and credible alternatives are excluded or bounded—not merely when events correlate.

Chapter starter artifact

Stop promotion when rollback evidence is missing

Complete Release Train Fifty with a risk-linked SIL/HIL/hardware matrix, immutable deployment manifest, replayable incident bundle, rollback drill, frozen unseen-condition matrix, exactly 50 adjudicated trials, and an uncut evidence-linked release report.

week-25-release-train-fifty.mjsJavaScriptDownload starter

const allowedStages = new Set(["SIL", "HIL", "HARDWARE"]);
const sil = {
  stage: "SIL",
  testsPassed: true,
  rollbackProved: true,
};
const plantedFailure = {
  stage: "HIL",
  testsPassed: true,
  rollbackProved: false,
};
const unknownStage = { ...sil, stage: "FIELD" };
const nonBooleanFlags = { ...sil, testsPassed: "true" };

function promotion(stage) {
  if (!allowedStages.has(stage?.stage)) return "BLOCK stage";
  if (typeof stage.testsPassed !== "boolean" ||
      typeof stage.rollbackProved !== "boolean") return "BLOCK schema";
  if (!stage.testsPassed) return "BLOCK tests";
  if (!stage.rollbackProved) return "BLOCK rollback";
  return "PASS";
}

console.log("SIL station: " + promotion(sil));
console.log("planted HIL fault: " + promotion(plantedFailure));
console.log("unknown station: " + promotion(unknownStage));
console.log("non-boolean flags: " + promotion(nonBooleanFlags));
console.log("hardware station: UNVERIFIED");
console.log("release train: HOLD");

Download the file into your terminal's current folder, then run the command below. The expected output is exact.

Run: node week-25-release-train-fifty.mjs
Expected output: SIL station: PASS planted HIL fault: BLOCK rollback unknown station: BLOCK stage non-boolean flags: BLOCK schema hardware station: UNVERIFIED release train: HOLD
Planted failure to diagnose: The HIL rollback gap, unknown station, and non-boolean gate flags each stop promotion rather than inheriting a pass from truthy or unrecognized values.