Two Artifacts to Build Next — Correction Lineage and the Inference Conflict Surface

Track A — Correction Lineage

Why this, now

Juno, the timing on this one comes from outside your portfolio. Two production AI platforms published their correction mechanisms in recent months: Presence, with an evidence-to-rollout pipeline for agent behavior changes, and Vercel, with a weekly evidence-intake workflow that separates collection from judgment from deployment. Both are real systems handling corrections at scale, and both run three distinct events through one governed process without separating the claims those events make.

Which is the general condition. Every AI interface that accepts user corrections shows "corrected" as a single state. The user cannot see whether the system recorded the correction, whether the system changed its behavior, or whether the changed behavior produced better results. That's three claims with three proof standards collapsed into one badge.

CarrierIQ is already most of the way to closing this. The live workbench proves that evidence was reviewed, a verification run occurred, an operator left a note, and a bind was approved. What it cannot prove is what happened after an operator disputed a result. Issue #6 established that a correction is an event, not an edit. Issue #7 named the gap. Build the thing that fills it.

What you already have

Nine elements on the live surface serve as starting points. What each does now, and where it goes.

Structured intake rail. The left rail captures profile, driver history, coverage, and carrier selections before execution. Keep it as the original intent record. When an operator disputes an extracted value, the correction has to point back to the exact requested field in this rail. A correction that floats without reference to what was originally asked for can't be evaluated by anyone downstream.

Per-carrier trace. Completed results expand into ordered agent messages with timestamps and the final extracted quote. The trace is evidence for the first claim and nothing more: it proves what the system did. Use it to identify the specific extraction being challenged and bind the correction to that observation.

Coverage detail and deltas. The review drawer lists returned coverage values and highlights deltas. Make the disputed field the entry point for a correction — immutable original value, asserted correct value, evidence attachment, correction author, timestamp, proposed correction scope.

Four review states. Completed results route as Bindable, Normalize, Referral, or Call review. These stay as operational routing. Do not add "Corrected" as a fifth badge. That collapses the three claims back into one, which is the failure the whole artifact exists to demonstrate.

Case File Checklist. Carriers supply checklist items the operator verifies before approving a bind. Extend it into a correction lineage manifest:

• Dispute evidence present
• Correction authority established
• Change object versioned
• Comparison test completed
• Rollout decision recorded
• Later-run evidence attached

Each item independently checkable.

Carrier Verification panel. Currently distinguishes active from completed agent sessions, shows proof attachments (Browser Use or Mock) and no-verification states, and provides verify, re-run, live-view, and follow-up prompt controls. Reuse this panel three times, once per claim, with a different proof contract each time. Note the limit of the existing control: a re-run establishes fresh carrier evidence, and fresh evidence says nothing about whether a system change caused it.

Operator Note. Free text where the operator records rationale, disabled after approval. Retain the free text. Add two structured fields — correction scope (this output only, this account, this workflow, this carrier integration, or global) and correction authority (who can approve a change at that scope).

Approval gate. The Approve Bind button stays disabled until the market snapshot and selected quote are complete. Split it into three gates: approval of the case outcome, approval of a proposed system change, approval of rollout. None of the three should assert that later behavior improved. That is a separate evidentiary question with a separate timeline.

Parallel staged execution and market-level progress. Running carrier rows show five stage pills (Session, Navigate, Fill, Extract, Verify), elapsed time, and a percentage bar. The aggregate workbench tracks completed, running, and queued carriers as a ratio. Replace both with the reversibility frontier below.

Three claims, kept separate

Keep these visually and structurally separate all the way through.

Claim 1: Receipt. The system recorded that a correction was initiated. Required elements:

• Disputed field identifier
• Original extracted value (immutable)
• Proposed correct value
• Evidence reference
• Actor identity
• Timestamp
• Authority level
• Scope declaration

Receipt is provable from a durable event record alone.

Claim 2: Incorporation. The correction entered a governed change process and altered a specific deployed behavior. Required elements:

• What changed (prompt, policy, extraction rule, evaluation criterion, memory entry, source-reliability weight)
• Where it applies (scope)
• Prior version
• Proposed version
• Evaluation state
• Rollout state
• Rollback availability

Incorporation requires a versioned change object. A correction that was received but never incorporated should be visible as exactly that. The gap between receipt and incorporation is the most useful thing on the screen: it tells the operator whether their feedback reached the system's behavior or only its logs.

Claim 3: Verified improvement. The changed behavior produced measurably better results on comparable later inputs. Required elements:

• Predefined evaluation conditions
• Comparison with the prior version on matched inputs
• Later-run evidence
• Visible adjacent regressions or failed checks

One successful later run does not clear this bar. Show what was tested, what improved, what regressed, and what went unmeasured.

Each claim gets its own visual state — not established, pending, established, disputed — its own evidence container, its own timestamp. The states are independent. Receipt without incorporation is a normal condition, and so is incorporation without verified improvement.

Ground the reasoning in production agent trace work at TinyFish, where the three questions come apart on contact. A trace proves the run happened. When an operator flags a bad extraction, the trace cannot tell you whether the correction reached the agent's next run, whether the agent's behavior changed, or whether the change helped. Each answer arrives from different evidence at a different time. The artifact turns that sequencing into interface structure.

Reversibility frontier

The current progress model counts completed work. Replace it with a representation of remaining flexibility.

At the moment an operator initiates a correction, optionality is at maximum. Scope can be narrowed or widened. The proposed change can be revised. Evaluation criteria can still be set. As the correction propagates from receipt through incorporation through rollout, options close: intake becomes immutable, the change object gets versioned and tested, the rollout reaches production. Each step reduces what can still be undone.

Make that closing the primary progress signal. The indicator starts full and narrows as propagation proceeds. At zero remaining flexibility the correction is fully propagated, and only a new correction event can alter the state.

The mechanics come from rollback experience with agent systems at TinyFish. Past certain checkpoints — a prompt version ships, an evaluation baseline resets, a downstream system consumes the new output — reversal stops being a button and becomes a new correction carrying its own evidence burden. The frontier puts that cost in front of the operator before they cross each threshold rather than after.

The Trust essay's In-Progress handoff argues against spinners and for visible steps that let users build a working model of system activity. This is one implementation of that: the working model the user builds is of what they can still influence.

Where this maps in the Trust essay

Track A spans three handoffs.

Output Review is where the correction starts — the operator identifies a disputed result against its evidence. Claim 1 gets established here.

Decision Gate is where the correction acquires authority and scope. Someone decides whether a proposed system change may proceed, at what scope, against what evaluation criteria. Claim 2 gets its approval here.

Loop Feedback carries Claim 3. The essay's warning that one loop's output becomes the next loop's input, and that small misclassifications compound, is the reason verified improvement has to be legible across versions and later runs.

Two more handoffs supply supporting structure. Intent-Setting provides the original contract that makes an extracted result contestable in the first place. In-Progress provides the propagation model the reversibility frontier depends on.

Presence and Vercel as precedent

Presence is the strongest published precedent for the receipt-to-incorporation path. The sequence they describe: production sessions reveal gaps, quality signals identify where the agent needs attention, Codex investigates and suggests updates, teams test proposed changes against the current production version, a team approves controlled rollout. Cite it for the middle of the chain only. They do not publish a user-facing correction-receipt interface, required sample sizes for improvement claims, or a rollback UI, and you shouldn't imply otherwise.

Vercel's design-agent workflow gives you the sharper separation of proof. Their weekly intake: a collector gathers messages and context without proposing rules, a judge groups and verifies, the output is a review packet with candidates, rejections, and gaps. Every candidate stays pending until a human decides whether it becomes guidance, a lint rule, an example, an evaluation, or nothing. Accepted changes pass checks before merge. They test with holdouts and no-skill baselines to measure whether the guidance actually changed agent behavior. That last part maps cleanly onto the three claims — evidence collected is receipt, candidate accepted and merged is incorporation, holdout and baseline testing is verified improvement.

Artifact type

Annotated interaction model with state diagram. The interaction model carries the correction flow from disputed field through the three claims. The state diagram carries the independent claim states and the reversibility frontier. Annotate each state with the CarrierIQ element it extends and the Trust essay handoff it maps to.

Track B — Inference-Aware Decision Surfaces

Why this domain, now

Juno, the inference market this week offers at least fourteen distinct price-speed-capability combinations across three providers. OpenAI's Sol sits at $4/$20 promotional through November 21, with effort levels from none to max, a Fast mode at 2x price for 2.5x speed, and Ultrafast in limited preview at up to 14x speed with no published price at all. Gemini 3.7 Flash runs $0.75/$3.75 through December 31 and doubles January 1; Flex costs half as much with 1–15 minute latency, Priority costs 1.8x for lower latency. Anthropic Opus 5 is $5/$25 with effort levels from low to max and a Fast mode at $10/$50 for 2.5x speed.

Navigating that requires an ML engineer, and even then the parameters are provider abstractions. Effort level, service tier, token pricing — none of it maps to what a product designer building an inference-powered feature actually needs to decide. The designer's question is whether this call can cost more than two cents, whether it can take longer than three seconds, and whether it can be wrong more than one time in ten. Then: which options clear all three, and what to give up when nothing does.

Core design idea

The user specifies consequences. The system handles parameters. Three constraint types:

• Cost ceiling. Maximum acceptable cost per call, per session, or per period. Denominated in the user's unit of account, not tokens.
• Acceptable delay. Maximum time from request to usable response, including network, queuing, and processing — not model latency alone.
• Minimum reliability. Acceptable rate of correct, usable responses for this task type.

Reliability is the hard one, and the reason it's hard is that the product has to define it. Google's "reliability" refers to service availability and queue priority. Anthropic's effort levels describe reasoning behavior. Neither measures whether the answer is right. So the constraint has to be grounded in the product's own evaluation evidence, and when that evidence doesn't exist the interface has to say so out loud. Show an explicit "no evaluation data" state on the reliability axis and offer two paths: supply evaluation results to populate the constraint, or mark reliability as movable, which tells the system to optimize cost and delay with no correctness guarantee attached. Design the empty column deliberately. It will be the most common state in year one.

Every constraint carries a hard or movable flag. The system maps available inference options against all three and returns one of three results: all constraints satisfiable, satisfiable with tradeoffs on movable constraints, or unsatisfiable.

The conflict surface

Concentrate the design hours here. Four conflicts drawn from current pricing:

A cost ceiling set to fit Gemini Flash's introductory price breaks on January 1 when the price doubles, with no change to the workflow. The interface has to surface that satisfiability decays on a calendar.

Sub-second response at minimum cost is structurally unsatisfiable. Flex is the cheapest Google option and targets 1–15 minute latency. No tuning closes that.

Maximum reasoning quality under a strict per-call cost cap produces a probabilistic ceiling rather than a deterministic one. Both OpenAI and Anthropic define higher effort as permission to spend more reasoning resources, and token consumption varies per call.

Fastest available inference points at Ultrafast, which advertises 750 tokens per second, sits in limited preview, and has no public price. The option exists and cannot be evaluated against a cost constraint at all — a fourth state the panel needs to represent.

In every conflict, show which constraint is blocking, what the nearest satisfying option costs in additional money, additional delay, or reduced reliability, and which movable constraints would have to shift to reach a satisfiable state.

Artifact type and structural direction

Annotated interaction exploration. Show the constraint-specification surface — three inputs, hard/movable toggle on each — the mapping to available options, and the three result states. Give the conflict panel the most attention. Include the Gemini January 1 change as the time-decay example, since it demonstrates satisfiability shifting without any user action.

This is a domain opener. The rest of the Inference-Aware UX queue — provider-switching logic, fallback chains, evaluation-driven reliability scoring — depends on the constraint-specification pattern and the conflict surface existing first. Build those two.