Visible thinking

Tuesday's meal is quick pasta. The household asks why. A good answer: Tuesday marked busy in the calendar, household rule caps busy evenings at twenty-five minutes active effort, selected recipe fits with twenty minutes active time, alternative stir-fry rejected at forty-five minutes. A bad answer: a scrolling log of internal tokens, or "trust me, it is optimized." Visible thinking is the product discipline of exposing enough rationale for trust, fix, and approval without dumping chain-of-thought theatre into the interface.

Helpful context: Contestability and confidence theatre set the trust bar. Intelligence beneath the surface explains why visibility is selective, not constant.

When to show thinking

The decision about when to expose rationale depends on consequence and contract mode, not on whether the system can generate explanations. Busy evening meal selection should show why this meal fits: the constraint plus the recipe attribute. Allergy enforcement should show source: endorsed knowledge, deterministic code check passed. Plan revision after correction should show the diff plus what triggered the replan. Routine variety choice may stay compressed unless the user contests, because the stakes are low and constant exposition trains users to ignore all rationale.

Situation	Show
Busy evening meal selection	Why this fits: constraint plus recipe attribute
Allergy enforcement	Source: endorsed knowledge, code check passed
Plan revision after correction	Diff plus what triggered replan
Routine variety choice	Compress unless user contests

The pattern is selective transparency rather than full disclosure. The selection criteria come from the decision the person needs to make: approve, contest, or fix. Each of those actions requires different information at different depth, and the product design determines which information appears at each level.

Balancing submergence and transparency

Submergence keeps scaffolding quiet on success paths. Visible thinking surfaces structure when consequence or contract mode requires the possibility of disagreement. The two principles work together rather than in opposition: submergence is the default on routine success, and visible thinking activates when the stakes require inspectable grounds.

The Collaboration Contract determines which visibility mode fits. When the person leads a decision, the system shows comparison and alternatives. When the person approves, the system shows proposal and grounds sufficient to reject. When the system acts autonomously within granted scope, it shows what it did and how to reverse it. Visibility without control is spectacle. Each exposed rationale needs a path to action: contest this assumption, fix this input, override this choice.

The layers that compose visible thinking separate into evidence (what was observed or retrieved), interpretation (what the system inferred), recommendation (what it proposes, with alternatives), and uncertainty (what remains unresolved). Separating these layers means disagreement can target the right layer. A household that contests Tuesday's meal might disagree with the busy flag (evidence), with the twenty-five minute rule (interpretation), or with the recipe time estimate (recommendation). Monolithic "because AI said so" blocks contest at every layer simultaneously.

Not chain-of-thought theatre

Internal tokens pasted into UI do not help households contest Tuesday's meal choice. They obscure the actual judgment beneath a wall of processing artifacts that were never meant for human consumption. Visible thinking selects which parts matter for disagreement, the same selection what a summary leaves out requires for accountable compression.

The distinction between visible thinking and transcript dump is architectural. Visible thinking is a designed output that translates system internals into domain language the household understands: "busy evening," "allergy list," "recipe time." A transcript dump exposes implementation artifacts: token sequences, chain names, probability scores. The first enables contest and correction. The second creates the illusion of transparency while actually obscuring the judgment by burying it in noise.

Invisible judgment, the third failure mode, presents a fluent answer with no inspectable grounds at all. "Quick pasta" appears without any rationale visible or expandable. Contestability becomes impossible because the household cannot identify what assumption to challenge. The product produces confidence theatre at the output layer, where fluent brevity substitutes for inspectable grounds.

Designing expandable rationale

The Tuesday quick pasta panel demonstrates the design pattern. Collapsed: "Quick pasta, twenty minutes active, fits busy Tuesday." Expanded: "Calendar marked Tuesday busy this run. Household rule caps busy evenings at twenty-five minutes active effort. Selected recipe reports twenty minutes active time. Alternative stir-fry rejected at forty-five minutes." That panel is visible thinking. It is contestable at the interpretation layer without exposing model internals.

Default collapsed for routine choices preserves flow. Expand on tap or on contest provides depth when needed. The rationale strings cite sources where possible: "Busy" from calendar, "Allergy" from endorsed list, "Uncertainty" when guest preferences are unknown. Each expandable row includes a disagree path that opens targeted correction: change the calendar link if busy is wrong, override the rule for this run, or provide a different recipe time estimate.

Rationale budget matters. Cap rationale length per situation: the busy Tuesday panel might show three lines collapsed, ten expanded. Uncapped rationale becomes a new wall-of-text that recreates the same problem it was meant to solve. The design goal is minimum sufficient rationale for the decision at hand, not comprehensive explanation of everything the system considered.

Contract mode drives visibility

Approval mode needs grounds sufficient to reject. Explore mode may tolerate lighter rationale until stakes rise. System-acts mode needs scope and reversal path visible before action. Mismatch between contract mode and visibility produces passive acceptance theatre: the household approves because the surface feels confident, not because grounds support the decision.

High-stakes outputs need expanded rationale by default in approval modes. Low-stakes explore modes may collapse until contested. Defaults follow the Collaboration Contract, not designer habit or a single template applied across all contexts. Regulated approvers need evidence spans linked to policy clauses. Consumer households need domain language without internal chain names. Same grounds, different depth, driven by role and mode.

Visible thinking and evaluation

Offline graders can check whether mandatory rationale fields appear for held-out cases. Product analytics track expand rate on high-stakes outputs. High expand plus high override may mean collapsed copy hides material assumptions that matter for the decision. Low expand with high correction may mean collapsed copy is ignored until problems surface at a costlier moment.

Engineering supports this by requiring rationale fields on cognitive unit outputs where UX exposes thinking. Empty rationale on a busy-day assignment fails the eval gate for planning features. Product and architecture share the contract: product defines which decisions need visible rationale, architecture provides the fields, and eval verifies they are populated and useful.

Contest rate on exposed assumptions, correction rate after expanding rationale panels, and support tickets asking "why" provide ongoing measurement. Support tickets should drop when panels answer material questions. If they persist, the rationale is not addressing the questions households actually ask.

Connection to confidence theatre

Fluent answers without grounds are confidence theatre. Visible thinking is the UX treatment when submergence would hide material assumptions the person needs to contest or approve. The two notes describe failure and remedy for the same problem: output that looks trustworthy but provides no basis for trust.

The cure is structural. Rationale panels translate system internals into household language. Contest buttons on each rationale row close the loop into correction. Loading states show specific progress rather than generic "thinking" dots: "replanning Tuesday for busy evening" rather than animated ellipsis. Every transparency surface connects back to an action the household can take, because visibility without agency is spectacle.

Common failures

The most frequent failure is token dumps presented as transparency: internal chain-of-thought pasted into the interface, readable to engineers and opaque to households. A close second is invisible judgment where the system produces confident output with no expand path and no source citation. Rationale without a contest action creates read-only theatre that feels transparent but provides no path to correction. And jargon rationale that exposes internal cognitive unit names ("JudgeWeekdayPracticality" instead of "busy evening rule") fails the household reader test while appearing technically complete.

These failures share a root: treating visibility as a quantity (more or less exposed) rather than a design choice (which information enables which action for which role). Visible thinking is architectural. It requires designed rationale fields, domain translation, layered expansion, and contest paths at each layer.

What to do next

The path toward visible thinking begins with one high-stakes output and the assumptions a user might disagree with. For each assumption, the minimum UI exposes it without a reasoning transcript: a collapsed line with source badge, an expand path to full rationale, and a disagree link that opens targeted correction. That pattern, repeated across high-consequence outputs and driven by Collaboration Contract mode, transforms opacity into contestable transparency without creating chain-of-thought theatre.

See what a summary leaves out and contestability.

Read next: Intelligence over aesthetics.