Scope and brief the capstone

2429. Lesson identity

Module

5.16 — Capstone

Lesson

1 — Scope and brief the capstone

Academic type

Integration

Schema type

Practical

Order

1 of 3 in this module

Sequence

Follows 5.15 L2 — Direct coherent tradeoffs; hands off to 5.16 L2 — Direct, review, and validate the implementation

Estimated time

45–60 minutes, including practice

2430. Learning objective

After this lesson, you can submit a capstone brief that states the player-facing goal, bounded scope, ownership, constraints, AI workflow, validation evidence, and definition of done.

2431. Why this matters

A capstone is not a collection of ambitious features. It is a claim about what you will build, why it matters, and how another person can determine whether it works. A precise brief lets you make tradeoffs without losing the project’s central promise. It also gives AI a bounded context for assistance instead of inviting it to expand the project indefinitely. Your brief becomes the reference point for implementation, review, and final evidence.

2432. Prior knowledge

You should already be able to:

• state a player promise and direct coherent tradeoffs from 5.15 L2 — Direct coherent tradeoffs;
• distinguish player-facing goals from implementation details;
• separate creative intent from technical constraints;
• use AI as a directed collaborator and evaluate its output rather than accepting it automatically;
• describe a validation method that produces observable evidence.

This lesson converts those decisions into the controlling contract for the capstone build and review process.

2433. Core concept

A capstone brief is a contract for a reviewable result. It turns intention into boundaries. The contract must answer seven questions:

1. What is the player meant to experience or accomplish?
2. What is included, and what is explicitly excluded?
3. Who owns each meaningful decision or deliverable?
4. What technical, creative, time, or tool constraints apply?
5. How may AI contribute, and what remains your responsibility?
6. What evidence will prove that the result is done and coherent?
7. What conditions define done, so the result can be accepted?

A goal such as “make a compelling action game” is not reviewable. A bounded statement such as “deliver one playable encounter in which the player uses two readable tools to escape a marked threat, with a complete start-to-result path and recorded validation evidence” is reviewable because it identifies an experience, a boundary, and an observable result.

2434. Mental model

Use the CAPSTONE contract:

A useful brief is specific enough to guide action but small enough to survive contact with implementation. If a section cannot be evaluated, rewrite it as an observable condition or remove it from the contract.

2435. Concrete example

Suppose the meaningful goal is: “Create a tense escape moment that rewards careful observation.”

A weak brief says:

Build a tense escape sequence with good atmosphere, several enemy types, multiple routes, and polished sound.

This brief mixes a goal with unbounded feature growth. It does not establish evidence or a stopping point.

A bounded brief says:

Core promise: The player identifies a visible environmental clue, chooses between two escape routes, and reaches a safe result while under pressure. Included: one playable escape space, one threat pattern, two routes with distinct risks, readable clue presentation, and a clear success and failure result. Excluded: additional enemy types, progression systems, extra spaces, and content beyond this encounter. Evidence: a fresh run recording, a short test log from at least three play attempts, and a checklist showing that both routes, outcomes, and clue readability were tested. Done when: the encounter can be started, completed or failed, restarted, and explained without relying on undocumented assumptions.

The second version still leaves room for creative decisions, but it makes the result inspectable and prevents adjacent ideas from silently becoming requirements.

2436. AI-native workflow

Use AI to clarify and challenge the contract, not to decide the project’s purpose for you.

1. Write the first version of the brief without asking AI to invent the concept.
2. Give AI the brief and ask it to identify ambiguous language, hidden scope, conflicting constraints, missing evidence, and criteria that cannot be tested.
3. Compare each suggestion against the player promise and your available capacity.
4. Accept, reject, or revise suggestions explicitly. Record consequential decisions in the brief.
5. Ask AI to produce a final consistency check: every included feature should support the promise, every definition-of-done item should have evidence, and every ownership item should name a responsible person.
6. Treat the final brief as your decision. AI may expose gaps; it does not own the scope or the acceptance decision.

If AI proposes a feature that is attractive but not necessary to prove the promise, place it in an out of scope or future consideration list rather than allowing it into the capstone by default.

2437. Common mistake

The most common mistake is writing a feature inventory and calling it a brief. A list of mechanics, art assets, and technical tasks does not explain which player experience matters most or how completion will be judged. Another frequent mistake is using vague acceptance language such as “polished,” “fun,” or “professional” without naming observable evidence. Replace those words with conditions a reviewer can inspect, run, compare, or reproduce.

2438. Guided practice

Draft a one-page capstone brief using the CAPSTONE contract. Complete these fields:

1. Core promise: Write one sentence beginning with “The player will…”
2. Meaningful outcome: State what makes this project worth building or reviewing.
3. In scope: List only the smallest set of elements required to deliver the promise.
4. Out of scope: List at least three tempting additions that will not be required for completion.
5. Ownership: Name who owns creative direction, implementation decisions, AI-assisted changes, testing, and final acceptance. If you are working alone, name yourself and distinguish the roles you perform.
6. Constraints: State the target platform or runtime, available time, technical limits, content limits, and any other non-negotiable boundaries.
7. AI workflow: Specify what AI may help with, what you must review, and which decisions cannot be delegated.
8. Evidence: Name the builds, recordings, test notes, screenshots, traces, or other artifacts that will demonstrate the result.
9. Definition of done: Write five to eight binary or inspectable conditions. Avoid “good,” “polished,” or “complete” unless you define how that claim will be verified.

Then perform one scope decision: remove one included item and explain whether the core promise becomes weaker, unchanged, or impossible to validate. Restore the item only if you can defend its necessity.

2439. Independent practice

Give your brief to a peer or to AI with this review prompt:

Find every statement that is ambiguous, unbounded, unowned, unsupported by evidence, or unrelated to the core promise. Do not add features. Return the statement, the risk it creates, and one question that would force a clearer decision.

For each finding, revise the brief or record a reasoned rejection. Finish by producing a compact final version that a collaborator could use without a verbal explanation from you.

2440. Validation / evidence

Your capstone brief is ready for submission when it contains all of the following:

• one player-facing promise rather than a general aspiration;
• a concrete in-scope boundary and at least three explicit exclusions;
• ownership for creative, technical, AI workflow, testing, and acceptance decisions;
• constraints that can affect tradeoffs;
• AI-use rules that preserve human review and decision ownership;
• evidence tied to the intended player result;
• a definition of done made of observable conditions;
• no requirement that depends on an undocumented assumption or an unbounded adjective.

The evidence for this lesson is the submitted brief, its revision notes, and the recorded response to at least one scope challenge. This brief is the handoff artifact for 5.16 L2 — Direct, review, and validate the implementation and the later capstone review work; subsequent work should use it to control additions, tradeoffs, and acceptance.

2441. Key takeaways

• A capstone brief is a contract for a reviewable result, not a feature wishlist.
• Scope is defined by exclusions as well as inclusions.
• Ownership must include decisions, review, testing, and acceptance—not only implementation.
• AI can challenge ambiguity and expose gaps, but you retain responsibility for scope and judgment.
• Definition of done must connect observable conditions to concrete evidence.

2442. Next lesson

Proceed to 5.16 L2 — Direct, review, and validate the implementation. Use the submitted brief, revision notes, and scope-challenge response as the controlling input for implementation decisions. Do not add work that is outside the contract without recording and evaluating an explicit scope change.

2443. Knowledge check