Defend the decision and document the work

2459. Lesson identity

Module

5.16 — Capstone

Lesson

Defend the decision and document the work

Academic type

Integration

Schema type

practical

Order

3 of the module

Estimated time

45–60 minutes, including evidence review, decision defense, documentation, and retrospective planning

2460. Learning objective

After this lesson, you can present the capstone outcome, justify accepted and rejected AI changes with evidence, identify remaining risks and regressions, and define a concrete next direction.

2461. Why this matters

A finished build does not reveal how decisions were made or whether its limitations are understood. A defensible capstone makes the reasoning visible: what changed, what was refused, what evidence supports acceptance, and what remains uncertain. This record also prevents a successful test path from hiding regression risk or unfinished work. The goal is not to make the result sound perfect; it is to make the decision inspectable.

2462. Prior knowledge

You should have completed L1 — Scope and brief the capstone and L2 — Direct, review, and validate the implementation in 5.16 — Capstone. You should have an approved brief, acceptance criteria, implementation notes, a reviewed diff or checkpoint, technical validation results, play-validation evidence, and a list of known limitations or unresolved questions.

2463. Core concept

The core concept is evidence-based defense. Defending a capstone decision means connecting each claim to an observable source and stating the boundary of the claim. The capstone requires evidence of an actual AI-assisted implementation change that the learner evaluated and corrected, narrowed, rejected, or deferred. If that evidence is absent, the final status must be correction required. A fallback AI review alternative may provide supplemental evidence of judgment or prepare the missing remediation, but it cannot satisfy the implementation-change requirement, replace project-history or validation evidence, or be presented as project work.

A useful defense answers five questions:

1. What decision was made? State whether the criterion is accepted, requires correction, or requires scope review.
2. What evidence supports it? Point to the brief, history, diff review, technical checks, and player-facing validation.
3. What was refused? Name AI suggestions or implementation changes that were rejected and explain the boundary, risk, or lack of evidence behind the refusal.
4. What could still fail? Identify remaining risks, regression possibilities, assumptions, and untested conditions.
5. What happens next? Select a specific follow-up action rather than describing an indefinite intention to improve.

A refusal is not a failure of AI collaboration. It is evidence that the learner can evaluate proposed work against scope, behavior, maintainability, and risk.

2464. Mental model

Use the CLAIM model to structure the defense:

A claim without a link is an opinion. A list of risks without a next action is an inventory, not a retrospective.

2465. Concrete example

Imagine that an AI tool proposes adding a broader interaction system while implementing one approved capstone criterion. The broader system might appear useful, but it changes unrelated behavior and has no acceptance test in the brief. You accept the bounded interaction change, reject the broader system, and document the decision this way:

• Claim: Criterion C-02 is accepted for the tested interaction path.
• Link: The reviewed checkpoint contains only the required files; the technical check passes; the success, failure, and restart paths were exercised and recorded.
• Alternative refused: The broader interaction system was rejected because it exceeded the approved scope and introduced unvalidated behavior.
• Issue: The interaction has not been tested under a missing-reference condition.
• Move forward: Add a bounded missing-reference test before expanding the interaction system.

Notice the boundary: the evidence supports the tested criterion, not a claim that every related condition is safe.

2466. AI-native workflow

Use AI to organize and challenge your reasoning, not to manufacture evidence or make the final decision.

1. Assemble your own evidence map before asking for assistance. List each acceptance criterion, its status, and the evidence that supports it.
2. Ask AI to compare your decision log with the approved brief and identify unsupported claims, omitted risks, or unexplained rejected changes.
3. Verify every suggestion against the actual brief, diff, history, technical results, and play record. Remove suggestions that rely on assumptions not supported by the project.
4. Ask AI to help compress the verified record into a clear presentation. Do not let it change a result, erase a failure, or describe an untested path as validated.
5. Write the final decision in your own words and retain the evidence references that make it reviewable.

A suitable review request is:

Compare this decision log with the approved capstone criteria. Identify claims without evidence, rejected changes without reasons, missing regression checks, and risks that need a next action. Do not infer test results or rewrite the decision.

2467. Common mistake

The common mistake is presenting only the successful outcome and treating rejected ideas, failed checks, and untested conditions as irrelevant. That produces a polished summary but hides the information a reviewer needs to judge risk. Another mistake is listing every possible future improvement without prioritizing one next action. A defensible record distinguishes verified behavior from assumption, limitation, and future work.

2468. Guided practice

Create and present a capstone decision record using the evidence from the previous lesson.

1. Build the evidence map — 10 minutes

For each approved criterion, record:

• the exact criterion and current status;
• the relevant implementation checkpoint or history identifier;
• the files and sections reviewed;
• technical checks and their results;
• player actions, starting state, expected result, and observed result;
• any evidence gap or warning.

Do not combine separate criteria into one unsupported overall claim.

2. Complete the decision log — 10 minutes

List at least two implementation decisions from the capstone work. For each one, classify it as accepted, rejected, or deferred, then explain:

• the option considered;
• the evidence available;
• the scope, behavior, maintenance, or regression tradeoff;
• the resulting decision;
• how the accepted outcome supports the approved player-facing or creative intent;
• how the rejected or deferred option would affect that intent, and what evidence supports that judgment.

You may mark the creative-intent analysis not applicable only when the approved contribution has no creative consequence. State why it has none rather than omitting the analysis.

At least one entry must document an actual AI-generated or AI-proposed capstone implementation change that you corrected, narrowed, rejected, or deferred. Include the original proposal or a faithful summary of it, the action you took, and the evidence or constraint that led to your decision. Do not describe a human-only change as an AI incident. The fallback review alternative cannot satisfy this requirement by itself because it does not replace an actual AI-assisted capstone change.

If no natural AI-generated or AI-proposed implementation change exists in your capstone record, the capstone status must be correction required until you complete and document the required actual AI-assisted change. You may also use this bounded review alternative as supplemental evidence of judgment or preparation for remediation: ask AI to propose one narrowly scoped change to the implemented criterion or its validation plan, without editing the project. Record the proposal, review it against the approved brief and evidence, and then correct, narrow, reject, or defer it. Label the entry explicitly as AI review alternative — supplemental only; no natural project proposal. It does not satisfy the implementation-change requirement, count as implementation evidence, or establish that the proposal occurred in project history.

3. Write the risk and regression review — 10 minutes

Identify remaining risks under separate headings:

• Known limitation: behavior that does not satisfy the intended target or remains incomplete;
• Regression risk: existing behavior that could be affected by the change;
• Evidence gap: a condition that has not been tested or inspected sufficiently;
• Assumption: a dependency or context believed to be true but not yet verified.

For each item, state its impact, likelihood in practical terms, and the condition or test that would reduce uncertainty. Do not turn this list into unsupported predictions about the project.

4. Deliver the defense — 10–15 minutes

Present the result in five parts using the CLAIM model:

1. the decision and its boundary;
2. the evidence chain;
3. accepted, rejected, and deferred changes;
4. remaining risks and evidence gaps;
5. one prioritized next action.

The presentation may be spoken, written, or recorded according to the project workflow. It must allow another reviewer to follow each claim back to evidence. Provide captions or a transcript for a recorded defense, text alternatives for visual evidence, descriptive labels for links, and a structured text version of the evidence map.

5. Make the required judgment — 5 minutes

Choose one final status for the capstone criterion or defined capstone scope:

• Accepted: the evidence satisfies the approved criteria and known gaps are within the stated boundary;
• Correction required: a bounded change can address the failed or incomplete evidence;
• Scope review required: the brief, assumptions, or requested outcome must be reconsidered before more implementation.

Justify the choice. Do not select acceptance merely because the primary path works.

2469. Validation / evidence

Submit a decision record containing:

• the approved scope and the final decision;
• an evidence map linking each claim to the brief, checkpoint or history, diff review, technical checks, and play validation;
• at least one documented actual AI-generated or AI-proposed implementation change that was corrected, narrowed, rejected, or deferred, including the proposal, the learner's response, and the reason for that response;
• if that required actual change is absent, the final status correction required and, if used, a separately labeled AI review alternative — supplemental only; no natural project proposal that supports judgment or remediation preparation without being counted as implementation evidence;
• accepted, rejected, and deferred AI-assisted changes with a reason for each decision;
• an explanation of how the accepted outcome supports the approved player-facing or creative intent and how rejected or deferred proposals would affect that intent, with supporting evidence; a justified not applicable is permitted only when the approved contribution has no creative consequence;
• a clear distinction between verified behavior, limitation, risk, evidence gap, and assumption;
• regression checks performed and any checks still required;
• one prioritized next action with a condition for completion;
• the final status: accepted, correction required, or scope review required.

For the judgment criterion in the Stage 5 rubric, the evidence must make the learner's judgment inspectable: it must show how the learner evaluated an actual AI-assisted implementation change against scope, evidence, behavior, maintainability, regression risk, and the approved player-facing or creative intent, rather than merely reporting that the build works. If evidence of that actual change is absent, the result is correction required; a review alternative remains supplemental and cannot earn completion of the implementation requirement. Another reviewer must be able to determine not only what was built, but why it was accepted, corrected, narrowed, rejected, or deferred, how those decisions support or affect the approved intent, what remains uncertain, and what should happen next. Unsupported claims must be marked as evidence gaps rather than presented as facts.

2470. Key takeaways

• Defend claims with traceable evidence, not with confidence or AI-generated explanations.
• A justified refusal or deferral is a valid demonstration of technical judgment.
• Separate verified behavior from limitations, regression risks, evidence gaps, and assumptions.
• A retrospective is useful only when it prioritizes a concrete next action.
• Acceptance is a bounded decision; it does not imply that every related condition has been validated.

2471. Knowledge check

2472. Next lesson

This is the last lesson in Stage 5. Your final submission must include the project record, evidence map, and an explicit defense of the technical and creative direction. Submit the final decision, limitations, and prioritized next action for course completion review and handoff; there is no subsequent lesson in this stage.

Next: course completion review and handoff.

2473. Knowledge check