Scope the decision before you build

“Build an AI assistant” is a capability, not a product decision. Before code, name who will use the output, what they decide with it, and what the system must not do.

The trap: a broad prompt hides a broad obligation

Our synthetic running case is Event Brief: it drafts an event briefing from fictional event notes for an event operations coordinator to review. “Summarise the notes” leaves open whether the draft is advice, a record update, or a message for attendees. Each interpretation needs different evidence. The product boundary must choose one.

Picture the handoff. A coordinator opens a note that says, “the room may change; confirm signage,” and asks for help before a busy event. A vague assistant could invent a new room, update a record, or compose a message. All three outputs may look useful. None answers the narrower question: what should this coordinator verify first, and what can they check against the note?

That distinction is practical. A product decision names a permitted next move for a named person. A capability label—“AI briefing assistant”—does not. If two reasonable teammates would build two different things from the same sentence, the sentence is still a request for scope, not a scope.

The move: make the boundary inspectable

A scope card records the smallest useful promise. In this case, the output helps an event operations coordinator decide what to verify first. It is a reviewable draft with source spans, not a domain-specific recommendation.

Read the card as a refusal as well as a promise

The diagram is a decision path, not a system architecture. The left box is the only input in this teaching slice. The middle box records why the output exists and what failure matters. The right box is deliberately a draft + spans: a reviewer can compare a statement with the synthetic note instead of accepting a fluent paragraph on trust.

Work the same request twice. Version A says, “Draft a briefing item with the source span for the room-change note.” Version B says, “Tell attendees that the room is changing.” A stays inside the card: it produces review material for the coordinator. B crosses the coral non-goal because it sends a message to a different audience and creates an external action. The correct result for B is not a better prompt. It is out of scope.

scope_card = {
    "user": "event operations coordinator",
    "input": "synthetic event notes",
    "output": "event briefing draft with source spans",
    "decision": "what to verify first",
    "failure": "invented briefing item",
    "non_goal": "domain-specific advice",
}

Use the card before discussing a model, interface, or provider. If you cannot fill a field without saying “it depends,” keep the uncertainty on the card: choose a smaller input, a smaller decision, or an explicit refusal. This is how APD.2 can turn the boundary into fields and states instead of inheriting ambiguity as product behavior.