Delegation Envelope — Three Artifact Specifications

Build these in order. Each extends a live element from CarrierIQ or Brand Pulse into a problem your portfolio doesn't currently address. The three together make one argument legible: confidence and authority are separate controls, and a delegation system has to keep them separate — at the moment authority is granted, while the agent is working, when the user pulls it back, and across runs when conditions change underneath.

The Design Context File carries the reframing of the Trust essay's five handoffs and the trust ladder. Assume it's open in another tab; I'm not restating it. Shorthand for what follows: the five handoffs (Intent-Setting, In-Progress, Output Review, Decision Gate, Loop Feedback) mark where trust transfers. Watch, Verify, Delegate marks how far the user has extended it. These specs operationalize both.

Artifact 1 — The Confidence/Authority Matrix

Domain: Inference-Aware UX

CarrierIQ already separates confidence from authority. The separation is implicit, which means a hiring committee scanning your portfolio for evidence that you've thought about it will not find any.

The structured intake rail records what the user authorized: liability limits, deductible preferences, coverage selections, which carriers to query. The review drawer reports what the system found: returned quotes, coverage deltas, review states like Bindable or Referral, carrier trust signals. Two surfaces, two dimensions, but no single element that places them side by side and makes their independence explicit.

A carrier can return a high-confidence result for something the user never authorized. A user can authorize broad coverage while the system has low confidence in what it extracted. The matrix makes both conditions visible at once.

Visual structure

Two axes. Vertical: authority, drawn from the intake rail's five field groups (Profile, Driver History, Coverage, Carriers, Launch). Horizontal: confidence, the system's own assessment of how complete and reliable its output is for each authorized dimension.

Every authorized coverage dimension — liability, deductible, roadside, rental — gets a horizontal fill indicator showing how much of the expected data the system extracted and verified. Aggregate confidence for a carrier is the lowest individual dimension, not the average. A carrier with perfect liability extraction and failed roadside extraction is as uncertain as its worst dimension, because the approval decision covers the whole quote.

The four review states already in production — Bindable, Normalize, Referral, Call review — should map to aggregate confidence thresholds. Proposed: Bindable requires every authorized dimension above ~90% extraction completeness. Normalize means all dimensions extracted with at least one needing manual verification (~70–89%). Referral means at least one dimension couldn't be reliably extracted (~40–69%). Call review means extraction failed on a critical dimension (below ~40%). Tune the numbers however you like. The principle holds regardless: review states are confidence classifications, not authority classifications.

Four cell states:

Authorized / High confidence. The system was asked to do this and believes it did it well. User requested $100K/$300K liability; the returned quote matches, extraction complete. Default treatment, no flag.

Authorized / Low confidence. The system was asked and isn't sure it succeeded. User requested roadside assistance; the carrier's page didn't expose that field clearly and the extraction may be wrong. The coverage delta indicator already flags differences between requested and returned values. Extend it with a confidence qualifier — not just "different from requested" but "different, and uncertain whether the difference is real or an extraction failure."

Unauthorized / High confidence. The system found something it's sure about that nobody asked for. A carrier returned a bundled renters quote. Separate this visually from authorized results. Present as discovered information, not as evaluated output.

Unauthorized / Low confidence. Outside the mandate, uncertain about it. Suppress from the primary view, available on expansion.

Three decisions that matter

Authority is set at delegation time and doesn't drift. The intake rail is the source of truth. If the system needs to act outside the user's stated boundaries, that's a new delegation request, not a wider interpretation of the old one.

Confidence is continuous. The case-study description promises a completeness-derived confidence score; the live application doesn't display one yet. This spec defines what that score communicates — per-dimension confidence, meaning "for each thing you asked me to do, how sure am I that I did it" — rather than a single aggregate number the operator has to interpret blind.

The Approval gate ("Approve Bind") currently activates when both the selected carrier and the overall market run are complete. Add a second condition: every authorized dimension must have a visible confidence assessment before the gate unlocks. Completeness of execution is necessary. Completeness of confidence disclosure is also necessary.

Trust essay mapping: Output Review and Decision Gate. Confidence belongs to Output Review — what did the system find, how certain is it. Authority belongs to Decision Gate — does the operator have enough context to approve a consequential action. The matrix holds both in one view because the approval decision requires both assessments at the same moment.

Where this lands: Headway's Staff Product Designer posting asks designers to define "trust signals" and "automation boundaries," and to specify what happens when the AI is "uncertain or wrong" while acting on a provider's behalf with a real patient on the other end. That's three-party delegation, and the posting language already tangles confidence with authority. This artifact shows you can separate them.

Artifact 2 — The Revocation Sequence

Domain: Human-Agent System Design

The user granted authority. The agent is mid-task with live sessions against external carriers. Then something changes — a coverage delta shifts the risk calculus, or they entered the wrong VIN, or the run is simply moot now. They need to revoke authority after the agent has already made external commitments it can't unilaterally undo.

Build this backward from the terminal state.

What the protocol actually gives you

Cooperative cancellation in the Model Context Protocol works like this: the client sends tasks/cancel with a task ID. The server returns an empty acknowledgement confirming the request arrived. It does not confirm that work stopped. The task may still reach completed, failed, or cancelled. There's no protocol status for "cancel requested, still unwinding" or "partially completed." The client polls until it learns what happened.

The protocol hands you an acknowledgement and nothing else. Everything between "I want to stop" and "here's what actually stopped" is application-level design, and that gap is the artifact.

Phase 1: Pre-revocation disclosure

This is what should have been visible all along, before cancellation became necessary.

Extend CarrierIQ's parallel execution display — the per-carrier rows showing Session, Navigate, Fill, Extract, Verify. Those currently show progress. Add a commitment state layer. For each carrier, surface whether the agent has:

• Only read information (no external effect, fully recoverable)
• Submitted form data to a carrier's system (the carrier now holds the user's information regardless of what happens next)
• Received a binding quote (the carrier may treat this as an application)
• Initiated a bind (irreversible without carrier-side intervention)

Show this during normal execution, not only at cancellation. The user should always know which carriers have received their data and which are still read-only. The Carrier Verification section already shows active and completed session status plus a live-session link. Extend it with per-stage commitment-state indicators.

Phase 2: The revocation interaction

The system can't promise immediate termination, so design for that honestly.

Acknowledge immediately, with the current commitment state of every active carrier. No confirmation dialog. The user has decided. Show them what's already happened.

Then triage per carrier, grouped by commitment state:

• Read-only sessions — abandon cleanly
• Data submitted — session can be terminated, submission cannot be reversed
• Quote or bind in progress — may complete before cancellation takes effect

For anything in the second or third group, surface residual obligations: what the user may need to do independently. Contact the carrier to withdraw an application. Confirm a bind did not complete. Verify how submitted data will be handled.

Phase 3: Post-revocation state

The system does not return to "before the run." It returns to a state that acknowledges partial execution. The Case File Checklist and Operator Note fields become the record of what happened and why it stopped. Completed carrier results stay visible with their review states. Cancelled carrier rows show their last known commitment state and whether cancellation was confirmed by the carrier session or only requested.

The approval gate stays permanently disabled for a cancelled run. A new run can be started, but it inherits the commitment history — the system knows which carriers already hold this user's data. The prior Track A spec established the three-claim correction record: what the system produced, what the operator changed, what the next run inherited. A cancelled run is a special case of that record, where the operator's correction was "stop everything" and the inheritance is the commitment history.

Trust essay mapping: In-Progress and Decision Gate. Commitment state is In-Progress — what has the agent already done to the outside world. Revocation is a Decision Gate — the user is making a consequential, partially irreversible decision to stop.

Where this lands: Headway again, and harder. In a three-party system, revocation has consequences for someone who isn't the person pressing cancel. The patient on the other end of the AI scheduling assistant has no idea the provider just pulled the agent's authority.

Artifact 3 — Contract-Variance Disclosure

Domain: Agent Infrastructure as UX

Brand Pulse hasn't had Track A treatment yet. This is that.

The delegation problem here runs across time rather than within a single task. You specified a brand, competitors, focus areas, and intelligence sources — Reddit, X. You launched. The system ran parallel agents and returned signal cards with source labels, sentiment, and AI-generated conclusions backed by displayed quotations. You made decisions on those results.

Next run, something has moved. A source API rate-limited the agent, so 80% of signals came from Reddit and 5% from X instead of the balanced split you saw last time. Or model routing shifted to a cheaper tier with different classification accuracy. Or a new source became available that wasn't part of your original delegation. The output looks identical — signal cards, sentiment scores, conclusions — while the conditions that produced it have changed from the ones you authorized.

The existing element to extend

The Sentiment & Sources panel already separates source-agent contribution, showing how many signals came from each source and what percentage of the total that represents. It answers "where did this result come from." The extension answers "is that different from where you expected it to come from, and does the difference matter."

Visual structure

Add a variance layer to the panel. Per source-agent: expected contribution based on the baseline run, actual contribution this run, and the delta between them against a materiality threshold. A 55/45 split when you expected 50/50 is noise. A 90/10 split changes what the results mean.

When a material variance appears, surface it twice. At the panel level, a variance indicator the user sees before reading any conclusions. At the card level, individual signals from the underrepresented source get a scarcity flag — if three signals came from X where the baseline returned forty, those three carry disproportionate weight in any X-specific conclusion, and the user needs to see that before they weight it themselves.

Three variance categories beyond source balance

Route variance. A source was selected but returned nothing, or was unavailable. The agent trace already shows per-source status. Extend it with an explicit "source unavailable — results reflect remaining sources only" disclosure when a selected source fails outright.

Model variance. The classification or generation model changed between runs. If sentiment labels came from a different model than the baseline's, the scores aren't directly comparable. Surface a version indicator per run — not the model name, but enough that cross-run comparison stays honest.

Capability variance. A capability was added or removed between runs. If the system now extracts entity relationships it didn't extract before, the competitive snapshot may look different for structural reasons rather than because the landscape moved. Flag new capabilities on their first run.

Four decisions

Variance disclosure comes before conclusions. The AI-generated conclusions are the highest-value output on the page. If the conditions producing them shifted, the user has to know before reading. Place the variance indicator above the conclusions section, or inline as a qualifier on the conclusions that depend on the affected source.

The first run sets the baseline. Whatever sources, models, and capabilities were active on the user's first delegated run become the reference point. Measure variance against that, not against the previous run. A rolling baseline drifts toward whatever the system happens to be doing and quietly erodes the disclosure into noise. An anchored baseline goes stale instead, so when cumulative variance across runs crosses a threshold, prompt for re-baselining: your reference point is N runs old, conditions have shifted materially M times since, reset? The user has to actively accept the new baseline. That acceptance is the point — without it, drift happens without anyone agreeing to it.

The system sets materiality thresholds. Asking the user to define what counts as material variance asks them to do the system's job. Err toward disclosure.

Variance is not failure. A run with material variance can still produce valid results. The disclosure is informational; the user decides whether it matters for their decision. The system's obligation ends at making sure they know it happened.

Trust essay mapping: Loop Feedback — one run's output becoming a later run's input, letting small errors compound. Contract variance is how that compounding stays invisible. A user who doesn't know the conditions shifted can't recalibrate how much to trust the output.

Where this lands: Vanta's Director of Product Design posting asks for connected workflows across risks, assets, vendors, controls, and frameworks, with "trust, transparency, and responsible AI use" in AI-powered experiences. Same design problem: when a vendor's risk posture changes, or a control's underlying implementation shifts, the risk assessment the user approved no longer holds under the conditions they approved it under.

How These Connect

Artifact 1 sets the distinction. Artifacts 2 and 3 both assume it, which is why the order matters — build the matrix first or the other two have nothing to stand on. Artifact 2 tests the distinction at the point of maximum consequence, when the user withdraws authority from a system that has already touched the outside world. Artifact 3 tests it across time, when the terms of the original grant quietly change.

Together they show a hiring committee that you treat delegation as a design system with boundary conditions, failure modes, and drift — not as a set of confidence indicators bolted onto an output screen.