1984. Lesson identity
1985. Learning objective
After this lesson, you can rewrite an ambiguous game-feature request as a bounded system brief that names boundaries, ownership, invariants, inputs, outputs, and non-goals.
1986. Why this matters
AI can produce a large amount of implementation quickly, but speed does not make an unclear design safe. If a feature has no clear boundary, an AI-assisted change may alter unrelated systems, duplicate authority, or satisfy the wording while violating the game’s intended behavior. A bounded brief gives both the developer and the AI something inspectable to reason about. It also makes review more precise: you can ask whether the change respects the stated contract instead of judging a large patch by appearance.
1987. Prior knowledge
Canonical entry capability: You can describe a game feature in terms of its intended behavior, relevant state, rules, and observable feedback, and distinguish that feature request from its implementation.
You also need the course prerequisites and a working vocabulary for game systems, features, state, rules, and feedback. No specific project file or engine setup is required for this lesson.
1988. Core concept
A system is safer and more inspectable to change when its responsibilities and limits are explicit. A bounded brief is a design prerequisite, not proof that a repository or implementation task is ready for AI-assisted change; the next lesson evaluates repository context, dependency visibility, validation mechanisms, and execution constraints.
A useful system brief defines five things:
- Boundary: What behavior belongs inside this system, and what behavior remains outside it?
- Ownership: Which component is authoritative for each piece of state or decision?
- Invariants: What must always remain true, regardless of implementation details?
- Inputs and outputs: What information enters the system, and what observable results leave it?
- Non-goals: What the system deliberately does not solve in this iteration?
Responsibility describes the function a component performs; authority identifies which component may validly establish or change a state or decision. They are not the same. In this brief, ownership identifies that authority.\n\nThe goal is not to predict every implementation detail. The goal is to constrain the decisions that an implementation may safely make.
1989. Mental model
Use the BOINS brief before asking an AI to implement or revise a system:
| Part | Question | Example answer |
|---|---|---|
| B — Boundary | What does this system control? | Calculates whether a guard becomes suspicious. |
| O — Ownership | Who is authoritative? | The suspicion system owns suspicion value; the UI only displays it. |
| I — Invariants | What must always be true? | Suspicion stays between 0 and 100. |
| N — Named inputs and outputs | What crosses the boundary? | Inputs: observed event and context. Output: updated suspicion state and notification. |
| S — Scope exclusions | What is explicitly not included? | It does not choose guard animations or spawn reinforcements. |
A brief is strong when another developer can identify an acceptable change and an unacceptable change without guessing your intent.
1990. Concrete example
Ambiguous request:
“Make guards react better when the player is seen.”
This request mixes detection, reaction, presentation, and possibly encounter difficulty. An AI could reasonably implement a detection timer, a UI alert, a new animation, a pursuit state, or all of them.
A bounded version is more useful:
System: Guard suspicion evaluation.
Boundary: Convert confirmed observation events into a suspicion value and a suspicion-level change event.
Owner: This system owns the suspicion value for one guard. The perception system owns whether an observation event is valid. The presentation layer owns icons, text, and animation.
Inputs: Guard identifier, observation event, event strength, and elapsed time for decay.
Outputs: Suspicion value in the range 0–100; a change event when the value crosses a configured threshold.
Invariants: Suspicion never leaves the 0–100 range; presentation code cannot directly set suspicion; an invalid or missing observation event does not increase suspicion.
Non-goals: No new animations, pursuit behavior, reinforcement spawning, level redesign, or difficulty rebalance.
Acceptance evidence: A test or inspection can show that valid observations increase suspicion, decay reduces it according to the defined rule, threshold crossings emit one corresponding event, and the UI cannot become the authority for the value.
The bounded brief does not dictate class names or a particular engine API. It does constrain the behavior and the ownership relationships that matter.
1991. AI-native workflow
Use AI as a specification critic before using it as an implementation partner:
- Write the first version of the brief yourself.
- Ask the AI to list ambiguities, missing owners, conflicting responsibilities, and possible scope expansion. Ask it to quote the exact sentence that created each concern.
- Revise the brief by deciding which concerns matter for this iteration. Do not accept every suggestion automatically.
- Ask the AI to propose acceptance checks derived only from the final boundary, invariants, inputs, outputs, and non-goals.
- Compare the proposed checks against your brief. Remove any check that introduces an unapproved feature.
The human decision remains the system boundary. AI may expose ambiguity, but it does not decide the product scope for you.
1992. Common mistake
The most common mistake is treating a feature name as a system boundary. “Guard reactions” or “inventory improvements” describes a desired result, not ownership or scope. Responsibility and authority must not be treated as synonyms: a component may display or process information without being authorized to establish its state. Another mistake is writing non-goals as vague statements such as “keep it simple.” A useful non-goal names a tempting responsibility that this system will not take, such as “does not modify animation state.”
1993. Guided practice
Rewrite this request as a BOINS system brief:
“Add a stamina system so movement feels more tactical.”
Complete this compact BOINS worksheet:\n\n- Boundary:\n- Authoritative owner:\n- Invariants:\n- Inputs:\n- Outputs:\n- Non-goals:\n- Acceptance evidence:\n- Safe change: Name one proposed change permitted by the contract and cite the BOINS element that permits it.\n- Refused change: Name one tempting change outside the contract and cite the BOINS element that requires its refusal.\n\nUse the following constraints:
- The brief must define one authoritative owner for stamina.
- It must distinguish stamina rules from movement presentation.
- It must include at least two invariants.
- It must state what happens when stamina is insufficient for an attempted action.
- It must name at least three non-goals.
Then perform one boundary decision: choose whether stamina belongs to the movement system or to a separate resource system. State the choice and give one reason based on ownership and change safety.
1994. Validation / evidence
Your evidence is a completed one-page system brief. It must contain:
- A named boundary that excludes at least one neighboring responsibility.
- An explicit owner for the authoritative state.
- At least two testable invariants.
- Clearly named inputs and outputs.
- At least three concrete non-goals.
- A decision about where the system belongs and why.\n- One proposed safe change permitted by the contract, justified by a specific BOINS element.\n- One tempting change that must be refused as out of scope, justified by a specific BOINS element.
A peer or future AI collaborator should be able to identify one safe change and one out-of-scope change from the brief without asking what you meant.
1995. Key takeaways
- AI-assisted implementation is safer when the design contract is inspectable before code is changed.
- Boundaries prevent a system from absorbing unrelated responsibilities.
- Ownership identifies the authoritative source of state and decisions.
- Invariants turn design intent into conditions that can be checked.
- Non-goals protect the iteration from silent scope expansion.
1996. Next lesson
Continue to 5.1 L2 — Evaluate AI-readiness before implementation.
1997. Knowledge check
Answer these items for yourself before reading the answers.
Which statement best defines a system boundary?
Show answer and feedback
Answer: The behavior the system controls and the neighboring behavior it excludes
Why: A boundary states what the system controls and what remains outside it. A feature name, implementation detail, or visual effect does not define that responsibility by itself.
Which is an invariant for a suspicion system?
Show answer and feedback
Answer: The suspicion value remains between 0 and 100
Why: An invariant is a condition that must remain true regardless of implementation. Keeping the value within its defined range is directly testable.
What is the best use of AI before implementation begins?
Show answer and feedback
Answer: Ask it to expose ambiguities and derive checks from the brief
Why: AI is useful as a specification critic: it can identify ambiguity and suggest checks. The developer remains responsible for deciding scope and accepting changes.
Why should a system brief include non-goals?
Show answer and feedback
Answer: To prevent tempting neighboring responsibilities from expanding the iteration
Why: Non-goals make scope explicit. They prevent the system, the developer, or the AI from silently absorbing related but unapproved responsibilities.