Lesson 4.1.1 — Defining the Capstone

Week 31

Prerequisite lessons: 1.1.4 (the full-stack pick-and-place pipeline), 2.1.2 (object detection and 6D pose estimation), 2.3.1 (grasp synthesis and quality), 3.1.4 (VLA fine-tuning), 3.2.3 (planning with world models), 3.3.4 (safety and constraints on LLM outputs), 3.4.4 (real-to-sim adaptation).

Prior results used in this lesson. From 1.1.4: the seven-stage pipeline and its health checks. From 2.1.2: the 6D pose estimator and its covariance. From 2.3.1: force closure and the $\varepsilon$ grasp-quality metric. From 3.1.4: the decision conjunction and the seven-phase fine-tuning pipeline. From 3.2.3: the receding-horizon planner and its four safety checks. From 3.3.4: the four-layer constraint stack and the residual-risk register. From 3.4.4: the closed adaptation loop. Each is restated at the point of use.

What this lesson hands forward. The capstone’s task definition, the subsystem decomposition, the evaluation’s design, and the risk register. Lesson 4.1.2 chooses the embodiment and the evaluation’s held-out suite against this definition. Lesson 4.1.3 designs the test suite’s stratification. Module 4.2 builds the subsystems this lesson names. Module 4.3 iterates against the metrics this lesson defines. Module 4.4 defends the result against the criteria this lesson sets.

The running case in one sentence. The running arm, gripper, eye-in-hand camera, table, cube, bin, and divider are unchanged; the capstone adds clutter — three distractor objects on the table — and the instruction is a conditional that requires the arm to pick the cube, avoid the distractors, and place it in the bin while satisfying the 3.3.4 safety stack.

§L.0 — Lesson map, objectives, and misconceptions

Observable outcomes. By the end of this lesson you can, without notes: (1) state the three properties a capstone must have and why each is necessary; (2) write the capability matrix that maps each module to the capstone’s demonstration; (3) decompose the capstone into seven subsystems and name each interface; (4) state the interface contract and the failure mode that crosses each interface; (5) design the evaluation’s metrics, splits, and stratification; (6) state the held-out discipline’s three preconditions; (7) write the scope’s in and out lists and the scope-creep’s signature; (8) write the risk register with five entries and their residuals; (9) freeze the running case’s capstone definition with its success criteria; (10) state the criterion for the capstone’s acceptance and the artifacts that evidence it.

Misconception inventory.

Everything is self-contained. Where a prerequisite lesson is used, the result is restated at the point of use.

§L.0.5 — Retrieval warm-up

Q1. In 1.1.4, the seven-stage pipeline had health checks at each boundary between perception, frame audit, IK, trajectory, control, state machine, and error recovery. Why were the checks at the boundaries rather than inside the stages?

Answer. Because the stages were individually tested and the integration’s failures were at the boundaries — a stage’s output interpreted differently by the next stage. The checks at the boundaries caught the interpretation errors. Used in §L.B.2 to define the capstone’s interface contracts.

Q2. In 2.3.1, a grasp is force-closed when every external wrench can be resisted by contact forces inside the friction cones, and the $\varepsilon$ metric is the radius of the largest wrench-space ball. What does a positive $\varepsilon$ guarantee, and what does it not?

Answer. It guarantees that the grasp can resist wrenches in all directions up to the radius; it does not guarantee that the grasp is reachable, that the approach is collision-free, or that the object’s pose is known precisely enough for the grasp. Used in §L.C.1 to separate the grasp’s quality from the capstone’s success.

Q3. In 3.2.3, the receding-horizon planner had a usable horizon bounded by the model’s accuracy. What does the planner’s horizon bound in the capstone?

Answer. The length of the action sequence the planner can commit to without re-observation; the capstone’s execution length $E$ is chosen against the horizon and the control period. Used in §L.B.3 to define the planner’s interface.

Q4. In 3.3.4, the residual-risk register had five fields including the residual column. Why is the residual the entry’s acceptance?

Answer. Because the residual is what the operator actually accepts; a mitigation without a residual claims completeness, which no real system has. Used in §L.D.3 to write the capstone’s risk register.

Part A — What a capstone is

§L.A.1 — The integration’s difficulty

A capstone is a synthesis project that demonstrates mastery by integrating the curriculum’s modules into a single working system. The word “synthesis” is the operative one: the capstone’s difficulty is not that each subsystem is hard — the labs already built each — but that the subsystems must compose, and composition is where the failures concentrate.

The composition’s difficulty has three sources, and each is the reason the capstone’s definition is a lesson rather than an afterthought.

The interfaces are underspecified by the modules. Each module’s lab defined its subsystem’s input and output in the module’s terms; the composition requires the outputs to be interpreted by the next subsystem’s inputs, and the interpretations are where the errors appear. The 1.1.4 pipeline’s health checks were the first response to this problem, and the capstone’s interface contracts are the second.

The failure modes are new. A subsystem that works in isolation can fail when its input’s distribution shifts, when its output’s consumer has a different tolerance, or when its latency exceeds the composition’s budget. The 3.3.4 §L.B’s four-layer stack’s blind spots are the individual layers’; the capstone’s failure modes are the gaps between the blind spots, which no module’s lab exercised.

The evaluation must be conclusive. A capstone whose success rate is 70% on a task whose distribution is unclear demonstrates nothing; the evaluation must be designed so that the result — whatever it is — is evidence. The 3.1.4 §L.D.1’s lower-bound acceptance and the 3.4.1 §L.C.1’s tail metric are the tools, and the capstone’s evaluation’s design is their application.

§L.A.2 — The three properties

A capstone that demonstrates mastery has three properties, and each is necessary.

Integration. It uses at least five of the curriculum’s modules in a single system, and the modules’ interfaces are explicit. A capstone that uses two modules is a lab; one that uses five with explicit interfaces is a synthesis.

Evaluation. It has a held-out evaluation whose distribution is stated, whose metrics are defined before the system is built, and whose result is reported with a confidence interval. A capstone without this is a demonstration; with it, it is evidence.

Failure analysis. It has a documented failure taxonomy whose entries were observed on the system, not hypothesized. A capstone whose failures are unknown has not been tested; one whose failures are catalogued has been understood.

The three properties are the capstone’s acceptance criteria, and §L.E.3 turns them into the running case’s specific criteria.

Self-explanation 1. Why is a capstone with a 95% success rate and no failure taxonomy not a capstone?

Answer. Because the success rate is a point estimate whose distribution is unstated and whose failures are unexamined; the mastery is in the understanding, not the number, and the number without the understanding is not evidence of mastery.

§L.A.3 — The capability matrix

The capability matrix maps each module to the capstone’s demonstration. Its rows are the curriculum’s modules; its columns are the capstone’s subsystems; its cells state whether the module contributes to the subsystem and how.

The running case’s matrix, at the module level.

The matrix’s value is the coverage argument. Each subsystem has a primary module, and the capstone’s demonstration of each subsystem is the primary module’s result’s application. A subsystem with no primary module is a gap in the curriculum; a module with no cell is a module the capstone does not exercise. The running case’s matrix has no empty rows and no empty columns, which is the coverage argument.

The matrix’s cell’s “how” is the interface’s contract. The 2.1 module’s primary contribution to perception is the 2.1.2 pose estimator; its contributing contribution to reasoning is the pose’s use as the reference’s grounding. The “how” is what the interface contract states.

Worked-example ladder.

WE-L.A.a (fully worked). The capability matrix has nine modules and six subsystems. Compute the coverage argument’s failure if the 3.2 world models’ cell in the planning’s column were empty.

Solution. The planning’s subsystem would have 2.3 as its primary and 2.2 as contributing, and 3.2’s absence would mean the model-based planning’s method is not exercised. The coverage argument fails for the planning’s subsystem’s method — the planner’s forward model — even though the subsystem has a primary. The fix is either to add 3.2 to the planning’s cell or to state that the capstone’s planning uses only the 2.3.2 classical planner.

WE-L.A.b (completion). The 3.1 VLA’s cell in the reasoning’s column is empty. Does the coverage argument fail? Completion. The reasoning’s subsystem’s primary is 3.3, and 3.1’s absence means the VLA is not the reasoning’s mechanism. The VLA is the task layer below the reasoning, and its cell belongs in the perception and the control’s columns, not the reasoning’s. The completion shows the matrix’s structure is the subsystems’ design, not a checklist.

WE-L.A.c (faded). Write the interface contract for the perception-to-reasoning interface. Faded step. The perception outputs the object’s pose with its covariance; the reasoning consumes the pose as the reference’s grounding and the covariance as the affordance’s uncertainty. The contract states the pose’s frame, the covariance’s form, and the freshness’s bound. Completion. The contract’s failure mode is the stale pose: the reasoning grounds a reference on a pose that has moved, and the 3.3.4 §L.B.2’s semantic layer’s check is the guard.

WE-L.A.d (contrastive near-miss). A learner’s capstone uses every module and has no evaluation, arguing that the breadth is the demonstration. Why it fails: the breadth without an evaluation is a demonstration, not evidence; the mastery’s claim is the evaluation’s, and the breadth without it is untested. The fix: the evaluation’s design precedes the system’s build, per §L.C.

Comparative table: the three properties.

Design principle P50.1. A capstone is an integration with an evaluation and a failure analysis; the integration’s difficulty is the interfaces, and the evaluation’s and the analysis’s are what make the result evidence.

Consolidation checkpoint 1

(a) Three capabilities. You can state the composition’s three sources of difficulty. You can write the capability matrix and the coverage argument. You can state the three properties and their tests.

(b) Transfer probe. A capstone uses the perception, the reasoning, the grasping, and the control modules. Does it satisfy the integration’s property? Answer: yes, four modules is above the five-module threshold only if the interfaces are explicit; the count is necessary and the interfaces are sufficient. The matrix’s cells are the evidence.

(c) Remediation rule. If you cannot state why the interfaces are the difficulty, re-read §L.A.1 before Part B.

Part B — The subsystem decomposition

§L.B.1 — The seven subsystems

The running case’s capstone decomposes into seven subsystems, each with a primary module and an explicit interface.

Perception. The eye-in-hand camera’s images to the object poses and the scene’s geometry. Primary module: 2.1. The output is the 2.1.2 pose with its covariance, the 2.1.4 point cloud, and the 2.1.1 camera model’s projection.

Scene understanding. The instruction and the scene’s poses to the task’s goal. Primary module: 3.3. The output is the 3.3.1 HTN decomposition with its grounded references, verified by the 3.3.1 verifier and gated by the 3.3.4 stack’s semantic layer.

Grasp planning. The object’s pose and the gripper’s capability to a grasp pose and its quality. Primary module: 2.3. The output is the 2.3.1 $\varepsilon$ and the 3.3.3 affordance’s truth.

Motion planning. The grasp pose and the scene’s obstacles to a collision-free trajectory. Primary module: 2.3.2. The output is the path with the clearance margin and the 3.2.3 planner’s goal states.

Control. The trajectory to the joint torques, with the 2.3.3 impedance’s force management. Primary module: 1.1. The output is the 1.1.3 computed-torque law’s torques and the 2.3.3 contact’s forces.

Safety. The four-layer stack of 3.3.4 and the 2.2.4 Q-shield, wrapping every action. Primary module: 3.3. The output is the accept or the reject with the layer’s reason.

Transfer. The 3.4.4 adaptation’s mapping and the 3.4.1 twin-track’s validation. Primary module: 3.4. The output is the adapted policy and the alignment’s MMD.

The seven subsystems’ primary modules are the matrix’s rows’ primaries, and the interfaces between them are the matrix’s contributing cells’ “how”.

§L.B.2 — The interface contracts

Each interface has a contract with four fields: the producer, the consumer, the data’s form, and the failure mode. The failure mode is the contract’s purpose, because the contract’s check is the guard against it.

Perception to scene understanding. Data: the pose with its covariance and the freshness’s timestamp. Failure mode: the stale pose. Guard: the freshness bound and the 3.3.4 §L.B.2’s reference check.

Scene understanding to grasp planning. Data: the grounded reference and the affordance’s truth. Failure mode: the reference’s ambiguity. Guard: the 3.3.1 verifier’s uniqueness check.

Grasp planning to motion planning. Data: the grasp pose and the approach’s direction. Failure mode: the grasp is feasible and the approach is blocked. Guard: the 2.3.2 clearance check and the 3.3.4 §L.B.4’s collision’s layer.

Motion planning to control. Data: the trajectory’s waypoints and the timing. Failure mode: the trajectory’s timing mismatches the control’s period. Guard: the 3.1.4 §L.C.2’s action-scale convention’s assertion.

Control to safety. Data: the torques and the contact’s forces. Failure mode: the force exceeds the limit. Guard: the 2.3.3 force limit and the 2.2.4 Q-shield.

Safety to transfer. Data: the accepted actions and the rejection’s reasons. Failure mode: the shield’s rejections cluster at a state the transfer’s policy has not seen. Guard: the 3.4.4 §L.C.3’s loop’s monitor.

The six contracts cover the seven subsystems’ six interfaces (the chain’s edges). The contracts’ checks are the 3.3.4 stack’s layers’ distributed across the interfaces, and the stack’s composition is the contracts’ composition.

Self-explanation 2. Why is the interface contract’s failure mode the contract’s purpose rather than the data’s form?

Answer. Because the data’s form is what the modules already specify, and the failure mode is what the composition adds — the interpretation’s error that no single module’s lab exercised.

§L.B.3 — The latency budget

The composition’s latency is the sum of the subsystems’ latencies along the critical path, and the budget is the control period’s. For the running case at 10 Hz, the period is 100 ms, and the subsystems’ budgets are:

• perception: 30 ms (the 2.1.2 estimator’s inference);
• scene understanding: 200 ms (the 3.3.1 LLM’s call), which is outside the control loop because it runs at the task’s start, not per step;
• grasp planning: 20 ms (the 2.3.1 proposal and check);
• motion planning: 20 ms (the 3.2.3 planner’s query);
• control: 1 ms (the 1.1.3 computed-torque law’s evaluation);
• safety: 5 ms (the 3.3.4 stack’s four layers);
• transfer: 0 ms (the mapping is in the training loop, per 3.4.4 §L.A.3).

The per-step total is $30 + 20 + 20 + 1 + 5 = 76$ ms, which is within the 100 ms period with 24 ms of margin. The scene understanding’s 200 ms is the task’s start’s cost, not the loop’s.

The latency’s design is the capstone’s first integration constraint: a subsystem that fits the module’s lab’s budget can exceed the composition’s, and the 3.3.4 §L.B.4’s physical layer’s 0.1 ms is the only one that is free.

§L.B.4 — The integration’s test strategy

The integration’s tests are the interface contracts’ tests, not the subsystems’ tests. The subsystems’ tests are the labs’; the capstone’s tests are the contracts’.

The strategy has three layers.

Unit tests. Each subsystem’s output on a fixed input, compared to the module’s lab’s result. These are the regression tests, and they catch a subsystem’s drift during the integration.

Contract tests. Each interface’s data on a fixed pair of subsystems, compared to the contract’s form. The contract’s failure mode’s guard is the test, and the test’s injection is the failure mode’s simulation.

End-to-end tests. The full pipeline on the held-out evaluation’s episodes. These are the capstone’s evidence, and their metric is the 3.4.1 §L.C.1’s tail and the 3.1.4 §L.D.1’s lower bound.

The three layers’ costs are the units’ seconds, the contracts’ minutes, and the end-to-end’s hours; the layers’ frequencies are the units’ every change, the contracts’ every interface change, and the end-to-end’s every milestone. The strategy’s design is the 3.1.4 §L.A.1’s seven phases’ structure applied to the integration.

Worked-example ladder.

WE-L.B.a (fully worked). The perception’s 30 ms, the grasp’s 20 ms, the motion’s 20 ms, the control’s 1 ms, and the safety’s 5 ms sum to 76 ms. The control period is 100 ms. Compute the margin and state the subsystem that would break it first if its latency doubled.

Solution. The margin is 24 ms. The perception’s doubling to 60 ms would consume 30 ms of the margin, exceeding the 24 ms; the grasp’s doubling to 40 ms would consume 20 ms, within the margin. The perception is the first to break the budget, and its optimization is the integration’s first latency priority.

WE-L.B.b (completion). The motion planner’s query rises to 50 ms because the clutter’s obstacles increase the sampling’s dimension. Recompute the total and state the fix. Completion. The total is $30 + 20 + 50 + 1 + 5 = 106$ ms, above the 100 ms period. The fix is either the planner’s horizon’s reduction or the control period’s increase to 150 ms, and the choice is by the task’s reactivity requirement.

WE-L.B.c (faded). Write the contract test for the perception-to-scene-understanding interface and state its injection. Faded step. The test feeds a pose with a 200 ms old timestamp and checks that the reference check rejects it. Completion. The injection is the stale timestamp, and the guard is the freshness’s check; the test’s pass condition is the rejection’s reason’s correctness.

WE-L.B.d (contrastive near-miss). A team tests each subsystem on its module’s lab’s data and the composed system fails on the held-out’s first episode. Why it fails: the subsystems’ tests used the labs’ distributions, and the composition’s distributions differ — the perception’s pose is noisier under the clutter, and the grasp’s quality falls. The fix: the contract tests and the end-to-end tests, not only the unit tests.

Comparative table: the integration’s tests.

Design principle P50.2. Test the contracts, not only the subsystems; the composition’s failures are at the boundaries, and the boundaries’ tests are the integration’s evidence.

Consolidation checkpoint 2

(a) Three capabilities. You can name the seven subsystems and their primary modules. You can write an interface contract with its four fields. You can compute the latency budget and identify the first subsystem to break it.

(b) Transfer probe. The scene understanding’s 200 ms is outside the loop. What would happen if it were inside? Answer: the loop’s period would need to be at least 276 ms, and the reactivity would fall; the task’s start’s cost is affordable, and the per-step cost is not.

(c) Remediation rule. If you cannot state why the contract tests are necessary, re-read §L.B.4 before Part C.

Part C — The evaluation’s design

§L.C.1 — The metrics

The evaluation’s metrics are chosen before the system is built, and each is a decision criterion, not a report’s number.

Success rate. The fraction of episodes whose instruction is achieved. The metric’s definition includes the instruction’s condition — the 3.3.1 conditional’s branch must be the correct one — and the achievement’s check is the final state’s, not the operator’s opinion.

Placement error. The cube’s final pose’s distance from the bin’s target pose. The 3.4.1 §L.C.1’s tail metric applies: the 95th percentile, not the mean.

Time. The episode’s duration, from the instruction to the placement’s completion. The metric’s bound is the deployment’s cycle time.

Peak contact force. The maximum force at any contact, from the 2.3.3 momentum observer. The metric’s bound is the 20 N safety limit.

Recovery rate. The fraction of episodes whose first attempt failed and whose recovery succeeded. The metric is the 3.3.2 §L.C.2’s recovery’s effectiveness.

Safety violations. The count of the 3.3.4 stack’s precondition violations. The metric’s target is zero.

The six metrics are the evaluation’s primary set, and the 3.3.4 §L.D.3’s certification checklist’s “layer coverage” entry is the stack’s metrics’ complement.

§L.C.2 — The splits and the stratification

The evaluation’s split is by episode, stratified by task, object, operator, and collection batch — the 3.1.3 §L.D.2’s discipline. The capstone’s addition is the clutter’s stratification: the held-out set’s clutter’s configurations must cover the deployment’s, and the distractor objects’ identities are the strata.

The split’s sizes are the 3.1.3 §L.D.2’s standard-error arithmetic. For a 90% success rate and a 3-point half-width at 95% confidence, the test set’s size is

so 400 episodes is the test set’s size for the 3-point resolution. The capstone’s evaluation’s total is the 400 test episodes plus the training’s episodes, and the 3.1.3 §L.E.1’s collection’s plan is the arithmetic’s source.

The stratification’s discipline is the 3.1.4 §L.D.1’s three axes — seen task, unseen object, unseen phrasing — plus the capstone’s fourth axis, the clutter’s configuration. The four axes’ held-out sets are disjoint, and the report’s table has a row per axis.

§L.C.3 — The evaluation’s three preconditions

The evaluation’s evidence is valid only if three preconditions hold, and each is a place where the capstone’s report can be over-read.

The distribution is stated. The test set’s distribution — the objects, the poses, the clutter’s configurations, the instruction’s phrasings — is documented, and the result’s claim is about that distribution, not about “the real world”. The 3.3.4 §L.D.3’s certification checklist’s “distribution coverage” entry is the documentation’s requirement.

The system is frozen. The evaluation runs on a checkpoint that is not further trained; the 3.1.4 §L.A.1’s policy freeze’s discipline applies. A system that is evaluated while being tuned is evaluated on its training’s distribution’s leakage.

The baseline is stated. The evaluation’s result is compared to a baseline — the 1.1.4 specialist pipeline, the 3.1.4 fine-tuned VLA, or the 3.4.4 adapted policy — and the comparison’s margin is the capstone’s claim. A result without a baseline is a number without a claim.

Self-explanation 3. Why is the baseline’s statement a precondition rather than a report’s detail?

Answer. Because the capstone’s claim is the integration’s benefit over the alternatives, and a result without a baseline is a performance’s statement whose value is unknown; the comparison is the claim’s content.

Concept check. A capstone reports 92% success on 400 episodes and claims general competence. Which precondition is violated?

Answer. The distribution’s statement; the 400 episodes’ distribution is the test set’s, and “general competence” is a claim about a distribution the test did not sample. The claim’s scope must be the test’s. [displaces M2]

Worked-example ladder.

WE-L.C.a (fully worked). A capstone’s test set has 400 episodes, and the success rate is 0.92. Compute the 95% lower bound and state whether it meets a 0.90 requirement.

Solution. $\text{SE} = \sqrt{0.92 \times 0.08/400} = 0.0136$; the lower bound is $0.92 - 1.645 \times 0.0136 = 0.898$. The bound is below 0.90, so the acceptance at the 95% level fails even though the point estimate is above.

WE-L.C.b (completion). The test set is expanded to 1,600. Recompute the lower bound and decide. Completion. $\text{SE} = 0.0068$; the lower bound is $0.92 - 0.0112 = 0.909$, which meets the requirement. The completion shows the test set’s size is the acceptance’s resolution’s determinant.

WE-L.C.c (faded). Write the report’s table’s four axes and their expected entries. Faded step. Seen task 0.92, unseen object 0.75, unseen phrasing 0.82, unseen clutter 0.68; each with its interval. Completion. The axes’ values are the capstone’s diagnostic; the aggregate is the headline, and the axes are the analysis.

WE-L.C.d (contrastive near-miss). A team tunes the policy during the evaluation and reports 95%. Why it fails: the system is not frozen, and the evaluation’s distribution’s leakage makes the number a training’s metric. The fix: the freeze, per §L.C.3.

Comparative table: the metrics and their bounds.

Design principle P50.3. Design the evaluation before the system; the metrics are the scope’s decisions, and the preconditions are what make the result’s claim valid.

Consolidation checkpoint 3

(a) Three capabilities. You can name the six metrics and their bounds. You can compute the test set’s size from the resolution’s requirement. You can state the three preconditions.

(b) Transfer probe. The capstone’s success rate is 0.92 on 400 episodes and the requirement is 0.90. Does it pass? Answer: the lower bound is 0.898, below 0.90, so the acceptance at the 95% level fails; the point estimate is not the acceptance.

(c) Remediation rule. If you cannot state why the distribution’s statement is a precondition, re-read §L.C.3 before Part D.

Part D — The scope and the risks

§L.D.1 — The in and out lists

The scope’s boundary is stated as two lists, and the lists are the capstone’s contract with itself.

In scope. The seven subsystems’ composition, the four axes’ evaluation, the three objects’ (cube, cup, screwdriver) grasp and place, the clutter’s three configurations, the conditional instruction’s two branches, and the 3.3.4 stack’s four layers.

Out of scope. The dexterous hand (2.3.4), the video world model (3.2.2), the LLM’s fine-tuning (3.1.4’s scope is the VLA, not the LLM), and the multi-arm coordination. The excluded items are the modules the capstone does not exercise, and the exclusion is stated so that the capability matrix’s coverage argument is honest.

The lists’ design is the 4.1.1 §L.A.2’s integration’s property’s implementation: the capstone uses the in-scope modules and states the out-of-scope modules’ exclusion. A capstone that silently omits a module is a demonstration whose coverage is unknown.

§L.D.2 — Scope creep and its signature

Scope creep is the expansion of the in-scope list during the project, and its signature is the evaluation’s metrics’ drift. When a new capability is added — a new object, a new instruction’s form, a new subsystem — the evaluation’s test set’s distribution must expand, and the expansion’s cost is the test set’s size’s increase and the report’s axes’ addition.

The creep’s detection is the metrics’ table’s version’s comparison: the metrics defined at the capstone’s start and the metrics in the report must be the same, and a difference is the creep’s evidence. The creep’s fix is the deferral — the new capability is added to the out-of-scope list for this capstone and to the next iteration’s in-scope list — not the metrics’ amendment.

The creep’s cause is the integration’s nature: each subsystem’s working suggests the next, and the suggestion is the scope’s expansion. The capstone’s discipline is the 3.1.4 §L.A.1’s seven phases’ structure — the scope’s freeze at the pipeline’s Phase 1, the baseline audit’s start — and the phases’ gates are the creep’s guard.

§L.D.3 — The risk register

The capstone’s risk register has the 3.3.4 §L.E.3’s five fields, and its entries are the integration’s risks.

The register’s “scope creep’s” probability is high because the creep is the integration’s default; its mitigation is the metrics’ freeze, and its residual is the deferred items’ list — the next iteration’s in-scope list’s start.

The register’s entries are the 3.3.4 §L.D.3’s certification checklist’s capstone-specific complement, and the register’s acceptance is the capstone’s review’s artefact.

Self-explanation 1. Why is scope creep’s probability high rather than low?

Answer. Because the integration’s nature suggests each subsystem’s next capability, and the suggestion is the default’s expansion; the creep is not an accident but the integration’s gravity, and the discipline is the metrics’ freeze.

Concept check. The metrics’ table has a new row for “the cup’s grasp” that was not in the start’s table. What is the diagnosis and the fix?

Answer. The scope creep; the fix is the deferral of the cup’s grasp to the out-of-scope list and the report’s metrics’ table’s restoration. [displaces M3]

Worked-example ladder.

WE-L.D.a (fully worked). The capstone’s start’s metrics are five; the report’s metrics are seven. Compute the creep’s magnitude and state the deferral’s list.

Solution. The creep is two metrics — the cup’s grasp and the screwdriver’s — and the deferral’s list is those two, which are the next iteration’s in-scope list’s start. The report’s metrics’ table’s restoration is the seven’s replacement by the five’s.

WE-L.D.b (completion). The creep’s metrics are the fourth axis’s two additional objects. Is the creep’s deferral necessary, or is the fourth axis’s expansion within scope? Completion. The fourth axis’s expansion is within the in-scope list if the list’s “three objects” is stated at the start; if the list’s three objects are the cube, cup, and screwdriver, the fourth’s expansion is a creep. The list’s precision is the creep’s guard.

WE-L.D.c (faded). Write the risk register’s entry for the latency’s overrun with its residual. Faded step. The probability is moderate, the consequence is the loop’s missing, the mitigation is the budget’s table, and the residual is the worst-case’s path. Completion. The residual is the path the budget’s table did not exercise — the perception’s worst-case latency under the clutter — and the mitigation’s complement is the perception’s optimization.

WE-L.D.d (contrastive near-miss). A team’s scope expands to include the dexterous hand and the video’s world model, and the evaluation’s report has no axes for them. Why it fails: the expansion’s subsystems are not evaluated, and the capability matrix’s coverage argument is dishonest. The fix: the out-of-scope list’s statement and the deferral’s discipline.

Comparative table: the scope’s lists.

Design principle P50.4. State the scope as two lists and freeze the metrics; the creep is the integration’s gravity, and the freeze is the discipline.

Consolidation checkpoint 4

(a) Three capabilities. You can write the in and out lists. You can diagnose the creep from the metrics’ table’s drift. You can write the risk register’s five entries.

(b) Transfer probe. The scope’s in list has “three objects” and the report’s evaluation has five. Which is the creep’s evidence? Answer: the metrics’ table’s drift; the two additional objects are the creep, and their deferral is the next iteration’s in-scope list.

(c) Remediation rule. If you cannot state why the creep’s probability is high, re-read §L.D.2 before Part E.

Part E — The running case

§L.E.1 — The capstone’s definition

The running case’s capstone, frozen.

The task. The arm must pick the cube from the table with three distractor objects (a cup, a screwdriver, and a sponge) and place it in the bin, satisfying the conditional: if the divider blocks the direct path, the placement is in the second bin. The instruction is natural language; the perception is the eye-in-hand camera; the safety is the 3.3.4 stack.

The subsystems. The seven of §L.B.1, with the primary modules and the interface contracts.

The evaluation. The six metrics of §L.C.1, the four axes of §L.C.2, and the 400-episode test set with the 3-point resolution.

The safety. The 3.3.4 stack’s four layers, with the running case’s thresholds: the 20 N force limit, the 5 N grip, the 2.2.4 Q-shield’s 10th percentile, and the 3.3.4 §L.C.3’s safe state.

The transfer. The 3.4.4 adaptation’s two-stage mapping and the 3.4.1 twin-track’s tail.

The definition is the capstone’s contract with its evaluation, and the contract’s freeze is the 3.1.4 §L.A.1’s Phase 1’s baseline audit’s start.

§L.E.2 — The success criteria

The capstone’s acceptance is the 4.1.1 §L.A.2’s three properties’ conjunction with the metrics’ bounds.

Integration. The seven subsystems’ contracts pass, the capability matrix’s coverage argument is complete, and the end-to-end’s test set’s success rate’s lower bound is at or above 0.90.

Evaluation. The four axes’ reports are present with their intervals; the placement error’s 95th percentile is at or below 2 cm; the peak force is at or below 20 N; the safety violations are zero.

Failure analysis. The failure taxonomy’s entries were observed, the risk register’s five entries have residuals, and the 3.3.4 §L.E.3’s register’s capstone-specific entries are present.

The conjunction is the capstone’s acceptance, and each criterion is necessary. A capstone that passes the metrics and fails the failure analysis is a demonstration; one that passes the failure analysis and fails the metrics is an analysis.

§L.E.3 — The artefacts

The capstone’s report’s artefacts are the evidence.

The capability matrix with the coverage argument’s statement.

The interface contracts’ table with the six contracts’ four fields.

The evaluation’s report with the metrics’ table, the four axes’ rows, and the intervals.

The failure taxonomy with the observed entries.

The risk register with the five entries and the residuals.

The system’s code with the 3.3.2 §L.E.3’s acceptance criteria’s tests.

The artefacts’ completeness is the report’s acceptance, and the 4.4.1 lesson’s “architecting the defense” uses the artefacts as the defense’s evidence.

Self-explanation 2. Why is the failure taxonomy an artefact rather than a section of the report’s prose?

Answer. Because the taxonomy’s entries are the observed failures, and their evidence is the trace’s or the log’s; the artefact’s form is the entries’ structured record, and the prose’s narrative is the analysis’s complement, not the evidence.

Worked-example ladder.

WE-L.E.a (fully worked). The capstone’s test set’s success rate is 0.91 on 400 episodes, and the lower bound is $0.91 - 1.645 \times \sqrt{0.91 \times 0.09/400} = 0.887$. The requirement is 0.90. State the acceptance’s result.

Solution. The lower bound is below 0.90, so the metrics’ criterion fails. The capstone’s acceptance’s conjunction fails, and the report’s evidence is the near-miss with the test set’s expansion’s plan. The 3.1.4 §L.D.3’s decision conjunction’s structure applies: the necessary condition’s failure is the acceptance’s failure.

WE-L.E.b (completion). The test set is expanded to 900 episodes and the success is 0.91. Compute the lower bound and state the acceptance. Completion. $\text{SE} = 0.0095$, the lower bound is $0.91 - 0.0156 = 0.894$, still below 0.90. The expansion did not fix the near-miss, and the policy’s improvement or the requirement’s revision is the next step.

WE-L.E.c (faded). Write the report’s failure taxonomy’s first entry with its trace’s evidence. Faded step. Failure: the grasp’s slip during the transport’s acceleration; the trace’s evidence is the momentum observer’s residual’s step and the postcondition’s failure. Completion. The entry’s cause is the friction’s underestimation at the rotated grasp, and the fix is the 2.3.3 §L.E.2’s adaptive grip’s force.

WE-L.E.d (contrastive near-miss). A capstone’s report has the metrics and the failure analysis’s prose and no taxonomy’s artefact. The review rejects it. Why it fails: the taxonomy’s evidence is the trace’s structured record, and the prose’s narrative is not the evidence. The fix: the artefact, per §L.E.3.

Comparative table: the capstone’s acceptance.

Design principle P50.5. Freeze the definition, evaluate the conjunction, and report the artefacts; the capstone’s mastery is the evidence’s completeness, not the headline’s number.

Consolidation checkpoint 5

(a) Three capabilities. You can state the running case’s capstone definition. You can apply the success criteria’s conjunction. You can name the six artefacts.

(b) Transfer probe. The capstone’s success rate is 0.93 and its failure taxonomy has two observed entries and three hypothesized. Is the failure analysis criterion met? Answer: no; the taxonomy’s entries must be observed, and the hypothesized entries are the analysis’s gap.

(c) Remediation rule. If you cannot state why the artefacts are the evidence, re-read §L.E.3 before the lab.

Failure taxonomy

The table covers the three lab corruptions plus three failures not exercised in the lab: the interaction, the safety’s blind spot, and the evaluation’s drift.

The lab

Task. Write the capstone’s definition’s artefacts: the capability matrix, the six interface contracts, the metrics’ table, the in and out lists, and the risk register. Then run a paper evaluation that predicts the end-to-end’s metrics from the subsystems’ lab results and states the acceptance’s expected result.

Conditions. Python 3.10+ for the artefacts’ generation; no system is built. The subsystems’ lab results are the curriculum’s prior lessons’ metrics. Seed all RNGs.

Controls. (i) The full artefact set; (ii) the artefacts with the interface contracts omitted; (iii) the artefacts with the metrics’ freeze’s version’s comparison; (iv) the paper evaluation’s prediction against the 3.4.1 §L.E’s tail.

Metrics.

Pre-registered hypotheses.

H1. The full artefact set’s coverage is complete, because the matrix’s rows and columns are the curriculum’s modules and the capstone’s subsystems.

H2. The contracts’ omission produces at least one predicted interface’s failure in the paper evaluation, because the contracts’ checks are the failure’s guards.

H3. The metrics’ freeze’s version’s comparison detects a deliberate creep’s injection, because the table’s rows’ difference is the creep’s evidence.

H4. The paper evaluation’s prediction is within 20% of the 3.4.1 §L.E’s tail, because the prediction’s arithmetic is the 3.4.1 §L.B.3’s decomposition’s.

Break-it sequence.

1. Inject the creep silently. Add a metric to the report’s table and check the version’s comparison. Silent: the metric looks reasonable.
2. Remove a contract’s field silently. The contract test’s omission hides the interface’s failure. Silent: the interface works in the nominal case.
3. Freeze the system’s after the metrics’ table’s expansion silently. The evaluation’s distribution’s leakage is hidden. Silent: the metrics’ table looks current.

Acceptance criteria.

What good looks like. A good artefact has five properties. (1) The matrix’s coverage argument is a paragraph, not a table’s assertion. (2) The contracts’ four fields are each a sentence with a test’s reference. (3) The metrics’ table has the version’s timestamp and the freeze’s record. (4) The risk register’s residuals are the deferral’s list’s complement. (5) The paper evaluation’s arithmetic is the 3.4.1 §L.B.3’s decomposition’s.

A runnable core of the paper evaluation’s arithmetic, seeded and annotated:

# lab_4_1_1.py — paper evaluation of the capstone's metrics
import numpy as np
np.random.seed(0)

# Subsystems' lab results (from prior lessons)
PERCEPTION_POSE_ERROR_CM = 0.8      # 2.1.2's held-out error
GRASP_SUCCESS = 0.95                 # 2.3.1's
PLAN_SUCCESS = 0.97                  # 2.3.2's under the clutter
CONTROL_TRACKING_CM = 0.3            # 1.1.3's
SAFETY_VIOLATIONS = 0.0              # 3.3.4's

# The composition's success estimate (independence's approximation)
$p_success$ = GRASP_SUCCESS * PLAN_SUCCESS
print(f"predicted success = {p_success:.3f}")

# Placement error's tail (the errors' convolution's approximation)
placement_tail_cm = np.percentile(
    np.abs(np.random.normal(0, PERCEPTION_POSE_ERROR_CM + CONTROL_TRACKING_CM, 400)),
    95
)
print(f"placement tail = {placement_tail_cm:.2f} cm  (bound 2.0)")

# Test set's size from the resolution's requirement
p, half = 0.90, 0.03
n = int(np.ceil(1.96**2 * p * (1-p) / half**2))
print(f"test set's size for 3-point half-width: {n}")

# The acceptance's lower bound at the predicted success
se = np.$sqrt(p_success$ * ($1-p_success$) / n)
lower = $p_success$ - 1.645 * se
print(f"predicted lower bound = {lower:.3f}  (requirement 0.90)")

# The paper evaluation's risk register's entries
risks = [
    ("integration's interface", 0.3, "halt", "contract tests", "untested interfaces"),
    ("distribution's gap",      0.3, "claim's invalidity", "stratification", "unseen configs"),
    ("safety's violation",      0.1, "blocker", "3.3.4 stack", "blind spots"),
    ("latency's overrun",       0.3, "loop's missing", "budget's table", "worst-case path"),
    ("scope creep",             0.8, "evaluation's drift", "metrics' freeze", "deferred items"),
]
for name, prob, cons, mit, resid in risks:
    print(f"  {name:26s} p={prob:.1f}  mitigation={mit}")

Line 5 is the subsystems’ lab results; line 11 is the composition’s success’s independence’s approximation, which is the paper evaluation’s central assumption. Line 14 is the placement’s tail’s approximation, and line 18 is the test set’s size’s arithmetic of Eq. (C.1). Lines 25–30 are the risk register’s entries.

Cheat sheet

Exercises with solutions

E 4.1.1.1. State the three properties a capstone must have and the test of each.

S 4.1.1.1. Integration (five modules with explicit interfaces), evaluation (held-out with pre-defined metrics), failure analysis (observed taxonomy). The lesson: the three are the acceptance’s structure, and a capstone that lacks one is a demonstration or an analysis, not a synthesis.

E 4.1.1.2 (transfer). A capstone uses eight modules but has no interface contracts. Which property fails, and what is the consequence?

S 4.1.1.2. The integration’s property fails on its interfaces’ explicitness; the composition’s failures are at the untested boundaries, and the success rate’s prediction is unreliable. The lesson: the modules’ count is necessary and the interfaces’ contracts are sufficient.

E 4.1.1.3. Write the perception-to-scene-understanding contract’s four fields.

S 4.1.1.3. Producer: 2.1.2 estimator. Consumer: 3.3.1 verifier. Data’s form: pose with covariance and freshness. Failure mode: stale pose. The lesson: the failure mode is the contract’s purpose.

E 4.1.1.4 (diagnostic). A capstone’s test set is 400 episodes and its success rate is 0.93, and it claims “general competence”. Which precondition fails?

S 4.1.1.4. The distribution’s statement; “general competence” is a claim about a distribution the test did not sample. The claim’s scope must be the test’s, per 3.3.4 §L.D.3. The lesson: the claim’s scope is the test’s distribution’s.

E 4.1.1.5. Compute the test set’s size for a 0.90 success rate and a 2-point half-width at 95% confidence.

S 4.1.1.5. $n = 1.96^2 \times 0.9 \times 0.1 / 0.02^2 = 864.36$, so 865 episodes. The lesson: the resolution’s requirement sets the size, and doubling the resolution quadruples the size.

E 4.1.1.6 (transfer). The metrics’ table has a new row for a new object that was not in the start’s table. Diagnose and state the fix.

S 4.1.1.6. The scope creep; the fix is the deferral to the out-of-scope list and the metrics’ table’s restoration. The lesson: the creep’s evidence is the table’s drift, and the fix is the freeze.

E 4.1.1.7 (diagnostic). The latency budget’s total is 106 ms and the period is 100 ms. Which subsystem is the first fix’s target, and why?

S 4.1.1.7. The motion planner’s 50 ms; it is the largest single subsystem’s cost and its reduction has the most headroom. The perception’s 30 ms is the second priority. The lesson: the budget’s fix targets the largest cost, and the ranking is by the clock.

E 4.1.1.8. Write the risk register’s entry for the scope creep with all five fields.

S 4.1.1.8. Failure: the metrics’ drift. Probability: high. Consequence: the evaluation’s claim’s invalidity. Mitigation: the metrics’ freeze. Residual: the deferred items. The lesson: the creep’s residual is the next iteration’s in-scope list’s start.

E 4.1.1.9 (transfer). The capstone’s success is 0.92 on 400 episodes and the failure taxonomy has three observed entries. Does it pass the acceptance?

S 4.1.1.9. The metrics’ lower bound is $0.92 - 0.027 = 0.893$, below 0.90, so the metrics’ criterion fails; the failure analysis’s criterion passes with three observed entries. The conjunction fails. The lesson: the acceptance is the conjunction, and one failed necessary condition is sufficient.

Exit test

You are ready for Lesson 4.1.2 when you can, without notes:

1. State the three properties and the test of each.
2. Write the capability matrix and the coverage argument.
3. Name the seven subsystems and their primary modules.
4. Write an interface contract’s four fields.
5. Compute the latency budget and rank the subsystems by cost.
6. State the three test layers and their frequencies.
7. Name the six metrics and their bounds.
8. Compute the test set’s size from the resolution’s requirement.
9. State the four axes and the three preconditions.
10. Write the in and out lists.
11. Diagnose the scope creep from the metrics’ table’s drift.
12. Write the risk register’s five entries with residuals.
13. Freeze the running case’s capstone definition.
14. Apply the acceptance’s conjunction to a result set.
15. Name the six artefacts and state why each is evidence.

Cross-references. 1.1.4 supplies the pipeline and its health checks restated in §L.B.2. 2.1.2 supplies the pose estimator restated in §L.B.1. 2.3.1 supplies the grasp quality restated in §L.B.1. 3.1.4 supplies the decision conjunction and the freeze restated in §L.C.3 and §L.E.1. 3.2.3 supplies the planner and its horizon restated in §L.B.3. 3.3.4 supplies the stack and the register restated in §L.D.3. 3.4.4 supplies the adaptation loop restated in §L.B.1. Lesson 4.1.2 chooses the embodiment and the held-out suite against this definition. Lesson 4.1.3 designs the test suite’s stratification.

Ready. The next lesson to write is 4.1.2 — Choosing the Embodiment and the Evaluation. Say “next” to generate it. Phase 4 is the curriculum’s final phase; its lessons are marked proposed in the index, and this lesson’s definition is the contract they extend.