Define technical gates for a small team

2384. Lesson identity

Module

5.14 — Technical direction

Lesson

Define technical gates for a small team

Academic type

Workflow

Lesson type

Mixed

Order

2

Estimated time

40–50 minutes for in-session drafting with a prepared bounded change and packet template; project execution and evaluation may require additional time

This lesson turns a technical decision into a small-team operating agreement: what must be true, how it will be checked, when a problem must be escalated, and how the change can be reviewed or recovered.

2385. Learning objective

After this lesson, you can create a technical direction packet that defines a transition’s definition of done through prioritized gates, observable evidence, escalation thresholds, explicit non-goals, a reviewable checkpoint, and a documented recovery path.

2386. Why this matters

A quality expectation such as “the feature should feel stable” is not yet useful for production. A definition of done makes a transition or milestone inspectable by stating the conditions that must be true before it can proceed. Prioritized gates make that definition usable under time pressure: they distinguish what blocks the transition from what must be addressed later. A reviewable checkpoint and a recovery path make the decision traceable after the change has been evaluated. This is especially important when AI can produce code faster than a small team can review it.

2387. Prior knowledge

You should be able to compare technical options under constraints, identify trade-offs, and record a decision with its assumptions from 5.14 L1 — Make a technical decision under constraint. You should also be familiar with the project’s current scope, its highest-risk systems, the difference between a requirement and an implementation preference, and the project’s normal method for recording changes.

2388. Core concept

A technical gate is a condition that must be satisfied before a defined transition can happen. The packet must also identify the tooling used to inspect the condition and its evidence, such as the issue tracker, test runner, runtime or profiling tools, review interface, and version-control system. A gate is not operationally complete if the team cannot reproduce its check with available tools. The transition might be merging a change, handing a feature to playtesting, advancing a milestone, or preparing a build for release review.

A set of prioritized gates becomes the definition of done for that transition. The definition is not a claim that the entire project is finished. It is a bounded answer to: “What must be true, and what evidence must exist, before this work can cross this boundary?” A transition is done when every blocking gate passes, every required gate is passed or explicitly accepted by the decision owner, and non-blocking items remain visible with an owner and review point.

For a technical change, “done” also requires traceability. The packet must identify a reviewable checkpoint—such as a commit, pull request, tagged revision, or equivalent project snapshot—so the evaluated state is unambiguous. It must record the evaluation performed against that state and describe how to restore the last known-good state or otherwise reverse the change if a gate fails.

A complete Gate Card has six required parts. The packet must also state its non-goals; attach a non-goal to an individual gate only when it clarifies that gate’s specific boundary.

1. Transition: What is authorized if the gate set passes?
2. Priority: How does failure affect this transition? Use P0, P1, or P2.
3. Condition: What must be true?
4. Evidence: What artifact or observation proves it?
5. Owner: Who performs or confirms the check?
6. Failure action: What happens when the condition is not met?
7. Gate-level non-goal, when needed: What related concern is deliberately outside this gate?

The packet adds three traceability fields for the change under review:

8. Checkpoint: Which commit, review, tagged revision, or equivalent snapshot is being evaluated?
9. Evaluation: What meaningful test, inspection, or comparison was run against that checkpoint, and what result did it produce?
10. Recovery path: What known-good checkpoint can be restored, who can perform the rollback or reversal, and what condition triggers it?

“Use clean code” is not a gate because it has no observable threshold. “The feature passes the listed acceptance cases, produces no new console errors in the test scene, and has a named reviewer before milestone handoff” is closer, but it is complete only when the packet also states its priority, owner, failure action, transition, excluded scope, evaluated checkpoint, meaningful evaluation, and recovery path.

Prioritization matters. A small team cannot inspect every possible property at every transition. Start with gates that protect the player-facing contract, prevent expensive rework, or expose a risk that the team cannot safely absorb later. Traceability matters for the same reason: a result without a named state cannot reliably be reproduced, compared, or reversed.

2389. Mental model

Use the Gate Card → Definition of Done → Checkpoint model:

Assemble the cards into a transition definition of done:

• P0 — blocking: Every P0 gate must pass. The transition cannot proceed otherwise.
• P1 — required: Every P1 gate must pass before the next milestone, or the named decision owner must explicitly accept the risk.
• P2 — recorded improvement: The issue does not block the current transition, but it needs an owner and review point.
• Traceability — reviewable state: The packet identifies the exact checkpoint evaluated, the meaningful evaluation result, and the recovery action for a failed change.

These P0, P1, and P2 meanings are the operating definitions used in this lesson. A team may map them to local priority labels, provided it preserves the same blocking, risk-acceptance, ownership, and review consequences.

The packet’s completion rule should be written in one sentence, for example: “This feature is ready for internal playtest when all P0 gates pass, P1 items have been resolved or explicitly accepted, every P2 item has an owner and review date, and the evaluated checkpoint and recovery path are recorded.” That sentence is the operational definition of done. If every item is P0, the system has no useful prioritization. If no item has a consequence, the document is only a set of recommendations. If the checkpoint or evaluation is missing, the team cannot tell which state passed the gate.

2390. Concrete example

Suppose a small team is preparing a new interaction for internal playtesting. Its transition definition of done could contain these Gate Cards:

The packet also records:

• Checkpoint: the reviewable commit or equivalent snapshot containing the interaction change.
• Evaluation: the three acceptance cases, the target-scene regression check, and their pass/fail results.
• Recovery path: restore the last known-good checkpoint if G-01 or G-02 fails after the change; record the trigger, restored state, and follow-up owner.

The definition of done is therefore: G-01 and G-02 must pass for playtest handoff; G-03 must be resolved or accepted before the next milestone; G-04 must remain owned and scheduled; and the evaluated checkpoint, evaluation result, and recovery path must be recorded. The packet should also name non-goals: no broad refactor of neighboring systems, no new content pass, no support for an uncommitted platform, and no claim of final performance readiness.

2391. AI-native workflow

AI can help draft, classify, and challenge a gate list. It cannot decide whether evidence is trustworthy, whether a failure is acceptable for the project, or which checkpoint should be treated as authoritative. Keep the human decision visible.

1. Frame the context. Give the AI the transition, the player-facing requirement, the known constraints, the previous technical decision, and the intended checkpoint and evaluation method. Do not ask it to infer project facts that are not in the prompt.
2. Request candidates. Ask for candidate gates in the complete Gate Card format, including transition, priority, condition, evidence, owner, failure action, and non-goal. Also ask it to identify the evidence needed to verify the checkpoint, evaluation, and recovery path. Require the AI to label assumptions separately.
3. Challenge the list. Ask which gates are vague, duplicated, impossible to inspect, or incorrectly prioritized. Ask what evidence would falsify each proposed gate and what result should trigger recovery.
4. Review against the project. Remove invented assumptions. Replace generic checks with evidence the team can actually produce. Set priorities based on consequence and timing, not on the AI’s wording. Confirm that the proposed recovery path is feasible before recording it.
5. Record the packet. Keep the final gates, the one-sentence definition of done, non-goals, owners, escalation rules, checkpoint, evaluation result, and recovery path in a human-reviewed document. The final packet is the team’s decision, not an AI-generated authority.

A useful prompt is:

Act as a skeptical technical reviewer. Given this transition, requirement, constraints, known risks, proposed checkpoint, evaluation method, and recovery option, propose no more than six complete Gate Cards. For each one, state the priority, observable condition, evidence, owner, failure action, and non-goal. Identify what must be recorded to make the checkpoint reviewable, the evaluation meaningful, and the recovery path executable. Mark every assumption. Then identify vague gates, duplicated coverage, and missing non-goals. Do not invent project history or claim that a check has passed.

After the AI responds, inspect one candidate at a time. Ask: “Could a different reviewer reproduce this check from the named checkpoint, and does this card contribute to the transition’s definition of done?” If not, rewrite the gate before accepting it.

2392. Git workflow

Use the project’s normal Git version-control process to make the technical change reviewable and recoverable. Do not treat an untraceable working directory as sufficient evidence. If Git is genuinely unavailable, permit an equivalent only as a documented exception that states the limitation, identifies the exact versioned snapshot and review location, and names the verifier.

1. Identify the last known-good commit, tagged revision, or equivalent checkpoint before the change.
2. Keep the technical change isolated enough that a reviewer can identify what was evaluated. Create a reviewable commit, pull request, tagged revision, or equivalent checkpoint according to the project’s process.
3. Record the checkpoint identifier in the technical direction packet before evaluation. Git is required by the syllabus; if it is genuinely unavailable, record the justified exception, equivalent snapshot identifier, exact location, limitation, and verifier instead.
4. Run one meaningful evaluation against that exact checkpoint. The evaluation must exercise the requirement or expose the highest-risk regression; a commit existing is not evidence that the feature works.
5. Record the evaluation method, environment or test path when relevant, date or session label if used by the project, and pass/fail result. Do not claim a test passed without performing it.
6. Document recovery before accepting the change: name the known-good checkpoint, the trigger for rollback or reversal, the person or role responsible, and any verification required after recovery.
7. If a blocking gate fails, stop the transition and use the documented recovery path when appropriate. Record whether the change was reverted, corrected in a new checkpoint, or held for an explicit risk decision.

A minimal traceability record is: evaluated checkpoint → meaningful evaluation and result → decision → recovery trigger and known-good checkpoint. The record should let another person determine what state was tested and what to do if the change causes a regression.

2393. Common mistake

The common mistake is treating a list of quality intentions as a definition of done. “We value maintainability,” “the feature should be polished,” and “AI output must be reviewed” are standards or intentions. They become operational only when the packet defines the transition, priority, condition, evidence, owner, failure action, and non-goal.

Another mistake is treating a commit or checkpoint as proof of quality. A reviewable state establishes what can be inspected; it does not establish that the requirement works. A meaningful evaluation must be run against that state, and a recovery path must be documented before the change is accepted.

A further mistake is making every gate blocking. That removes the distinction between a release-critical failure and a recorded improvement. It is also a mistake to hide scope decisions inside quality language or to describe rollback as “fix it later.” If a team does not intend to support a platform, content variant, or performance target in the current transition, state it as a non-goal. If a change can cause a regression, state which known-good state can be restored and what event triggers that action.

2394. Guided practice

Create a technical direction packet for one prepared, bounded feature or system in the current project. Start from an existing change description and use the Gate Card, traceability, review-allocation, and validation headings in this lesson as your packet template. If you do not have a project context available, use a small interaction such as “the player activates an object, receives a state change, and can continue through the intended path.” Name the tools that will produce and inspect the evidence. Draft the packet during the session; if running the meaningful evaluation requires building, profiling, or other project execution, record it as pending and complete it afterward before scoring the packet as complete.

Allocate review effort with this method: identify the gates with the highest failure consequences, increase review time for risks that are difficult to detect or reverse, assign each review activity to an owner or role, and justify the amounts from those consequences. Use time or percentages for gate drafting, evidence verification, risk review, and recovery review. For example: 20% gate drafting — implementer; 40% evidence verification — reviewer, because the two P0 interaction gates protect the playtest handoff; 25% risk review — technical owner, because state loss is difficult to detect later; 15% recovery review — implementer and reviewer, because the isolated checkpoint makes reversal comparatively simple. The amounts must total 100% or the stated review-time budget.

Complete these steps:

1. Name the transition your packet controls: code review, internal playtest, milestone handoff, or another concrete boundary.
2. State the player-facing requirement in one sentence.
3. List the three highest-consequence risks. Separate player-facing failure, technical failure, and scope failure where possible.
4. Identify the last known-good state and create or designate a reviewable checkpoint for the technical change: a commit, pull request, tagged revision, or equivalent snapshot.
5. Draft four to six complete Gate Cards. Include at least one P0, one P1, and one P2 gate unless the context gives a documented reason not to.
6. For every gate, write evidence that another person can inspect without relying on your memory.
7. Define one meaningful evaluation for the checkpoint. It must exercise the player-facing requirement or the highest-risk technical behavior. Record the method and result; do not mark it as passed until you have run it.
8. Write the one-sentence definition of done for the transition. State what must pass, what requires explicit risk acceptance, and how P2 work remains visible.
9. Define one escalation rule. For example: a P0 failure blocks the transition immediately; a P1 failure requires a named decision owner to accept the risk before the milestone review; a P2 issue needs an owner and point of review.
10. Document the recovery path. Name the known-good checkpoint, the condition that triggers rollback or reversal, who performs it, and how recovery will be verified.
11. Write at least three non-goals. Make them specific enough to prevent a likely scope expansion.
12. Ask an AI tool to challenge the packet using the prompt above. Compare its suggestions with the actual project context, retain only justified changes, and mark any unresolved assumption.

The required decisions are your priority ordering and recovery trigger. If two gates compete for limited time, choose which one is checked first and explain the consequence your ordering protects. Then decide what evidence would justify keeping the change, correcting it in a new checkpoint, or restoring the known-good state.

2395. Validation / evidence

Your packet is complete when it contains:

• One named transition and one bounded requirement.
• Four to six gates with unique IDs.
• A priority for every gate.
• An observable condition and inspectable evidence for every gate.
• A named owner or checking role for every gate.
• A failure action for every gate.
• A reviewable commit, pull request, tagged revision, or clearly identified equivalent checkpoint for the change.
• A meaningful evaluation performed against that exact checkpoint, with its method and result recorded.
• A one-sentence definition of done that distinguishes P0, P1, and P2 outcomes.
• At least one explicit escalation rule.
• At least three non-goals.
• A documented recovery or rollback path naming the known-good checkpoint, trigger, responsible role, and post-recovery verification.
• A short note explaining the most important prioritization and recovery decisions.
• A review-effort allocation that identifies the highest-consequence gates, assigns time or percentages and an owner to each review activity, and justifies the allocation by risk and reversibility.
• A record of which AI suggestions were accepted, rejected, or left unresolved, with reasons.

Run a reviewer test: give the packet to another person, or read it after a short break, and ask whether they could determine pass, fail, or escalation without asking what you meant. They should be able to identify the exact state that was evaluated, determine whether the evaluation supports the gate result, and state what to restore if the change causes the defined failure. They should also be able to state whether the transition is done from the packet alone. Revise any gate that requires interpretation beyond the stated evidence.

2396. Practical assessment

Score the completed packet from 0 to 18 points, awarding 0 = missing or unusable, 1 = present but incomplete, or 2 = complete and decision-ready for each criterion:

1. Transition fit: The gates govern the named boundary and bounded requirement.
2. Priority rationale: P0, P1, and P2 choices are justified by consequence and timing.
3. Reproducible evidence: Another reviewer can repeat each check with the named tools and evidence.
4. Escalation authority: Failure thresholds identify who blocks, accepts risk, or schedules follow-up.
5. Checkpoint traceability: The exact evaluated state, evaluation method, and result are linked.
6. Recovery feasibility: The trigger, known-good state, responsible role, and verification make reversal executable.
7. Non-goals: Packet-level exclusions prevent likely scope expansion; gate-level non-goals are included where they clarify a specific gate.
8. Review-effort allocation: Time or percentages total the stated budget, have owners, and are justified by risk and reversibility.
9. AI disposition: Accepted, rejected, and unresolved AI suggestions are documented with project-based reasons.

A packet is complete at 14 points or more, with no zero on reproducible evidence, checkpoint traceability, or recovery feasibility. Revise and reassess any packet below that threshold; the score evaluates decision quality and traceability, not preferred tools or terminology.

2397. Key takeaways

• A prioritized set of technical gates is the definition of done for a specific transition or milestone, not a claim that the whole project is finished.
• A complete Gate Card states the transition, priority, condition, evidence, owner, and failure action. Non-goals are mandatory for the packet and may be attached to individual gates when they clarify a gate-specific boundary.
• A reviewable checkpoint identifies the exact state under evaluation; it is not a substitute for meaningful evaluation.
• A recovery path names the known-good state, trigger, responsible role, and verification required after rollback or reversal.
• P0 gates block, P1 gates require resolution or explicit risk acceptance before the next milestone, and P2 items remain owned and scheduled without blocking the current transition.
• AI can draft and challenge gates, but people must verify evidence, evaluate the change, and accept project risk.

2398. Next lesson

Next: 5.15 — Creative direction, where technical direction is handed off to the creative direction work with its scope, constraints, unresolved decisions, and technical checkpoint status clearly identified.

2399. Knowledge check