Judgment should have locality

Allergy checks appear in three places: the mobile UI disables a button, the API validator rejects unsafe ingredients, and the composition template includes a paragraph that "remembers" cashews. Each implementation drifts slightly. Tuesday's plan passes the client and fails the server. Worse, both pass while violating endorsed household knowledge because the prompt used an outdated allergy list.

The team did not intend three sources of truth. They intended responsiveness and safety. Without locality discipline, good intentions become contradictory judges.

White Paper Principle 2 states the rule: judgment should have locality. One primary home per open judgment. Duplicates may exist only when they are intentional, synchronized, and documented. Accidental copies across layers are architectural defects waiting for production traffic.

This page is the operational compliance angle. Where does a decision live? introduces the locality question in Shift vocabulary. Judgment should be explicit requires naming first. Together, explicit naming and single homes make responsibility traceable.

Drawing the judgment map

Before debating models, sketch every open judgment in the feature. Put a dot where the judgment is actually decided today, not where the specification says it lives. Read code, prompts, and UI copy honestly.

Multiple dots for one judgment signal a locality violation unless a sync story exists. The map is a team exercise. It works best on a whiteboard with the outcome sentence at the top and the Meal Companion named edges as reference labels.

Judgment	Primary home (Meal Companion)
Confirmed allergy enforcement	Deterministic validation (closed)
Busy evening meal fit	AssessMealPracticality
Weekly composition under competing goals	Agent-led ComposeWeek strategy
Missing preference clarification	AskTargetedQuestion, then household
Unfamiliar medical diet interpretation	Household or professional-led

When the UI re-implements practicality "for responsiveness," you now have two judges with no synchronization rule. They will disagree under edge cases. Incidents will reproduce intermittently because clients and servers saw different worlds.

Locality is not centralization of all checks

Principle 2 is often misread as "only one layer may touch a concern." That misread blocks legitimate defence in depth for closed work.

Two layers may enforce the same exact rule. The UI disables purchase when approval is missing. The server rejects the same request. Both call the same deterministic validator or read the same endorsed knowledge. That pattern expresses one closed rule referenced consistently, not two open judgments. Open judgment duplicated without a sync story is different. Two practicality judges with different prompts are two opinions. Two composition strategies in middleware and agent without declared precedence are two owners. Locality forbids accidental duplication, not intentional redundancy with a shared source of truth.

Relationship to explicit judgment and separation

Separating, not sorting splits compound features into distinct decisions. Locality assigns each split decision exactly one primary home. Separation without locality produces many named cognitive units that still overlap in prompts.

One cognitive unit, one open decision prevents compounds at the contract edge. Locality prevents the same decision from reappearing outside that edge under another name. Both rules apply together during refactors.

The distinction becomes visible when teams migrate from demo to architecture. Demos tolerate smeared judgment because traffic is low and reviewers share context. Production traffic exposes contradictions.

Judgment should have locality.

Thoughtware White Paper · Pr. 2

What this looks like in practice

Take busy evening fit, a fuzzy but strongly patterned judgment in the terrain table.

Correct pattern. AssessMealPracticality owns the open decision. The agent invokes it when evaluating candidates. Deterministic code validates outputs and enforces hard constraints. UI may display verdicts and reasons returned by the cognitive unit. UI does not re-score meals locally unless it calls the same contract through an API that shares suite identity.

Violation pattern. Mobile code embeds heuristics about cooking time. Middleware adds another heuristic for "simple meals." ComposeWeek template includes natural-language rules about Tuesdays. Three homes, three drift paths, one angry household.

Repair starts by picking the primary home, deleting or redirecting duplicates, and publishing the contract callers must use. Locality fixes are boring and high leverage. Portion calculation never belonged in cognitive units. It lives in deterministic code with a single implementation. That is locality for closed work: one exact function, many callers.

Human homes count

Locality applies to human judgment too. Purchase approval has one designed gate: a human node with explicit artifacts, not three different "are you sure" modals that disagree about what is being purchased.

Human judgment remains part of the system by design for consent and consequence. Those human homes must appear on architecture diagrams as first-class nodes with handoff contracts, not as informal habits discovered after launch. When leadership returns for medical diet interpretation, the map shows the return path explicitly. Implicit human judgment violates Principle 2 the same way implicit model judgment does.

Enterprise parallel

Invoice intake material uses the same structure. Classification and extraction cognitive units live in libraries with single primary homes. Clerks remain the human home for contested fields with financial consequence. Middleware that re-classifies for "speed" without calling the library contract duplicates judgment and breaks audit trails. The same pattern appears in any regulated domain where multiple teams touch the same decision pipeline, because each layer that re-implements a judgment without referencing the primary home introduces a potential compliance gap.

The domain changes. The locality rule does not.

Common mistakes

Prompt inheritance. Teams fork a parent prompt into three services. Each fork becomes a new home unless inheritance is automated and versioned.

Feature flags that change judgment. A flag switches practicality thresholds in UI but not in server-side evaluation. Flags must not silently alter open judgment without updating the named home and suites.

Middleware "helpfulness." An API layer rewrites cognitive unit outputs to sound nicer. If the rewrite changes meaning, middleware has become a hidden judge.

Copy-paste judges. Judge-library entries duplicated into a product repo to "move faster." Two homes, diverging calibration.

Synchronizing intentional duplicates

When two layers must enforce the same closed rule, the shared source is documented. Both UI and server call the same validator function or read the same endorsed knowledge record. Tests fail if either copy diverges.

When two cognitive units appear to answer the same open question, merge them or split the decisions until the overlap disappears. AssessMealPracticality and a shadow practicality scorer in middleware is accidental duplication. Allergy validation in UI plus server is intentional duplication with a shared closed rule.

Incident reviews update the judgment map. If production found a fourth home for busy-evening fit, the map was wrong or the code violated it. Locality fixes belong in the same incident ticket as the user-visible bug.

Locality across teams

Large organizations split UI, API, and agent work across teams. Locality violations appear at handoffs. API team re-implements practicality because agent team latency is too high. UI team adds heuristics because API responses feel sparse. Each team optimizes locally while the product accumulates contradictory judges.

Fixing this requires a shared judgment map in the program wiki or architecture repository, referenced in each team's definition of done. Pull requests that introduce new decision points must update the map or cite an existing primary home. Locality is a cross-team contract, not a solo architect exercise.

What to do next

Draw the judgment map for one outcome on one page. Mark actual decision points in code and prompts, highlight duplicate dots, and merge into a primary home or document sync rules with shared validators. Move closed checks to deterministic code with a single source of truth referenced everywhere, and split compounds so each cognitive unit owns one decision at one home.

Finish by reading the map aloud in a review. If two owners answer the same open question, fix locality before adding features.

Read next: Human judgment remains part of the system.