Write an AI-ready external brief

1876. Lesson identity

Module

4.13 — Outsourcing

Lesson

Write an AI-ready external brief

Academic type

Guided Build

Schema type

practical

Order

Lesson 2 in the module

Estimated time

45–60 minutes, including practice

This lesson turns the handoff interface from the previous lesson into a usable brief. The brief is designed for either a human contractor or an AI-assisted contributor. It defines the required deliverables, what may be changed, what must remain stable, how the result will be reviewed, and what evidence is required before integration.

1877. Learning objective

After this lesson, you can write an outsourcing brief with bounded scope, explicit inputs and deliverables, review gates, integration constraints, and observable acceptance criteria.

1878. Why this matters

Outsourcing does not remove design responsibility from the person directing the work. A vague request transfers ambiguity instead of transferring a task. That ambiguity becomes rework, inconsistent implementation, or integration risk when the contribution returns to the game. A strong brief gives the contributor room to solve a defined problem while preserving the project’s rules and review authority.

For AI-assisted contribution, this boundary is even more important: the contributor may produce plausible output without knowing which project assumptions are non-negotiable. The brief supplies those assumptions before implementation begins. Naming the deliverables also prevents a contributor from treating an informal progress update as a finished handoff.

1879. Prior knowledge

You should already be able to:

• distinguish scope, inputs, implementation, and acceptance from A handoff is an interface;
• state what evidence is used to accept or reject outsourced work;
• describe a task as an interface between a requester, a contributor, and an integration point;
• identify the part of a game task that is safe to delegate and the part that remains under project-owner review.

No specific engine or programming language is required for the writing exercise.

1880. Core concept

Bounded delegation means delegating a defined outcome without delegating the authority to redefine the problem.

An external brief must separate seven things:

1. Outcome: the player-facing or team-facing result that should exist.
2. Inputs: the information, files, conventions, and starting state the contributor may use.
3. Deliverables: the concrete materials the contributor must return, such as changed files, an asset, a short report, screenshots, or test evidence.
4. Boundaries: what the contributor may change and what must not change.
5. Review gates: the points at which work pauses for inspection or approval.
6. Acceptance evidence: the observable checks that determine whether the result is accepted.
7. Delivery and compatibility requirements: tool or engine version, editable source format, export format, naming and path conventions, delivery mechanism (branch, patch, or package), repository or package boundaries, and an explicit statement that the contributor has no merge authority unless separately granted.

Deliverables are a required brief field, not an optional administrative detail. Acceptance criteria describe whether the result is acceptable; deliverables describe what must be handed back so that the result can be reviewed and integrated. A brief may require both a changed implementation and a change summary, test evidence, and a list of known limitations.

The contributor owns the proposed implementation inside the boundary. The project owner retains responsibility for the boundary, the review decision, and integration into the larger game.

1881. Mental model

Use the Brief → Gate → Evidence model:

A complete brief can also be checked with this sentence:

“The contributor may change X, using Y, but must not change Z; the required deliverables are D; work is reviewed at G, and acceptance requires E.”

If one of these fields is missing, the task is likely under-specified. If the brief contains every implementation decision in advance, the task is over-constrained and delegation is not doing useful work.

1882. Concrete example

Weak request:

Improve the inventory panel so it feels cleaner and easier to use.

AI-ready external brief:

Task: Revise the inventory panel’s item-selection presentation for the existing inventory screen.

Desired outcome: When the player moves the selection across available items, the selected item is visually distinct, the item name and quantity remain readable, and the panel communicates unavailable items without changing inventory rules.

Inputs: Use the current inventory screen, existing item data, current selection behavior, project typography conventions, and the supplied screen capture of the target layout. Ask for clarification if any required input is missing.

In scope: Selection highlight, item-name and quantity presentation, unavailable-item visual state, layout spacing inside the existing panel.

Out of scope: Inventory data structures, item sorting, item costs, save data, controller bindings, navigation rules, and unrelated screens.

Required deliverables: InventoryPanel.presentation.ts with the three selection states implemented; InventoryPanel.presentation.test.ts; captures/inventory-selection-1920x1080.png; and CHANGELOG-inventory-selection.md.

Delivery and compatibility requirements:

• Tool or engine version: N/A for this example. Use the repository’s existing locked toolchain and report the resolved tool versions in the change summary.
• Editable source formats: TypeScript (.ts) for the presentation and test files and Markdown (.md) for the change summary.
• Export format: PNG at 1920×1080 for the required review capture.
• Naming and path conventions: Use the exact file names and paths listed above. Do not rename or move existing files.
• Delivery mechanism: Return one identified patch containing the required files and no unrelated changes.
• Repository boundary: The patch may modify only InventoryPanel.presentation.ts and InventoryPanel.presentation.test.ts and may add only the named PNG capture and Markdown change summary.
• Access requirements: Read-only access to the current inventory presentation files, existing item-data interface, typography conventions, and target-layout capture. No repository write access is required.
• Authority boundary: The contributor may prepare the patch but has no authority to merge, apply, or integrate it. The project owner retains that decision.

Integration constraints: Preserve existing item identifiers and selection events. Do not add a new dependency. Keep the contribution isolated to the inventory presentation layer. List every changed file and identify any assumptions made.

Review gates:

1. Before implementation: provide a short interpretation of the requested states and identify ambiguities.
2. After the first visual pass: provide a screenshot or recording showing selected, unselected, and unavailable states at 1920×1080.
3. Before integration: provide the final change summary, required deliverables, test evidence, and any known limitations.

Acceptance criteria:

• At the documented test resolution and 100% UI scale, a reviewer who cannot rely on color can still identify selected, unselected, and unavailable using a non-color marker (icon, border style, or label) in the supplied capture or in a structured inspection note.
• In that same capture, item name and quantity text are fully visible: no clipping, no overlap with the highlight, and contrast sufficient to read the strings without zooming.
• Existing inventory values and navigation behavior are unchanged.
• A second check at 125% UI scale leaves the same two strings unclipped; if the learner cannot perform the visual check, a peer verification note or inspection list is accepted.
• The contributor provides every required deliverable, including the changed-file list and any failed or skipped checks.

Integration decision: The project owner reviews the evidence and integrates the contribution only after the acceptance criteria and required deliverables are complete.

Notice what the brief does not do: it does not prescribe every color value, animation curve, or implementation method. Those decisions remain available to the contributor, but they are bounded by the required states, deliverables, and integration constraints.

1883. AI-native workflow

An AI-assisted contributor should be used in stages rather than given unrestricted authority:

1. Restatement: Ask the AI to restate the outcome, scope, exclusions, required deliverables, gates, and acceptance criteria. Correct the restatement before implementation.
2. Plan: Ask for a proposed change plan and a list of files or systems that may be affected. Reject plans that cross the out-of-scope boundary or fail to account for a required deliverable.
3. Small proposal: Request one bounded implementation or presentation change at a time.
4. Evidence: Require the AI to report changed files, assumptions, checks performed, unresolved issues, and each required deliverable.
5. Human review: Compare the result against the acceptance criteria and integration constraints. Do not treat the AI’s completion statement as evidence.

The AI may propose an implementation. It does not decide whether the scope should expand, whether an exception is acceptable, whether a deliverable is sufficient, or whether the contribution is integrated.

1884. Common mistake

The common mistake is writing acceptance criteria as preferences:

• “Make it polished.”
• “Keep it intuitive.”
• “Use a nice animation.”

These statements may communicate taste, but they do not establish a review decision. Convert each preference into an observable condition, a test situation, or a comparison artifact. If a quality cannot be checked by looking, playing, measuring, or inspecting the contribution, it is not yet a sufficient acceptance criterion.

A related mistake is omitting the deliverables because the contributor is expected to “send the work back.” Without a named list, the contributor may return an implementation without the changed-file list, test evidence, screenshots, or limitations needed for review. Specify the handoff materials in the brief and check their presence separately from the quality of the implementation.

A second mistake is allowing the contributor to modify adjacent systems “while they are already there.” That expands integration risk without passing through a review gate. Record adjacent improvements as separate requests instead.

1885. Guided practice

Write a complete external brief for one bounded task in a game project. Submit that brief as the scored practical assessment for this lesson; the quiz remains a knowledge check only. Choose a task such as:

• revising a menu presentation state;
• adding a visual feedback effect to an existing interaction;
• preparing a small accessibility presentation change;
• documenting a narrowly defined gameplay tuning change without changing the underlying rule.

Do not choose a task that requires redefining the game’s economy, progression, difficulty contract, or core interaction rules. The exercise is about delegation and integration boundaries, not about expanding the design.

Use this sequence:

Step 1 — Define the result

Write one sentence describing the observable outcome. Avoid implementation verbs such as “refactor everything” or “make it better.”

Step 2 — Bound the task

List:

• inputs the contributor receives;
• systems, files, screens, or behaviors in scope;
• explicit exclusions;
• dependencies or assumptions that must be confirmed.

Step 3 — Name the deliverables and delivery mechanics

Write the exact materials the contributor must return. Include the contribution itself and the review package, such as:

• changed files or assets;
• a short change summary;
• screenshots, recordings, or other defined presentation evidence;
• test results, including failed or skipped checks;
• assumptions and known limitations.

Do not write “deliver the finished work” as the only deliverable. Each required item must be identifiable at handoff. Add a Delivery and compatibility field: tool or engine version, source and export formats, naming or path rules, branch/patch/package mechanism, repository boundary, and no merge authority unless separately granted.

Step 4 — Add review gates

Define at least two gates:

• one before implementation or after interpretation;
• one before integration.

For each gate, state who reviews the work, which deliverables are expected, and what evidence is required.

Step 5 — Write acceptance criteria

Write at least four criteria. Each must name the test environment, the action, the expected observable state, and the pass/fail condition. Do not use “distinguishable at a glance” or “remains readable” without a comparison method. Include one non-color or alternative-evidence check. Include at least one criterion that protects existing behavior, one that checks the contributor’s reporting of changes or limitations, and one that confirms all required deliverables and delivery files are present.

Step 6 — Identify integration risk

Name the most likely way the contribution could damage or complicate the project. Add one constraint or evidence requirement that reduces that risk.

Step 7 — Perform the restatement test

Read your brief as if you were an external contributor with no unstated context. Write a five-line restatement of the task, including the expected deliverables. If the restatement introduces a new interpretation or omits a required handoff item, revise the brief before considering it complete.

1886. Validation / evidence

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

• a single bounded outcome;
• a clear list of inputs;
• explicit in-scope and out-of-scope areas;
• a named list of required deliverables, including the contribution, review materials, and delivery mechanism;
• at least two review gates;
• at least four operational acceptance criteria with environment, action, expected state, and pass/fail;
• a criterion or check confirming that all required deliverables are present;
• a named integration constraint;
• a changed-file, assumption, or limitation reporting requirement;
• a clear statement that the project owner decides whether the work is integrated.

To validate quality, give the brief to a peer or an AI and ask for only a restatement, a deliverables checklist, and a list of ambiguities. Do not ask for implementation yet. A passing brief produces no unresolved ambiguity about the intended outcome, required handoff materials, authority boundaries, or acceptance evidence. Any ambiguity that could change scope or alter a deliverable must be resolved before work begins.

1887. Key takeaways

• Delegate a bounded outcome, not the authority to redefine the problem.
• Treat deliverables as a required brief field: name every material needed for review and integration.
• Separate outcome, inputs, boundaries, review gates, and acceptance evidence.
• Treat AI output as a proposal that requires evidence and human review.
• Convert preferences into observable acceptance criteria and protect integration by naming exclusions.

1888. Next lesson

The next lesson is 4.14 — Legal basics. Continue to that module after completing this outsourcing brief.

1889. Knowledge check