Build Queue — Routing Visibility and Governance Specs

The design problem

When a user sends a prompt to an AI product, the system chooses which model handles it. That choice involves real tradeoffs: cost against reasoning depth, speed against reliability, token budget against answer quality. The user doesn't see any of them.

Claude now exposes five effort levels. Gemini offers Standard, Extended, and Deep Think. In ChatGPT, GPT-5.6 Sol's thinking slider is one control and GPT-6 Pro is a separate model choice. And in August, Stripe agreed to acquire OpenRouter, which puts routing infrastructure inside a payments company whose announcement talks about "maximizing revenue and efficacy while minimizing token costs." The platform's economics, in the press release.

Every one of those is a visible control. None of them tells the user what the routing choice bought, or who it favored.

Issue 11 deferred the Inference Conflict Surface until inference cost became a user-facing choice in a shipped application. That condition is now met.

Two specs follow. Track A extends Brand Pulse's existing source-attribution pattern into a routing visibility surface. Track B creates a new decision flow governing model selection. Build Track A first. It establishes the visual vocabulary that Track B's terminal nodes reference.

Track A — Routing Visibility Surface

The existing pattern

Brand Pulse's Sentiment & Sources section has a BY PLATFORM area: one horizontal row per active source, each carrying a source-colored dot, the source name, a stacked bar splitting signals into positive/neutral/negative, a signal count, and a percentage of total. The left rail holds a separate AGENT TRACE listing per-agent events with status dots, event types, messages, and elapsed time. The signal cards in the middle column carry source-colored dots and sentiment labels, but nothing about which model produced them, how confident it was, or what the run cost.

So source-level information sits in three regions and never gets joined. The BY PLATFORM row reports contribution and sentiment composition. It says nothing about source quality, model identity, or routing rationale. Issue 9's Delegation Envelope spec proposed extending that row with expected-versus-actual contribution and model changes between runs. This spec continues that line.

What the extension adds

Each BY PLATFORM row becomes a route row. It keeps everything it currently has and gains five attributes.

Model identifier. The name of the model that processed this source's signals. Text label, not a logo. When the model changes between runs, show the previous name in a muted secondary style beneath the current one.

Reasoning effort. The effort level the system selected for this route, in the provider's own vocabulary — Low/Medium/High/Extra high/Max for Claude, the five-level scale for Astra. Most users will read this attribute first, because the consumer products have already trained them to look for it.

Latency. Elapsed time for this route's processing, in seconds. Measured, not estimated. Right-aligned, inline. While the mission is running, show a live counter that freezes on completion — an elapsed count rather than an indeterminate spinner, because duration is the thing the user needs to be able to read. This is Handoff 02 from the Trust essay: confidence forms through visibility into what the system is doing and how long it has been doing it.

Cost indicator. Relative, not absolute. Three tiers — low, medium, high — rather than dollar amounts. Per-token pricing varies by provider, cache state, context length, and service tier in ways that make raw numbers misleading at the user level. The tiers map to whether the route used a cost-optimized path (batch, cached, low-effort), a standard path, or a premium path (fast mode, high effort, long context).

Verification burden. How much human review this route's output warrants. Three labels:

• Review — check the output before acting on it
• Spot-check — sample a few items
• Accept — routine enough to act on directly

These map to the Trust essay's Watch/Verify/Delegate postures, scoped to this route and this run. That follows the task-scoped interpretation in the Design Context File: the same user may accept one route's output while reviewing another's.

Classify on downstream coupling. Does the output enter a workflow without a human looking at it? If it triggers an action — sends a message, updates a record, feeds another agent — the default is Review. If it's presented for a human decision, Spot-check. If it's exploratory or informational with nothing depending on it, Accept. Track B systematizes this later by tying the same classification to stakes and reversibility, but in Track A it has to work on its own, because the routing surface ships first.

Information hierarchy

Default row state shows five elements: source dot, source name, model identifier, reasoning effort, latency. Those fit one horizontal row without scrolling.

Cost indicator and verification burden appear on hover or tap, in a secondary line beneath the row. Most people checking the routing surface want to know which model handled the request and how hard it thought. Cost and verification burden matter to power users and to governance review, but showing all seven attributes at once turns the row into a data table.

The expanded state — click or tap the row — shows that route's full agent trace, pulled from the left rail's existing AGENT TRACE data. This collapses the current three-region split into one expandable surface per route.

Placement

Where BY PLATFORM currently sits, inside the right column's Sentiment & Sources section. Enriched route rows replace the existing rows, visible by default in their collapsed single-line state. The aggregate sentiment donut above stays as it is. Don't create a new panel.

Production grounding

TinyFish's constraint-first architecture routed on cost ceilings and latency budgets per agent. Model, effort, latency, cost tier, and verification burden are the variables that determined whether a routing call met its constraints or blew through them in production. You already tracked all five operationally. The artifact makes them visible to the user.

Company mapping

This one addresses the trust-architecture problem: users acting on AI output without enough evidence about how that output was produced.

Strongest fit. Anthropic, where Claude's effort controls exist without any routing rationale attached (high confidence — observable in the shipped product). Google, where Gemini's Standard/Extended/Deep Think labels sit on top of an API using different vocabulary and different pricing (high confidence — the mismatch is documented). Any company building on OpenRouter or comparable infrastructure, where model selection happens behind the API boundary (high confidence — Stripe's announcement language confirms routing economics are the product). Notion, Figma, Canva and the rest of the enterprise AI platform tier, where the user never picks the model and may not know which one answered (moderate confidence — inferred from product behavior, not from any hiring-side signal I can confirm).

Why it lands. It shows you've worked through the information hierarchy problem every multi-model product has and most are still deferring. The default/hover/expanded split is the decision these companies need someone to make.

Build complexity

Moderate. The visual foundation exists. The work is the enriched row, the hover and expanded states, and the hierarchy between them. The hardest call is calibrating the verification burden label so the downstream-coupling rule produces classifications that feel right to users who never read the rule. Test it against Brand Pulse's own routes. Does the Reddit agent's output, which feeds the synthesis, warrant Review or Spot-check? That depends on whether the synthesis is the terminal output or whether the user acts on individual signal cards. That ambiguity is where the design difficulty sits.

Track B — Routing Governance Flow

The decision problem

Track A makes routing visible after the system has already chosen. Track B is the prior question: how should the system decide, and whose interest governs the decision?

Three variables drive it. Stakes — what happens if the output is wrong. Reversibility — whether the user can undo or correct the outcome. User tolerance — willingness to accept more delay or cost for a better answer. Issue 8's Inference Conflict Surface specified these as constraint parameters with hard or movable designations. This spec inherits that grammar and adds what Issue 8 left out: whose objective the routing serves.

The objective layer

When a system routes a request to a cheaper, faster model, one of three objectives explains it:

• User's objective. The user wants speed over depth for this task.
• Platform's objective. The platform is optimizing margin. Stripe's OpenRouter framing says so out loud.
• Negotiated default. Plan tier, workspace settings, or prior preferences establish a routing policy.

The rest of the artifact is structure around that.

Visual structure

Use a decision flow, not a matrix. The routing decision is sequential — stakes get classified before reversibility is assessed, and both precede the tolerance check. A matrix flattens that sequence into a lookup table. Lookup tables are fine for reference documentation, but the branching logic is the thing that needs to be inspectable here.

Structure it as a vertical flow with three horizontal bands, read top to bottom. Each band is a branching stage.

Band layout. Each band spans the full width. A stage label sits on the left edge: Stakes, Reversibility, Tolerance & Objective. The band holds one or more classification nodes — rounded rectangles containing the branching question — with connector lines descending to the next band.

Branch visualization. At each classification node, two paths diverge, left and right. Connectors run vertically from the node's bottom edge to the top edge of the nodes below. The Consequential path uses a heavier connector weight than the Routine path. Make that weight difference legible before any label is read; it's the primary signal that stakes are escalating.

Terminal nodes. The four endpoints at the bottom are bordered cards. Each contains, top to bottom:

1. Model tier ("Highest-capability model," "Cost-optimized model")
2. Effort level ("Maximum reasoning," "Low effort")
3. Objective label ("User" / "Negotiated" / "Platform")
4. Verification burden label ("Review" / "Spot-check" / "Accept")
5. Override affordance — a text link or small button

Terminal cards on the Consequential side carry heavier border weight than those on the Routine side, so the connector weight system continues into the endpoints.

Objective label treatment. Distinguish the three states with background fill. "User" gets no fill; it's the expected default and shouldn't pull the eye. "Negotiated" gets a light neutral fill. "Platform" gets a distinct fill, visible but not alarming. That fill carries the disclosure, so calibrate it to read as a fact about the system rather than a complaint about it.

Branching logic

Stage 1: Stakes classification. Two branches. Consequential covers financial, medical, legal, or reputational impact if the output is wrong. Routine covers informational and exploratory work with low impact. Classification can be automatic — task type, workspace context, prompt analysis — or user-declared. Show which method was used.

Stage 2: Reversibility assessment. Two branches per stakes level. Reversible means the output can be edited, retried, or discarded before it affects anything downstream. Committed means it triggers an action, sends a message, updates a record, or informs a decision that's hard to walk back.

Stage 3: Tolerance and objective resolution. For each combination, show the default routing policy and name the governing objective.

• Consequential + committed. Highest-capability model, maximum reasoning effort. Governing objective: user's. The system should not cost-optimize here regardless of plan tier. Verification burden: Review.
• Consequential + reversible. High-capability model, standard effort. Governing objective: negotiated — plan tier may constrain the model, but the user can override. Verification burden: Spot-check.
• Routine + committed. Standard model, standard effort. Governing objective: negotiated. Verification burden: Spot-check. This is where silent cost optimization most often operates unnoticed (moderate confidence — inferred from TinyFish production patterns where automated agent chains defaulted to cost-optimized routes, and from Stripe's announcement language prioritizing token-cost minimization; not confirmed by published usage data from any consumer AI product).
• Routine + reversible. Cost-optimized model, low effort. Governing objective: platform's, unless the user overrides. Verification burden: Accept.

The override mechanism

Every terminal node includes an override affordance. The user can promote a routine task to consequential treatment, or accept a lower-capability route for a consequential one. The override switches the governing objective to User and logs the change. That's the Trust essay's Decision Gate applied to routing: consequential, irreversible outcomes keep a human decision point even when the system has a default.

Production grounding

TinyFish enforced cost ceilings per agent and required fallback paths when a preferred model was unavailable or over budget. The branching logic here mirrors the sequence you actually built: classify the task, assess what happens if the output is wrong, check whether the budget allows the preferred route, fall back with disclosure if it doesn't. At TinyFish that logic was invisible to the end user. This artifact makes it the product surface.

Company mapping

This one addresses trust architecture and agent-workflow orchestration together — multiple actors coordinating incoherently even when each individual capability works.

Strongest fit. Infrastructure companies where routing is the product. Stripe/OpenRouter, where this flow could become a developer-facing configuration surface (high confidence — the acquisition announcement describes the exact problem the artifact governs). Enterprise AI platforms carrying compliance requirements in financial services, healthcare, and legal tech (moderate confidence — inferred from regulatory patterns around algorithmic decision-making, not from confirmed hiring signals at named companies). Any company running multiple models that needs a principled answer to when inference spend is justified (high confidence on the need; moderate confidence on whether specific companies have reached the point of designing for it rather than deferring it).

Why it lands. The objective label is what separates this from other routing interfaces. Most treat model selection as a technical parameter. This treats it as a governance question — who benefits from this routing decision — which is what product leaders at these companies are beginning to ask internally and haven't yet seen designed for.

Build complexity

Heavy. New artifact, no existing visual foundation. Three branching stages, four terminal states with defined card structure, an objective-labeling system with three fill treatments, override affordances at each endpoint. Two hard design problems sit inside it.

The objective label. Making "Platform" visible without making it feel like an accusation requires precise calibration of the fill. Too close to the background and users miss the disclosure entirely. Too saturated and it reads as commentary on the business model. Test all three labels side by side; the visual distance between "User" and "Platform" should be noticeable without being dramatic.

The stakes classification. Automatic classification has to be transparent about its own confidence. User-declared classification has to be fast enough that people don't skip it. Add friction at that step and users will default everything to routine, and the flow collapses into a single path.

Build order

Track A first, Track B second. Track A shows what the system did; Track B governs what it should do. The verification burden label is what they share, which is why it has to be settled in Track A before Track B can reference it.