Hiring decisions get made in a room you never enter. The interviewer who watched you reason through a delegation boundary in real time has to carry that into a debrief where everyone else saw different evidence. The craft reviewer who used your live application has to translate that interaction into a recommendation for people who didn't touch it.
Your evidence degrades in that transfer. You can structure it so it doesn't.
Why your best evidence is the most fragile
Research on group decision-making — including simulated hiring tasks and a meta-analysis across 20 publications — finds that groups spend disproportionate discussion time on information everyone already encountered. Information held by only one member gets less airtime.
The research comes from controlled experiments, not observed design-leadership debriefs. But the structural conditions match: in a multi-round interview loop, each interviewer sees different evidence. When they sit down together, your resume, your title history, and the general impression are shared. The specific thing each person observed is not.
Some companies build against this. GitLab requires structured scorecards submitted within 24 hours, with ordinary interviewers unable to see each other's full feedback. Figma Engineering reopens a candidate's actual work artifact during the debrief so panelists cite specifics rather than reconstruct from memory. You will not know from the outside whether the company you're interviewing at does either of these things.
Build for the case where they don't. Your evidence mix makes this worse: the work that shows your current AI judgment has no URL anyone can open after you leave, and the published cases that do have URLs don't show current judgment.
The portable unit
Every piece of evidence you present needs three parts so the interviewer who saw it can carry it accurately into the debrief.
Claim. One sentence the interviewer can repeat. A specific proposition about what you can do. "She showed me how she reasons about delegation boundaries in an agent workflow" is a claim. "She has a really strong portfolio" is atmosphere — it can't be inspected or argued with, so it dissolves in the debrief. Claims survive because they're specific enough for the next person to evaluate.
Warrant. The inspectable evidence behind the claim. A screen the interviewer saw. A case study they can pull up after you leave. A live application they used. If the warrant requires the interviewer to reconstruct your verbal explanation from memory, it is already degrading. The best warrants are things the second interviewer — the one who wasn't in the room — can also open.
Boundary. What the evidence does not prove. Candidates almost never provide this, and it is the part that builds the most credibility. When you say "this artifact shows how I reason about this problem — it does not show that this pattern shipped or produced outcomes," you prevent your advocate from overclaiming on your behalf. Overclaiming gets corrected by someone else in the debrief, and the correction damages your advocate's standing, not just your candidacy.
State the boundary yourself. If you leave it unstated, someone else will supply one, and theirs will be less generous.
Evidence-class vocabulary
Label what you're presenting as you transition between evidence types. A phrase, not a preamble. "I'm going to show you an original exploration" tells the evaluator how to weight what follows. "This is published production proof from my work at BCG Digital Ventures" sets a different expectation. The labels prevent the evaluator from applying the wrong standard — expecting shipped outcomes from an exploration, or expecting current AI reasoning from a 2019 enterprise case.
Six classes:
| Class | What it proves | What it does not prove |
|---|---|---|
| Original exploration | How you reason about a design problem right now | That the pattern shipped, survived production, or changed an outcome |
| Production-informed judgment | Design judgment grounded in conditions you've encountered in production AI systems | That the displayed pattern was designed or shipped at your current company |
| Published working artifact | That you can build a functional AI product with inspectable interaction behavior | Adoption, revenue, organizational leadership, or team-scale delivery |
| Published reasoning | That you have a structured framework for a problem domain | That the framework has been executed in production or produced measurable results |
| Published production proof | That you shipped work at scale, with your stated role and reported outcomes | Current AI-native judgment; metrics are not independently verified |
| Verbal practitioner context | Recent proximity to a class of production problems | Anything inspectable — testimony, not portfolio proof |
Use these labels in the interview. They set the evaluator's expectation before you show the evidence, so the evaluator judges against the right standard rather than one they assumed.
Per-layer application
Reference section. Each of your evidence layers with the claim an interviewer can carry, the warrant they can point to, and the boundary you state before they have to guess.
Forward-looking artifacts
Inference-Aware UX, Intent-Based Interaction, Agent Infrastructure as UX, Human-Agent System Design, Delegation Contract, Claims Ledger
Claim they carry: "She reasons visually about current AI-interaction problems — delegation, agent oversight, trust calibration — at a level of specificity that shows active work in this space."
Warrant: The artifact itself. States, counterexamples, instrumentation proposals, evaluation conditions, design decisions — visible in the work. These do the most differentiation work because they show current judgment, which your published production cases cannot.
Boundary to state: Original and production-informed, but not published production proof. No stable public URL exists for these artifacts, so they can be presented in a live review but not cited afterward. Say it directly: "This is an original exploration informed by production conditions I've encountered. It has not shipped."
Trust essay — "Trust Is the New Interface"
Claim they carry: "She has a structured account of how agency and responsibility move through an agentic workflow — five handoffs, a Watch-Verify-Delegate progression."
Warrant: The published essay. Public and inspectable after the interview.
Boundary to state: Published reasoning, not execution proof. The framework has not been tested against production durability, speed, or business outcomes. Present as a thinking tool, not a case study.
Agentic Labs — Brand Pulse, Retail Velocity, Carrier IQ
Claim they carry: "She builds working AI products. I used one during the interview."
Warrant: The live application. An evaluator who opens Carrier IQ and inspects the approval-gate interaction is looking at a warrant that survives retelling — the second interviewer can open it too.
Boundary to state: Solo working-artifact evidence. No adoption metrics, no revenue, no organizational leadership proof, no team delivery. Be precise about what you built and what infrastructure you used. Retail Velocity visibly names TinyFish services as infrastructure, and the other two rest on a similar relationship to TinyFish. Lead with the specific interaction patterns you designed: the approval gate in Carrier IQ, the scoring surface in Brand Pulse. If an interviewer asks about the underlying infrastructure, acknowledge what you built on rather than claiming end-to-end authorship. "I designed this interaction flow; the application runs on infrastructure from my current company" is defensible. Blanket independence claims are not.
Alibaba — Head of Design and Research, North America
Claim they carry: "She diagnosed a structural design problem at enterprise scale, created the mandate to fix it, and the reported results are substantial — +20% daily transactions, +7% DAU, +2.2-point NPS, 47% reduction in buyer-reported security concerns."
Warrant: The published case study covering homepage, search, and product-detail work.
Boundary to state: Enterprise production proof, not AI-native interaction proof. Metrics are published portfolio claims, not independently verified company records. Use only the metrics visible in the cited case.
Thermo Fisher — BCG Digital Ventures
Claim they carry: "She built a zero-to-one exception-first system in pharma supply chain — six partners, nine sites, twelve months, 100% partner adoption."
Warrant: The published case. Boundary: Attribute to BCG DV. The $20M margin opportunity is a stated figure, not a confirmed financial result.
American Red Cross — BCG Digital Ventures
Claim they carry: "She consolidated six disaster-relief systems into one, deployed nationally, with $847K disbursed and 1,689 cases opened in the first two weeks."
Warrant: The published case. Boundary: Attribute to BCG DV. Describe as disaster relief, not healthcare. Do not treat interactive recreations as proof the original system remains live.
Allē — BCG Digital Ventures
Claim they carry: "She designed coordinated consumer and provider surfaces — iOS app and provider back-office — with reported reactivation economics."
Warrant: The published case. Boundary: Attribute to BCG DV. Do not overstate HIPAA or regulated-compliance proof; the case does not establish those details.
Equinox+ — BCG Digital Ventures
Claim they carry: "She shipped a five-brand platform MVP in three months with a 4.8 App Store rating at launch."
Warrant: The published case. Boundary: Attribute to BCG DV. The case does not publish retention, revenue, or adoption-change metrics. The rating is a launch-window snapshot.
TinyFish — verbal practitioner context only
Claim they carry: "She has recent, direct experience with agent traces, attribution, auditability, governance, and commercial AI product decisions."
Warrant: Your verbal description of the role and the classes of production conditions you encountered. Testimony. Cannot be inspected after you leave the room.
Boundary to state — early and explicitly:
"I use TinyFish as context for how I think about these problems, not as portfolio proof. I won't show internal work or cite undisclosed metrics."
It tells the evaluator you know where your evidence stops — which is the same calibration they need from a design leader making scope decisions every week.
Different warrants, same candidate
In Issue #13 I mapped six interviewer types by what each fears and what evidence each needs. The portable-evidence problem adds a routing constraint: different interviewers receive different warrants, but the claims they carry to the debrief should converge on one candidate.
Hiring manager. Their feared failure: hiring someone who can't operate at the organizational level the role requires. Lead with Alibaba (structural diagnosis, mandate creation, reported business movement) or Thermo Fisher (zero-to-one delivery in a regulated domain). The choice depends on the role's primary accountability — organizational redesign or product creation. The claim they carry should be about your pattern, not a single project.
Craft reviewer. Their feared failure: recommending someone whose design judgment doesn't hold under scrutiny. Lead with a labeled forward-looking artifact. This is where your original explorations carry the most weight — the craft reviewer can evaluate your current reasoning directly, in real time. Follow with a live Agentic Labs application if time permits. The reviewer interacts with it, which makes the warrant inspectable rather than narrated.
Cross-functional partner (product, engineering, operations). Their feared failure: getting a design partner who can't reason about constraints outside design. For a product partner, the published cases separate your contribution from the product mechanism and the reported result — let them see that separation. For an engineering or AI partner, the Trust essay's five handoffs and the live Labs applications supply system-behavior and failure-state reasoning. TinyFish context adds credibility here, but remember its class: verbal testimony, not a warrant.
The convergence test: if the hiring manager says "she diagnoses organizational design problems and builds the mandate to fix them," the craft reviewer says "her current visual reasoning on agent-delegation problems is specific and production-informed," and the cross-functional partner says "she reasons about system constraints and failure states," those three claims should reconstruct one candidate.
One correction
In Issue #6 I wrote that Atlassian interviewers "submit feedback independently before calibrating." Atlassian's current public guide supports prompt written feedback followed by calibration but does not establish that feedback is independent, hidden, or locked before discussion. GitLab's process provides stronger evidence of independence — ordinary interviewers cannot see each other's full scorecards. The distinction matters because the degree of independence determines how much the shared-information problem applies. At a company with GitLab-style hidden scorecards, your distinctive evidence has a better chance of surviving in written form. At a company with open discussion before written assessment, it has a worse chance.
You usually won't know which format you're walking into. Label the claim. Attach it to something inspectable. State the boundary before anyone else has to.
- Real debriefs vary wildly: A field study of seven residency-selection committees found participation ranged from one person producing 54% of the words to the most balanced committee ranging 10–30%, illustrating why you cannot assume a structured round-robin when preparing your evidence.
- CZI's published interview categories: Their candidate guide names scope and impact, design excellence, leadership and ownership, and collaboration as evaluation dimensions, giving you a rare look at how one organization frames its scoring criteria before you walk in.
- Consensus doesn't destroy evidence automatically: A structured-interview study found that consensus ratings had statistically higher validity than averaged independent ratings, which complicates the assumption that group discussion always degrades individual judgment.
- GitLab's visibility architecture: Their handbook specifies that ordinary interviewers cannot see each other's full scorecards while hiring managers see everything, creating a documented example of how feedback independence is engineered in practice.

