1861. Lesson identity
This lesson extends the previous lesson, 4.12 L2 — Make the handoffs visible. A visible handoff is not automatically a usable handoff. The receiving person also needs a precise interface for the work.
1862. Learning objective
After this lesson, you can identify ambiguity in an outsourcing request by separating its scope, inputs, outputs, constraints, and acceptance evidence.
1863. Why this matters
External work fails when the requester and the receiver silently hold different definitions of “done.” A short request can hide missing assets, incompatible assumptions, unbounded scope, or an acceptance standard that nobody can check. Treating a handoff as an interface makes those assumptions explicit before implementation begins. This protects the game’s coherence without requiring the requester to prescribe every implementation detail.
1864. Prior knowledge
You should already be able to make a team handoff visible by naming the artifact, owner, evidence, and acceptance decision, as practiced in 4.12 L2 — Make the handoffs visible. You should also be familiar with separating a desired outcome from the implementation used to produce it.
1865. Core concept
An outsourcing request is an interface between two people or teams. It must define five parts:
| Part | Question it answers | Example |
|---|---|---|
| Scope | What work is included, and what is excluded? | Create one pause-menu layout; do not redesign the settings screen. |
| Inputs | What information, assets, and decisions does the receiver get? | Current screen capture, target resolution, copy, and style reference. |
| Outputs | What artifact must the receiver return? | A documented layout specification and exported visual reference. |
| Constraints | What conditions must the result respect? | Existing navigation, readable text, controller support, and fixed screen bounds. |
| Acceptance | What observable evidence allows the requester to accept or reject it? | The layout passes the listed navigation and readability checks. |
A request can be detailed in one area and still be ambiguous overall. For example, “make the pause menu feel cleaner” describes an intention, not a bounded deliverable. The receiver cannot reliably determine what to produce or how the result will be judged.
1866. Mental model
Use the SCOPE interface before assigning external work. The acronym maps directly to the canonical five parts:
S — Scope: included work and explicit exclusions
C — Context: inputs, references, and current assumptions
O — Output: artifact or decision to return
P — Parameters: constraints the result must respect
E — Evidence: acceptance evidence—the observable checks and proof
used to evaluate the result
In this mapping, Context means Inputs, Parameters mean Constraints, and Evidence means acceptance evidence. The wording changes to preserve the SCOPE mnemonic, but the five interface parts remain Scope, Inputs, Outputs, Constraints, and Acceptance.
Evidence and acceptance are related but not identical. Evidence is the observable proof produced by checks, such as a capture, test result, or completed checklist. Acceptance is the requester’s decision to accept or reject the work using that evidence. Evidence supports acceptance; it is not the acceptance decision itself.
The model is not a request for exhaustive documentation. It is a test for ambiguity. If a receiver would need to guess an answer to any of the five questions, the interface has a gap.
A useful distinction is:
- Outcome: what the game or team should gain.
- Interface: what the external contributor must receive and return.
- Implementation: how the contributor chooses to produce the result.
The interface should make the outcome testable without unnecessarily dictating the implementation.
1867. Concrete example
Consider this request:
“Please improve the pause menu so it feels more polished and works well on controller.”
The request has a direction, but it leaves several decisions unresolved:
- Scope: Is the work limited to the pause menu, or does it include settings and controls screens?
- Inputs: Which existing layout, copy, screen sizes, and controller mappings should be used?
- Outputs: Is the expected result a visual mockup, an implemented screen, a navigation specification, or all three?
- Constraints: Must the existing navigation structure remain unchanged? Are localization, safe areas, and accessibility requirements in scope?
- Acceptance: Which controller actions must work, and what evidence demonstrates that they work?
A stronger interface might say:
“Create one revised pause-menu layout for the existing screen dimensions. Use the supplied current screenshot, copy, and controller mapping. Keep the current menu destinations and navigation order. Return a visual layout plus a short navigation table. The result is accepted when every listed destination is reachable with the assigned controller actions, focus remains visible, and all supplied text fits within its defined area. Do not change the settings or controls screens.”
This version still leaves room for implementation judgment, but it gives both parties a shared boundary and a checkable finish line.
1868. Common mistake
The common mistake is to treat a desired quality word as a specification. Words such as “polished,” “responsive,” “clean,” and “professional” may communicate intent, but they do not define scope, inputs, outputs, constraints, or acceptance. They can remain as design direction only after the observable requirements around them are explicit.
Another mistake is over-specifying the implementation while leaving acceptance vague. Telling an external contributor which files, tools, or sequence to use does not answer whether the resulting artifact satisfies the game’s needs.
1869. Guided practice
Analyze the following outsourcing request:
“Build a new enemy warning indicator for the combat HUD. Make it clear, match the game style, and make sure it does not get in the way.”
Create a five-row table with these columns: Interface part, What the request states, What remains ambiguous, and One clarification question. Use one row each for scope, inputs, outputs, constraints, and acceptance.
Then make one decision: choose the single ambiguity that should be resolved first. Explain why resolving it reduces the greatest downstream risk. Do not rewrite the entire request yet; first identify the boundary that controls the other decisions.
1870. Validation / evidence
Your evidence is:
- A completed five-row ambiguity table.
- One selected highest-risk ambiguity.
- A justification that connects the selected ambiguity to scope, implementation, or acceptance risk.
Your work is sufficient when another person can distinguish what the external contributor may decide from what the requester must decide before work begins. A request is not ready merely because it sounds specific; it is ready when the intended output and its acceptance evidence are testable.
1871. Knowledge check
Answer the quiz associated with this lesson. The questions test whether you can distinguish an outcome from an interface, locate missing boundaries, and select useful acceptance evidence.
1872. Key takeaways
- An outsourcing request is an interface between the requester and the external contributor.
- Scope, inputs, outputs, constraints, and acceptance expose different kinds of ambiguity.
- A quality word is not a substitute for observable acceptance evidence.
- Define the result and its boundaries without unnecessarily dictating implementation.
- Resolve the ambiguity with the greatest downstream risk before external work begins.
1873. Next lesson
The next lesson is 4.13 L2 — Write an AI-ready external brief. It turns an identified ambiguity into a bounded external-work brief and reviewable acceptance criteria.
1874. Handoff contracts (fix-handoff-contracts)
Open academy-fixtures/labs/handoff-contracts. Run node run.mjs. Record inputs, outputs, owner, invariants, failure (illegal write), validation. Then fix-save-roundtrip: academy-fixtures/labs/save-roundtrip → node run.mjs.
1875. Knowledge check
Answer these items for yourself before reading the answers.
Which item defines the observable conditions and evidence used to decide whether outsourced work is acceptable?
Show answer and feedback
Answer: Acceptance criteria
Why: Acceptance criteria define the observable checks and evidence used to accept or reject the result.
What is the main ambiguity in the request “Make the combat HUD feel more polished”?
Show answer and feedback
Answer: It does not define an observable result or acceptance standard.
Why: “Polished” communicates intent, but it does not identify the deliverable or how the result will be judged.
Which request best preserves implementation choice while defining a usable interface?
Show answer and feedback
Answer: Return the defined artifact, respect the listed constraints, and demonstrate the stated acceptance checks using your implementation approach.
Why: A good interface defines the output, constraints, and acceptance evidence while leaving the contributor room to choose how to implement it.
Why should the highest-risk ambiguity be resolved before rewriting the entire outsourcing request?
Show answer and feedback
Answer: It prevents later details from being built on a boundary that may be wrong.
Why: A high-risk unresolved boundary can invalidate later scope, inputs, outputs, and acceptance decisions, so it should be clarified first.