Start from the result, not the feature list

Your team is planning an AI feature. Someone asks: "Where could we add an assistant?" Within a week you have a slide deck. A meal ideas chatbot. A summarisation widget. A copilot for support tickets. Each demo works in isolation. Stakeholders see fluent output. Nobody can answer the question that should come first: what is this product actually trying to accomplish, and how would we know if it succeeded?

Helpful context: Start from decisions, not from models owns the full twelve-step workshop. This page focuses on one step: outcome versus feature list versus implementation intention. The workshop scene, Judgment Chain mapping, terrain classification, and Thoughtware Map production live on the framing page. Here the focus narrows to the outcome sentence and boundary that make every later step possible.

Three ways teams phrase the work

Teams describe the same dinner-planning product three different ways, and the differences are architectural rather than cosmetic. A feature list like "add a meal planning assistant" describes what the interface might show without identifying the cognitive burden that should move into software. An implementation intention like "use GPT to recommend recipes" names a technique before the burden is clear. An outcome statement like "help a household produce an accepted weekly dinner plan under their constraints" names the domain result whose interpretive work should shift into Thoughtware, with boundaries for what the system will not do.

Framing	Example	What it buys
Feature / assistant list	"Add a meal planning assistant"	Demos, not architecture
Implementation intention	"Use GPT to recommend recipes"	Substrate before purpose
Outcome	"Help a household produce an accepted weekly dinner plan under their constraints"	Decisions, authority, evaluation

The same outcome could be served by several architectures with different cost and reliability profiles. That flexibility matters. When the outcome stays vague, architecture expands around whatever the model happens to be able to do. A "meal assistant" can drift into medical advice, grocery purchasing, or nutrition policy because nothing in the framing refused those scopes. An outcome with boundary makes refusal discussable before build choices harden.

Why the outcome sentence matters

Without an outcome, three failures follow quickly. The first is missing authority boundaries. Features do not state what the system may propose, approve, or refuse. Authority becomes whatever the demo accidentally did on the happy path. For household dinner planning, purchase without approval and medical interpretation without deferral are different products with different consequence profiles. An outcome boundary names what the system will not do so those refusals are designed, not discovered in production.

The second failure is missing evaluation. Meaningful suites cannot be written for "assistant quality." They can be written for whether a plan passes exact checks: busy evenings under twenty-five minutes of active effort, confirmed allergies excluded, shopping list matches portions, material assumptions visible to the household. Evaluation needs a result to measure against, and the outcome sentence is that result.

The third failure is missing named judgments. Every cognitive step collapses into "the agent," or one oversized agent hides interpretation, comparison, critique, and repair with no decision locality. See separating, not sorting when one blob hides several decisions that need separate owners. With an outcome, the team can ask who owns busy-Tuesday fit, who enforces allergy exclusion, and who approves purchase. Each is an open judgment or closed check with a named owner.

Outcome framing keeps decisions above substrate. Implementation intentions invert the order: the team chooses a model, then discovers what the product was supposed to accomplish by reading the model's outputs. That inversion is how strong demos produce weak systems.

1. 01OutcomeDomain burden to move
2. 02DecisionsWhat must be judged
3. 03Architecturecognitive unit, authority, memory
4. 04SubstrateModels and tools last

Outcome framing keeps decisions above substrate. Implementation intentions invert the order.

Outcome and boundary as a pair

The outcome sentence names what success looks like in domain language a household or manager would recognise. The boundary sentence names what the system refuses so scope creep cannot hide inside helpfulness. Neither sentence is sufficient alone. Outcome without boundary invites drift because "help people eat better" can mean medical diet coaching, calorie tracking, meal planning, or grocery optimisation, each carrying different authority requirements. Boundary without outcome produces a list of refusals with no centre. Together they define a product slice small enough to frame and large enough to matter.

For the Weekly Meal Companion, the grounding reference converges on:

Outcome: Help a household create a practical weekly dinner plan that reflects the current week, respects confirmed constraints, uses ingredients sensibly, supports local correction, and prepares an accurate shopping list.

Boundary: The system plans household dinners. It does not diagnose medical conditions, create dietary policy, replace professional guidance, or purchase groceries without approval.

Those two sentences already imply named judgments (AssessMealPracticality, JudgeWeeklyVariety), deterministic shell work (allergy enforcement, portion math), and authority limits (may propose purchase, may not complete it). Features derive from outcome decomposition, not the other way around.

What this looks like in practice

The running example begins from a household request, not from model choice:

Plan dinners for four people this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week.

A feature-first team might respond by scoping "meal chatbot with recipe retrieval." An implementation-intention team might scope "RAG over recipe corpus with GPT-4." An outcome-first team asks what accepted plan means for this household: practical evenings on busy days, sensible ingredient use, variety without repeating last week's meals, a shopping list the household trusts.

That reframing changes the architecture conversation immediately. Busy-evening fit becomes a judgment worth naming and evaluating, not a prompt adjective. Spinach-before-Wednesday becomes a constraint the plan must satisfy or explicitly challenge. Last week's meals belong in working state or context, not in a vague "remember preferences" instruction. Allergy enforcement moves toward deterministic code once knowledge is endorsed. The team can write checks before selecting a model tier.

Two success statements for the same initiative illustrate the difference. A weak version reads: "Users like the assistant." A strong version reads: "Given Tuesday and Thursday flagged busy, no accepted plan includes a candidate AssessMealPracticality fails, confirmed allergies never appear in candidates, and the shopping list matches declared portions." The strong version is testable. It connects outcome language to evaluation hooks the framing workshop will later formalise.

When the outcome remains vague, the architecture expands around whatever the model happens to be able to do.

Introduction to Thoughtware . Ch. 30

Common mistakes

Stopping at the feature list. "Meal planning assistant" is a label, not a result. The meaningful question is what accepted plan means for this household this week.

Jumping to the model. "Use an LLM to recommend meals" chooses substrate before purpose. The same outcome could use several architectures with different cost and reliability profiles.

Outcome without boundary. Open-ended helpfulness is how products inherit scopes nobody approved. Boundary makes refusal designable rather than accidental.

Outcome without success checks. A sentence a manager recognises is necessary but not sufficient. Success checks connect the outcome to evaluation: exact checks pass, material assumptions visible, authority respected.

Repeating the full framing workshop here. Outcome and boundary are step two of twelve. Judgment Chain mapping, terrain, memory forms, and posture belong on framing. This page exists so teams do not conflate the outcome sentence with the entire workshop.

What to do next

The outcome sentence and boundary together form the anchor that every later framing step refers back to. A domain result named in language a household or manager recognises, paired with refusals that make authority designable, is what allows the full framing workshop to proceed with named judgments, terrain, and memory policy. When the team is ready for Judgment Chain mapping, terrain classification, and the Thoughtware Map, the full workshop owns those steps. For the first construction move after the outcome is named, start with one bounded judgment describes what fully enclosed means and why one vertical slice beats a platform diagram.

Weak framing cannot be rescued reliably by a stronger model. Outcome framing is what keeps authority, memory, and evaluation discussable before substrate is chosen.

Read next: Start with one bounded judgment.