Previous issues organized artifacts by domain. Trust design in one bucket, AI-native execution in another, presentation in a third. That made sense for coverage. The question now is exposure: which claims does Juno's portfolio make that a skeptical evaluator cannot verify from what's currently published?
Every artifact below is ranked by how much damage its absence does to a specific assertion, given the Act-tier pipeline as of this week. The three highest-ranked pending artifacts get full first drafts at the end, written in Juno's voice, ready for screenshots and publication.
Disclosure classifications follow the Published Portfolio Boundary and its four-class expansion: Public, Controlled-interview, Verbal-context-only, Unavailable. No actual interview questions from Juno's screens are documented. Every "interview question" entry below is anticipated from posting vocabulary and hiring-panel patterns.
The queue contains six artifacts across four of the five evidence domains: Trust Design, AI-Native Execution, Design Patterns, and Presentation/Credibility. Design Iterations — before/after version evidence, A/B outcomes, documented revision history — is the unrepresented domain. Nothing pending in that category is pipeline-critical this week, but the gap means the portfolio has no published iteration evidence beyond what appears inside individual case studies.
The Ranked Queue
1. Carrier IQ Longitudinal Control Record
Claim it supports: Trust compounds across runs. An agent that extracted the wrong value in run 3 behaves differently in run 5 because the system recorded the correction, adjusted source weighting, and added a verification step.
Companies it unlocks: Gusto Head of Design names trust, uncertainty, graceful failure, and do-not-send. This artifact is direct evidence for all four. OpenAI Engineering Acceleration describes trace, evaluation, rollback — the correction chain is rollback designed into the product layer. Fieldguide asks for AI-assisted audit workflows and regulated complexity in an agentic context.
What a skeptical evaluator assumes without it: She built a review dashboard. The agent shows its work, the operator approves. Minimum viable human-in-the-loop. The panel writes "nice HITL pattern" in their notes and moves on. Where's the evidence that corrections change future behavior?
Interview question it answers: "Walk me through what happens after the system gets something wrong."
Build time: Needs new build. The public Carrier IQ app shows review states, coverage deltas, evidence sessions, and approval — but has no visible control for marking a value incorrect, recording a correction, or changing behavior in a subsequent run. The correction-to-next-run chain needs to be built into the app before screenshots can be taken.
Status: Pending. The Trust essay supplies the origin story (wrong row, wrong control, confident wrong result) but names no carrier, no value, no correction, no subsequent behavior.
Disclosure classification: Public once built. The underlying production observation is Verbal-context-only.
This is the highest-ranked artifact in the queue and the hardest to produce. Issue #6 ranked it first for the same reason and reached the same conclusion: the draft stays incomplete while its factual brackets stay open. The first draft below addresses this by publishing what IS built and naming what ISN'T, with design intent for the gap.
2. Trust Framework Revision Field Note
Claim it supports: The trust model is two independent controls — autonomy scope (what the agent does without asking) and intervention sensitivity (how fast the operator catches a problem) — that move separately. The published ladder (Watch → Verify → Delegate) treats trust as one variable that increases. Production broke that model.
Companies it unlocks: Gusto — trust framework directly relevant to their service-platform context. OpenAI Payments — financial authority requires distinguishing confidence from authorization, the exact separation this revision makes. Vanta — trust and compliance.
What a skeptical evaluator assumes without it: The trust essay describes a clean linear progression that reads like a conference talk. Has she tested this model against real operator behavior, or is this a framework she drew on a whiteboard?
Interview question it answers: "How do you decide what level of autonomy to give an AI system?"
Build time: Writing-only. A complete editorial draft exists in prior Playbook work. The live Trust essay still presents Watch → Verify → Delegate unchanged. The Design Context File already marks the single-axis ladder as retired internally.
Status: Complete editorial draft, not published on junochen.com.
Disclosure classification: Public. The production observation that motivated the revision (an experienced operator interrupting faster with fewer gates than a newer operator with more gates) is Verbal-context-only and should motivate the revision without being cited as named evidence.
The editorial draft is done. Add two screenshots from the existing Carrier IQ review surface and ship it as a field note on junochen.com. This is the fastest way to strengthen the Gusto and OpenAI Payments conversations.
3. Permissioned-Action Surface Annotation
Claim it supports: I design the information hierarchy of the moment where a human decides whether an agent's output goes forward. What's foregrounded, what requires a click, what's withheld from the default view — and why those choices matter more than whether the system has an approve button.
Companies it unlocks: OpenAI Engineering Acceleration — rollback is rejection at the action boundary. Gusto — do-not-send is rejection with consequence. Giga — non-determinism, zero-to-one. Google's People + AI Guidebook and Nielsen Norman Group's emerging AI-UX work both frame the human review moment as a design problem distinct from the model problem, but neither offers component-level examples from production agent systems. This artifact would be one of the few published practitioner accounts of a specific review-surface hierarchy in a live agentic product.
What a skeptical evaluator assumes without it: The agent has an approve button. Every AI product has an approve button. The evaluator wants to know whether the operator can actually intervene when they disagree, or whether the surface trains them to wave things through.
Interview question it answers: "What information does the user need to make a good decision about AI-generated output?"
Build time: Needs screenshots of existing Carrier IQ review states + writing. The review surface, coverage deltas, evidence sessions, and approval flow are live and screenshottable now. The rejection-to-correction flow is not built.
Status: Pending. Partially producible from current app state.
Disclosure classification: Public.
4. Confidence-Basis Component
Claim it supports: Confidence in this system means required-field completeness, not correctness. A complete extraction can still be wrong. The distinction matters because it changes what the operator is verifying.
Companies it unlocks: Gusto, OpenAI Engineering Acceleration, Fieldguide — any role where the posting mentions evaluation, accuracy, or trust signals. Google's PAIR research and Apple's Human Interface Guidelines for machine learning both address confidence display, but most published guidance stays at the principle level. A component-level account of how completeness and correctness diverge in a production system would answer the question these frameworks raise without resolving.
What a skeptical evaluator assumes without it: There's a confidence score, but what does it measure? Is this a number the model outputs, or did she design the basis for it?
Interview question it answers: "How do you communicate uncertainty to the user?"
Build time: Needs screenshots + writing. The Carrier IQ wrapper claims confidence from data completeness, and prior editorial work develops the rule and its failure modes. The current public app response doesn't expose a confidence or completeness value in its captured output.
Status: Partially addressed in editorial. Not demonstrable from current public app.
Disclosure classification: Public once the app exposes the value.
5. Agentic Component Patterns
Claim it supports: I have a transferable design vocabulary for agent interfaces — coverage-delta displays, evidence sessions, review states, approval records — that appears across different agent contexts. The Labs are a system, not four separate demos.
Companies it unlocks: All Act-tier roles. Practitioner publications — Lenny's Newsletter, design blogs from companies building agent products — are beginning to discuss what a pattern library for agentic interfaces would look like, but no widely cited component taxonomy has emerged. The hiring-manager commentary surfacing in design-leadership communities treats pattern transferability as a differentiator at this level: the question is whether your design decisions would hold in a second agent product. This artifact answers that with named, reusable components.
What a skeptical evaluator assumes without it: Four apps, four one-offs. The evaluator sees range but not system.
Interview question it answers: "How do you scale design decisions across multiple products?"
Build time: Needs screenshots from across Labs + writing. Drafted in issue #5 but not published.
Status: Editorial draft exists. Not published.
Disclosure classification: Public.
6. "How I Design AI Products" Process Narrative
Claim it supports: I ship AI products from zero, and I can describe how.
Companies it unlocks: Giga — zero-to-one, code. Fieldguide — regulated complexity, systemic patterns, AI-assisted workflows. OpenAI roles — AI-native execution.
What a skeptical evaluator assumes without it: She has live apps but no process story. Did she design these or assemble them?
Interview question it answers: "Tell me about your process for a recent zero-to-one product."
Build time: Writing-only. Drafted in issue #5. Not published.
Status: Editorial draft exists. Not published.
Disclosure classification: Public.
Three Publishable First Drafts
Written in Juno's voice. Screenshot insertion points are marked with bracketed descriptions. Each draft draws from Carrier IQ's public implementation as publishable evidence and production observations as technical context.
What Happens After the Agent Is Wrong
Domain: Trust Design × AI-Native Execution
The browser automation pointed at the right element on the insurer's portal, extracted the value from the adjacent cell instead of the target cell, and returned a coverage limit that was confidently, precisely incorrect. The confidence score — which reflects how many required fields the agent filled, not whether the values are right — was high. The value was wrong.
This is where most trust-in-AI conversations stop: the system can be wrong, so keep a human in the loop. I needed to design what "in the loop" actually means when the human has eight carrier results to compare and four seconds of attention per row.
[SCREENSHOT: Carrier IQ review surface showing a completed run with multiple carriers. The State Farm result is routed to Normalize with a coverage-delta flag visible.]
Carrier IQ extracts insurance quotes from carrier portals and compares them against a baseline the operator sets at intake. When a carrier's result deviates from the requested coverage — a $1,000 comprehensive deductible returned against a $500 request, rental coverage at $50/day instead of $40 — the system routes that result to one of four states: Bindable, Normalize, Referral, or Call review.
The routing is the first design decision that matters. A result with a coverage delta isn't wrong the way a hallucination is wrong. The carrier may not offer $500 comprehensive. The delta is real. But binding it without the operator's acknowledgment is an authority failure, not an accuracy failure. The operator didn't approve the substitution.
[SCREENSHOT: Coverage-delta detail for a single carrier, showing requested vs. returned values for each coverage line. The delta is highlighted.]
The review surface shows the operator three things at once: what was requested, what was returned, and where they differ. Each carrier result carries an evidence session — the extracted data, the source, the agent's step-by-step trace of how it arrived at each value. The approval record stores who approved, when, with what note, and which evidence session was open at the time.
[SCREENSHOT: Evidence session for a single carrier, showing agent steps, extracted values, and source reference.]
Here is what the current system does not yet show.
When the operator identifies a wrong value — not a coverage delta but an extraction error — there is no control to mark the specific field incorrect, record the correct value alongside the original, and feed that correction back into the system's behavior on the next run.
[SCREENSHOT NEEDED — not yet built: A correction control on a single extracted field, showing original value, operator-marked correct value, and a flag that routes this correction into source-reliability tracking.]
[SCREENSHOT NEEDED — not yet built: A subsequent run where the previously corrected source shows a verification step — the system re-checks the value it got wrong last time before routing the result.]
The design intent: a correction in run 3 changes what the system pays attention to in run 5. The source that produced the wrong value gets a reliability flag. The next extraction from that source triggers a targeted verification — the agent checks that specific field twice, or routes the result to human review regardless of whether the rest of the extraction looks clean.
Evidence at the moment of review: built. A record of what the operator decided and why: built. A mechanism that turns corrections into changed future behavior: not yet built. That third piece is what I'm building next.
Two Dials, Not Three Rungs
Domain: Trust Design
I built the trust ladder wrong.
The original version, still live in my Trust essay, describes trust as a three-stage progression: users watch the system, then verify its outputs, then delegate. Watch → Verify → Delegate. Clean. Wrong in a specific way I can now describe.
What I observed in production: an experienced operator working with minimal approval gates — high autonomy, few checkpoints — interrupted a run within seconds of spotting an anomalous extraction. A less experienced operator working with more gates — lower autonomy, more checkpoints — approved through every gate and caught the same category of error only at final output. More gates did not produce faster intervention. Fewer gates did not produce slower intervention. The variables were independent.
The ladder assumes trust is one thing that increases. It's two things that move separately.
Autonomy scope is what the agent is allowed to do without asking. A high-autonomy configuration lets the agent extract, compare, normalize, and route without human approval at each step. A low-autonomy configuration inserts approval gates between stages. This is a system-design decision, set before the run starts.
Intervention sensitivity is how quickly the operator detects a problem and acts on it. Shaped by experience, interface design, and what the review surface makes visible — but not controlled by gate count.
[SCREENSHOT: A 2×2 grid mapping autonomy scope (low to high, x-axis) against intervention sensitivity (low to high, y-axis). Four quadrants labeled: high autonomy + high sensitivity = experienced operator, efficient flow. High autonomy + low sensitivity = risk zone, errors pass through. Low autonomy + high sensitivity = friction without safety gain. Low autonomy + low sensitivity = the configuration most systems default to.]
The ladder model says: start low (Watch), move to medium (Verify), end high (Delegate). Sequential path, fixed destination. The two-dial model says: autonomy scope and intervention sensitivity are configured independently, and the right configuration depends on the operator, the task, and the consequence of a missed error.
In Carrier IQ, this changes how I think about the review surface. The question becomes what the review surface needs to show a given operator — given their intervention sensitivity — so they catch what matters.
[SCREENSHOT: Carrier IQ review surface annotated with two callouts: one marking an element that supports intervention sensitivity (the coverage-delta highlight that draws attention to the deviation), and one marking an element that reflects autonomy scope (the routing state that determines whether this result requires approval or proceeds automatically).]
The original essay described something real. People do watch before they verify, and they do eventually delegate. But the mechanism is two controls they adjust — sometimes in the same session, sometimes in opposite directions.
I'm revising the essay to reflect this. The original framing stays as the origin story. This note is the correction.
The Information Hierarchy of a Decision Moment
Domain: Trust Design × AI-Native Execution
The operator has three seconds. A State Farm quote came back with a $1,000 comprehensive deductible against a $500 request. The system routed it to Normalize. What does the operator see?
The default answer in most AI review surfaces: everything. The full extraction, the raw trace, the confidence indicators, the metadata, the action buttons — all visible at once, all competing for the same three seconds. The operator's job becomes finding the problem inside the information, which is a different task than evaluating the problem once found.
Carrier IQ makes a different bet. The review surface is layered, and the layers are ordered by the operator's decision path.
[SCREENSHOT: The Carrier IQ review surface for a single carrier result in Normalize state. Annotate three layers: (1) the routing state and coverage-delta summary visible by default, (2) the evidence-session expansion available on click, (3) the approval action at the bottom.]
Layer one is the deviation. The routing state — Normalize, Bindable, Referral, Call review — and the coverage delta are visible by default. The operator doesn't scan the extraction to discover that something is off. The interface tells them what's off and categorizes why. This layer earns or loses those three seconds. If the deviation isn't immediately legible, the operator either slows down (which doesn't scale across eight carriers) or approves without understanding (which transfers risk).
Layer two is the evidence. The agent's step trace, the extracted values, the source. Available on click, not shown by default. An operator who sees the deviation and understands it doesn't need the trace. An operator who sees the deviation and questions it can open the evidence without leaving the review. The common path (deviation is clear, act on it) stays fast. The uncommon path (deviation needs investigation) stays possible without a context switch.
Layer three is the action. Approve Bind, with its provenance fields — who, when, what evidence was open, what note was left. The action sits below the evidence, not beside it. The operator reaches it after seeing the deviation and optionally reviewing the evidence.
[SCREENSHOT: The approval action for a single carrier, showing the provenance fields. Annotate the position relative to the evidence session above it.]
What's missing from this hierarchy is the second verb. The surface has Approve. It does not have Reject. An operator who disagrees with a result can decline to approve — leave the record in its current state, close the review — but that inaction is structurally invisible. The system can't distinguish between "rejected because the deductible was wrong" and "hasn't been reviewed yet." Both look like an un-approved record.
A structured rejection — which field, why, what should happen next — would complete the decision surface. It would also connect this single-moment hierarchy to the longitudinal record I describe in What Happens After the Agent Is Wrong: every rejection becomes a correction the system can learn from in the next run. That connection is what I'm building next.
Build Schedule
No confirmed interview dates in the current record. Posting recency is the urgency proxy. The two OpenAI roles posted August 6 and the still-live Gusto posting are the freshest Act-tier signals.
Immediate — before any outreach or screen this week:
Publish the Trust Framework Revision (Draft 2). Add two screenshots from Carrier IQ's existing review surface and ship it as a field note on junochen.com — either an addendum to the Trust essay or a linked companion page. Writing-only. The editorial draft is done. Both Gusto and OpenAI Payments require a trust framework that goes beyond "keep a human in the loop." This is the fastest way to have that evidence live.
This week:
Produce the Permissioned-Action Surface Annotation (Draft 3). The review surface, coverage deltas, evidence sessions, and approval flow are all live and screenshottable in the current Carrier IQ app. Take the screenshots, annotate the three layers, publish. The rejection-control section stays as design intent with [NEEDS BUILD] markers — still valuable because it shows the operator's decision architecture and names the gap being addressed. This unlocks the OpenAI Engineering Acceleration conversation (rollback as a design problem) and strengthens Gusto (do-not-send as a design problem).
Next two weeks:
Build the correction-to-next-run chain into Carrier IQ's public app. Specifically: a control to mark a specific extracted value incorrect, a stored original/corrected pair, a source-reliability flag, and a verification step in a subsequent run that checks the previously corrected field. Once built, take the screenshots that fill the [NEEDS BUILD] brackets in Draft 1 and publish the Longitudinal Control Record. This artifact completes the most differentiating claim in the portfolio. Writing alone can't produce it.
Parallel, lower priority:
The Confidence-Basis Component and Agentic Component Patterns are both partially drafted and both strengthen systematic credibility. Neither is blocked by a build — they need screenshots and adaptation. Slot them after the top three ship, or pull one forward if a specific company conversation makes it urgent. The Process Narrative is the lowest-effort remaining item (writing-only, draft exists) and worth publishing whenever a Giga or Fieldguide conversation accelerates.
One unresolved exposure: the private-essay access issue and client-side gate failures on full cases remain open from prior issues. They are boundary problems, not evidence problems, so they're not in this queue. But every artifact you publish on the public surface while the private essay remains accessible without authentication widens the gap between what you intend to control and what you actually control.
- CHI 2026 transparency study: A peer-reviewed study with 12 participants found that eight preferred progressive or on-demand transparency over maximal process visibility, which creates a documented tension with the Trust essay's argument that confidence develops through visible work.
- Anthropic's permission model: Their agent research frames operation as plan-act-observe-adjust and describes permission configurations that always allow, require approval, or block specific actions, which maps directly to the autonomy-scope axis in the two-dial revision.
- Vercel's agent-readable decisions: Vercel reports that coding agents can see existing code but cannot infer why product decisions were made, so it now stores accepted decisions as reviewed, agent-accessible code and requires coverage of loading, error, permission, and edge states.
- OpenAI Payments as new artifact pressure: The Payments role explicitly combines billing, usage pricing, Codex consumption, and agentic workflows, asking the designer to make complex financial logic understandable and trustworthy — a portfolio question not covered by any existing artifact.