Judgment should be explicit

"Use AI to improve meal planning" is not an architectural decision. It names neither the judgment, nor its owner, nor how anyone would know if the system failed on a busy Tuesday. Product decks fill the gap with demos. Engineering fills it with prompts. Operations discovers the gap when households reject plans and nobody can say which step was wrong.

White Paper Principle 1 refuses that vagueness. Judgment should be explicit: every open decision gets a name, a boundary, and a primary home before models, agents, or UI patterns are chosen. Explicit judgment is accountability technology. It turns interpretive work into something you can evaluate, price, and improve.

This page is the architect's compliance angle. What is judgment defines the term. Where does a decision live? introduces locality in Shift vocabulary. One cognitive unit, one open decision is the operational rule at the contract edge.

Implicit judgment is untestable

When busy-evening practicality hides inside the ComposeWeek template, several failures follow at once. You cannot evaluate practicality separately from composition. A regression in Tuesday fit might be a composition problem, a practicality problem, or an interaction between the two. Suites mix metrics that belong to different families.

You cannot substitute a better practicality model without touching composition. Every improvement risks unrelated behaviour change because two decisions share one identity version. You cannot assign ownership when Tuesday fails. The agent "decided," the template "said," and the UI "looked fine." Incident reviews become narrative archaeology.

Extracting AssessMealPracticality makes the judgment explicit: a first-class cognitive unit with its own decision sentence, contract, and suite. Composition still happens in ComposeWeek. Practicality is invoked where the terrain table assigns it (judgment terrain). Explicit naming is the prerequisite for cognitive capability should be encapsulated.

Explicit does not mean everything is a cognitive unit

Explicit judgment is often misread as "model all the things." That misread produces oversized templates and avoids the deterministic shell.

Portion math for four people stays in code. It is exact and verifiable. Purchase approval stays a human step with financial consequence and consent requirements. Allergy enforcement against endorsed knowledge belongs in deterministic validation once rules are fixed. Explicit means nowhere does open judgment hide without a name. If more than one defensible answer exists, consequences matter, and ownership must be visible, the spec shows where that work lives. If the work closed through evidence, it migrates toward code or endorsed expertise (maturity moves settled work out of runtime).

Naming before modeling

Teams often choose models before they name judgments. The order produces features that fluently violate constraints. A capable model can compose a plan that ignores a twenty-five-minute effort budget because nothing in the architecture said practicality was a separate decision with its own suite.

A healthier workshop sequence starts from the outcome sentence (start from the result, not the feature list), lists open judgments implied by that outcome, assigns each a cognitive unit name or human step, then selects models and orchestration. Models become policy inside declared identities, not substitutes for design.

Walk the Meal Companion verbs as a checklist: interpret, assess, compose, critique, recommend, judge, ask. Each maps to a named edge in the grounding reference or to a declared human node. None appears only as "the agent handles it" in a diagram footnote. Teams that skip the verb walk discover implicit judgments only during incident review, when tracing a household complaint to a template reveals decisions that nobody named, nobody owns, and nobody can evaluate in isolation.

What this looks like in practice

Consider the originating household request:

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

Explicit architecture names at least these judgments before build. Interpretation: InterpretWeek represents the request as structured context and calendar facts. Practical fit: AssessMealPracticality judges whether a candidate fits one evening, including busy budgets. Composition under competing goals: agent-led strategy invoking ComposeWeek when multiple valid weekly plans exist. Critique: CritiquePlan surfaces material weaknesses before acceptance. Local repair: RecommendMealSubstitution proposes a bounded patch when critique names one weakness. Clarification: AskTargetedQuestion when missing preference or authority blocks progress. Human nodes: purchase approval before grocery execution, and professional or household leadership when medical diet interpretation exceeds granted authority.

A spec that only lists "meal planning assistant" fails Principle 1 even if the demo impresses executives. Explicit judgment is what turns the demo into a system someone can maintain.

Judgment should be explicit.

Thoughtware White Paper · Pr. 1

Relationship to principles and specs

The ten principles index White Paper rules without re-teaching each one. Principle 1 is the front door for architects: if judgment is implicit, Principles 2 through 10 have nothing stable to attach to. Locality requires names. Encapsulation requires boundaries. Evaluation requires identities.

Executable specifications (specification executable) inherit Principle 1 literally. A Thoughtware Map row that says "improve UX" without a decision sentence is incomplete. A row that says AssessMealPracticality with inputs, outputs, and suite pointer is reviewable. Explicit judgment also supports contestability. Households challenge plans they dislike. Contestability requires knowing which edge produced which part of the plan. Implicit judgment makes contestation impossible because no edge owns the disputed decision.

From workshop to diagram

Explicit judgment changes meeting dynamics. Instead of debating which model to buy, the room lists judgments and assigns names. Product asks what the household must never suffer silently. Engineering asks which edges need suites before launch. Trust asks where authority stops.

The Meal Companion workshop table might look like this before any vendor selection:

Verb in outcome	Named home	Closed or open
Interpret request	InterpretWeek	Open, evaluable
Check confirmed allergy	Deterministic validator	Closed
Assess evening fit	AssessMealPracticality	Open, patterned
Compose competing goals	Agent strategy + ComposeWeek	Open, agent-led
Critique full plan	CritiquePlan	Open, judge-shaped
Approve purchase	Human gate	Consent, consequence

Rows with no name in the right column are Principle 1 violations waiting for sprint planning. The empty-name rows are the highest-leverage items in the backlog, because filling them creates the identity that evaluation, substitution, and ownership all depend on.

Common failures in reviews

Assistant lists. Backlogs that enumerate chatbots and widgets without outcome or judgment map.

Prompt-as-spec. A ten-page template substitutes for a contract. Reviewers cannot see abstain paths, authority limits, or evaluation hooks.

UI smuggling. Copy that re-implements practicality "for responsiveness" duplicates judgment without sync rules (judgment should have locality).

Implicit human steps. "User will approve" without wiring, artifacts, or consequence ownership. Human judgment remains (human judgment remains part of the system), but it must appear on the diagram as designed nodes, not as hope.

Backlog items that say "improve AI responses" or "add intelligence to planning" fail Principle 1 until translated. The author must name which judgment moves. If they cannot answer, the item is not ready for engineering estimation. Similarly, "use GPT for step three" describes policy, not architecture. Step three must already be a named edge with a decision sentence. Model choice belongs in the policy ring after explicit judgment exists.

What to do next

List open judgments implied by the outcome statement in plain language first. Assign each judgment a cognitive unit name or human step before model selection, reject feature specs that only list assistants, tools, or model tiers, and add suite pointers at naming time rather than in a hardening phase after launch. When finishing a design review, underline every verb that implies judgment. If any underline lacks a named home, the design fails Principle 1 regardless of model quality.

Principle 1 is the first gate in the sequence. Without explicit judgment, later principles have nothing stable to refine.

Read next: Judgment should have locality.