Start from decisions, not from models

A product team gathers for the quarterly roadmap review. Someone opens with a familiar question: where could we add an assistant? Within two weeks the room fills with possibilities. A meal-planning chatbot. A summarisation widget for internal docs. A copilot that drafts replies in support. Each prototype works on a happy path. Executives see fluent output. Engineers see integration debt. Nobody can answer the question that matters: what domain result is this organisation trying to produce, and who owns the consequence when the answer is wrong?

Helpful context: Outcomes, not features owns the outcome sentence alone (step two of this workshop). The Thoughtware Map and Grammar owns map and grammar detail. Start with one bounded judgment is the first construction move after framing. This page owns the full workshop sequence that produces a named decision map before anyone selects a model tier, writes a system prompt, or chooses an agent framework.

Why decision-first beats model-first

A feature list describes possible outputs. It does not identify the outcome whose cognitive burden should move into software, reveal where judgment occurs, clarify which decisions require human leadership, name what must remain exact, specify what the system is allowed to remember, or describe how its conduct will be evaluated. An implementation intention like "use GPT to recommend meals" names a technique before purpose is clear. Both patterns feel productive because they produce visible artifacts quickly. Both leave the hard questions unanswered until production consequences arrive.

Decisions give framing its sorting questions: is this work closed enough for code, or open enough that someone must own the answer? Judgment terrain asks how patterned, consequential, and reversible each link is. Together they prevent the common mistake of treating every interpretive step as "the model will figure it out" and every exact step as "we will prompt carefully." Framing makes those assignments explicit before build choices harden hidden assumptions.

Weak framing cannot be rescued reliably by a stronger model. When the outcome remains vague, architecture expands around whatever the model happens to be able to do. When judgment locality is unnamed, failures have no address. When authority is implicit, the system drifts into scopes nobody approved. Framing is how teams buy themselves a coherent object to implement, evaluate, and improve.

The workshop sequence

Work begins before models, prompts, tools, or interfaces are selected. The sequence is ordered because later steps depend on earlier ones, and skipping steps produces maps that look complete but behave incoherently under stress.

The first move locates cognitive burden: where interpretive, comparative, planning, and corrective work already happens in the domain, often in human routines the software is meant to support. The second step defines the outcome as a domain result with boundaries, refusing scope creep by naming what the system will not do. Third, the team maps the Judgment Chain, naming the sequence of interpretations, decisions, checks, and actions that produce the outcome. Fourth, terrain classification asks six questions per link: how deterministic, novel, well-covered by knowledge, consequential, reversible, and evaluable is this judgment? Fifth, leadership allocation assigns each decision to a person, a cognitive unit, a shared judgment, or deterministic code based on its terrain.

The sixth step identifies cognitive units and agents: named judgments versus goals that need continuing ownership across changing working state. Seventh, the deterministic boundary is established for calculations, schemas, validations, permissions, transactions, and audit. Eighth, memory receives explicit routing by type: context for this run, working state for the current plan, endorsed knowledge for standing facts, experience records for learning, expertise primitives for compression, and evaluation memory for performance history. Ninth, Cognitive Posture is defined: role, initiative, confidence, restraint, challenge, explanation, and recovery rules that govern conduct. Tenth, authority and escalation state what may be done, proposed, approved, and reversed, and by whom. Eleventh, evaluation and learning routes are created: graders, cases, gates, regression, promotion, and rollback. Twelfth and finally, the team produces the Thoughtware Map: the shared workshop artifact that holds the framing together and will be handed to specification and construction.

Each step answers a question a feature list cannot. Steps one through five connect terrain to leadership so that allergy enforcement belongs in deterministic code, busy-evening fit belongs in a named cognitive units, and purchase stays behind human approval. Steps six through eight translate the map into buildable structure where memory forms separate this-run context from endorsed knowledge so temporary corrections do not silently become durable policy. Steps nine through eleven govern trust: posture describes how the system conducts itself when information is missing, authority states what the system may do without approval, and evaluation ties behaviour to cases rather than model releases alone.

1. 01OutcomeDomain result with boundaries
2. 02Judgment ChainNamed links and leadership
3. 03Memory and authorityWhat may be believed and done
4. 04Thoughtware MapWorkshop artifact that holds it together

Framing produces a shared object before implementation choices harden hidden assumptions.

What weak framing costs

Teams that skip framing pay predictable costs. Demos impress in isolation because happy paths hide missing boundaries. Production reveals the gaps: medical advice where the product only planned dinners, purchase actions without approval, memory that treats a temporary preference as enduring fact. Each failure is treated as a prompt problem when it is an architecture problem.

Strong framing does not guarantee good behaviour on day one. It guarantees that failures have an address. When AssessMealPracticality fails on busy Tuesday, the team knows which judgment to fix, which suite to extend, and whether authority was too high for the evidence available. When framing stayed at "meal assistant," the same failure becomes a vague complaint about model quality with no path to improvement.

What this looks like in practice

The Weekly Meal Companion frames as accepted weekly plan under constraints, not "GPT meal app." The originating household request mentions no models:

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

Framing produces concrete artifacts before substrate selection. The outcome sentence reads: 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. The boundary names refusals: the system plans household dinners, does not diagnose medical conditions, does not create dietary policy, does not replace professional guidance, and does not purchase groceries without approval.

The Judgment Chain names links in order: InterpretWeek, GenerateCandidates, AssessMealPracticality, ComposeWeek, CritiquePlan, and repair steps when critique finds weakness. Terrain rows make leadership legible. Confirmed cashew allergy is exact once knowledge is endorsed, so deterministic validation owns it. Whether a candidate fits a busy evening is fuzzy but strongly patterned, so a cognitive unit owns it. Composing the full week involves competing goals, so agent strategy leads. Portion math stays in code.

Memory forms receive explicit policy. "Tuesday is busy this week" is context for this run. "Busy evenings stay under twenty-five minutes of active effort" is endorsed knowledge. "Avoid pasta because we had it recently" is a temporary correction that must not silently become durable knowledge without approval. Authority states what the agent may propose versus what requires household consent. At least one evaluation route exists before anyone selects a model tier: given a busy-week working state, AssessMealPracticality must fail a sixty-minute recipe on a flagged evening.

That map is what makes outcome framing more than a slogan, what makes making the specification executable possible later, and what lets a team ship one bounded judgment as a first vertical slice instead of a platform diagram with nothing measurable.

Weak framing cannot be rescued reliably by a stronger model.

Introduction to Thoughtware . Ch. 30

Common mistakes

Starting with model selection. Model tier is one decision among dozens. Without a map, the team optimises fluency while architecture drifts into unowned scopes.

Treating the workshop as documentation theatre. A Thoughtware Map that never connects to specification, contracts, and suites remains a slide deck. Framing earns its keep when it becomes the human-authored layer construction derives from.

Framing the whole enterprise at once. The twelve steps belong to one product slice. A household dinner planner teaches the method. A portfolio-wide map on day one usually hides unresolved conflicts between teams rather than surfacing them.

Confusing posture with personality. Cognitive Posture is conduct architecture: when to ask, when to challenge, when to defer. It is not brand voice pasted onto a chat widget.

What to do next

The twelve-step sequence above applies to one bounded slice of real work, not an imaginary platform. Running those steps for a household dinner planner or an invoice intake flow produces a Thoughtware Map with named judgments, terrain, and authority before models enter the conversation. That map then hands off to a Thoughtware specification for durable record and to making the specification executable for runnable structure. The first construction move after the map exists is shipping one bounded judgment as a vertical slice with evidence and declared gaps.

See Judgment chains for mapping sequences in depth, outcomes, not features for the outcome sentence alone, and the Thoughtware Map and Grammar for the shared artifact format.

Read next: Outcomes, not features.