AI Credibility Dossier: When the Reframe Doesn't Land

The standard four-layer reframe covers most AI credibility questions at the portfolio-review and first-interview stage. This dossier is for when you've delivered it and the interviewer keeps pushing.

That push tells you something specific. The reframe failed to satisfy a particular screen, and until you identify which one, every additional piece of evidence you offer is a guess. You may not be able to satisfy it at all. Knowing that quickly is also valuable.

The general framework for diagnosing reframe failures — perception gap, evidence gap, mandate boundary — is in "Where Objections Form". Everything below applies that framework to the AI credibility objection.

The diagnostic question

When the standard reframe doesn't land and the interviewer presses — a follow-up, a skeptical pause, a redirect to "but what about the technical side" — deploy this before your next piece of evidence:

"What does the technical work look like for this role day-to-day?"

This is information-gathering, not a stall. "AI technical depth" is at least five different screens, and each one requires different evidence or a different kind of honesty. The interviewer's answer sorts you:

• They describe interaction patterns, trust surfaces, oversight flows: Screening for interaction judgment (Screen 1). You have strong evidence. The reframe failed on delivery, not substance.
• They describe building prototypes, working in code, shipping experiments: Screening for code-based prototyping (Screen 2). Partial evidence, known gap.
• They describe writing production code, committing to repositories, owning implementation: Screening for production-code authorship (Screen 3). This is a boundary.
• They describe model behavior, output quality, failure modes, prompt architecture: Screening for model-behavior reasoning (Screen 4). Conceptual evidence, limited hands-on proof.
• They describe designing evaluations, building measurement frameworks, writing scoring rubrics: Screening for evaluation design (Screen 5). Likely a boundary.

Each requires a different response.

Screen 1: Interaction judgment

Classification: Perception gap.

Their question sounds like: "Have you actually designed AI interactions — not just written about them?"

They want evidence you can design the specific patterns AI products require: how users review agent output, when to surface confidence, how to structure human override, what happens when the system is wrong. The Trust essay and the CarrierIQ approval gate are direct evidence. If the reframe didn't land, the connection between your existing work and their product's interaction surface wasn't concrete enough.

Lead with: "The approval gate in Carrier IQ — one of the AI systems I've built recently — is structurally the same problem: a user inspecting system-generated output, deciding whether to authorize a consequential action, with the system providing context for that decision. I can walk you through the specific interaction patterns: what the system surfaced, what the user could override, how we handled the cases where the system was wrong."

Then map CarrierIQ's approval flow to their product's equivalent surface. Be specific about their product. Generic "my work transfers to AI" framing will not survive a skeptical evaluator.

Confidence: High. This is your strongest evidence. If it still doesn't land after a concrete, product-specific mapping, the interviewer may be screening for something they haven't named. Ask a follow-up: "Is there a specific technical capability you're trying to assess? I want to make sure I'm answering the right question."

Screen 2: Code-based prototyping

Classification: Hybrid — perception gap on capability, evidence gap on process.

Their question sounds like: "Can you actually build things, or do you hand specs to engineers?"

You have three working applications. That's capability evidence. What you don't have is an inspectable build record (repository history, rejected approaches, versioned iterations) that shows how you got there. Issue #12 covered this gap: the applications show an outcome, but the evaluator screening for prototyping fluency wants to see the process.

Lead with: "I build working prototypes — I can show you three live applications. What I should be honest about is that I haven't published the build process behind them. If you want to see how I work through a prototyping problem, I'd welcome a take-home exercise or a live working session."

The offer to do a live exercise shifts the evaluation from inspecting past artifacts to observing present capability. Most evaluators screening for prototyping fluency respond well to it.

Confidence: Medium. Depends on whether the interviewer accepts the live-exercise redirect or insists on inspectable prior work. If they want a public repository with commit history, you don't have that today.

Evidence status: Working applications exist. Build-process documentation does not. A published build walkthrough showing repository structure, rejected approaches, and versioned iterations for one of the three apps would close this gap. It does not exist and is not in progress.

Screen 3: Production-code authorship

Classification: Evidence gap — non-substitutable.

Their question sounds like: "Have you written production code? Do you commit to the codebase?"

This is a boundary. The Issue #12 treatment remains current. You have not held a production-engineering role. No reframe changes that, and attempting one will cost credibility you need for the screens where you are strong.

Lead with: "I haven't held a production-engineering role. I've led technical product work and built functional prototypes, but I don't write production code. If this role requires that as regular work, that's worth knowing now so we're both evaluating fit accurately."

Said aloud, this sounds like a senior operator who knows what she does and doesn't do. It doesn't redefine "production code" to include prototyping, and it doesn't apologize.

Confidence: High — on the boundary statement itself. The confidence is in the response, not the outcome. Some roles genuinely require production-code authorship from the designer.

Stop rule: If the interviewer confirms production-code authorship is a regular expectation, stop reframing. This is a qualification boundary, not a messaging problem.

Screen 4: Model-behavior reasoning

Classification: Hybrid.

Their question sounds like: "Do you understand how these models actually work? How do you design for model limitations?"

The Trust essay shows you can reason structurally about model behavior — delegation, mandate drift, the difference between prediction failure and authority violation. TinyFish provided direct experience working with model outputs in production. But you don't have a published artifact showing hands-on engagement with model tuning, prompt architecture, or systematic failure-mode analysis.

Lead with: "At TinyFish I worked directly with model outputs in production — understanding where they failed, how failure modes shaped the interaction design, what the system needed to surface so users could catch problems. The Trust essay lays out the conceptual framework: when a system acts on your behalf, the design problem is making its reasoning and its limits visible. What I don't have is experience on the model-development side — training, fine-tuning, evaluation scoring."

This draws a clear line between designing for model behavior and developing model behavior. Said aloud, it reads as someone who knows the territory well enough to name exactly where her experience stops. Most design roles at AI companies need the former.

Confidence: Medium. Strong if the role is about designing interfaces that account for model limitations. Weak if the role requires direct participation in model development or evaluation infrastructure.

Evidence status: The Trust essay and TinyFish context exist but are conceptual and contextual, not hands-on proof. The artifact that would close this gap is a published failure-mode analysis: bad model output, diagnosis of the failure pattern, the design or system change that addressed it, and verified subsequent behavior. This is the correction-lineage record from Issue #8. It is specified but not built. No other artifact addressing this gap is in progress.

Screen 5: Evaluation design

Classification: Evidence gap — likely non-substitutable.

Their question sounds like: "Can you design evals? Do you know how to build measurement frameworks for model quality?"

This screen shows up primarily at companies like Anthropic where some design-adjacent roles involve designing evaluation frameworks — writing scoring rubrics, building assessment interfaces, defining quality metrics for model outputs. If the role requires production-quality code for evaluation infrastructure, that's a gate, non-negotiable regardless of how strong the rest of your profile is.

Lead with: "I've designed measurement frameworks for product quality and user outcomes, but I haven't built evaluation infrastructure for model behavior specifically. If this role requires designing evals in the technical sense — writing scoring functions, building evaluation pipelines — that's outside my current background."

Same logic as Screen 3's boundary: name what you have, name where it stops, don't hedge.

Confidence: Low for roles where evaluation design is a primary responsibility. If the posting mentions evaluation infrastructure, assessment design, or scoring methodology, treat this as a boundary and apply the same stop rule as Screen 3.

Evidence status: Prior product-quality measurement work exists in your background but has not been documented as a standalone artifact. Even if it were, the transfer to model evaluation is limited — product-quality metrics and model-evaluation scoring are structurally different problems. The artifact that would partially close this gap is a model-evaluation case study showing rubric design, scoring methodology, and quality-metric definition applied to model outputs. It does not exist and is not in progress. For roles where evaluation design is a primary responsibility, this is likely a boundary that no artifact can close.

The forward-looking artifact problem

One reason the standard reframe fails more often than it should: the forward-looking artifact layer is currently empty. The Inference-Aware Decision Surface has a completed specification but has not been built or published. The other named objects — Delegation Contract, Claims Ledger, Correction Lineage — are specified but not built. None are publicly accessible on junochen.com.

Until those artifacts ship, the reframe depends more heavily on mapping existing work — particularly CarrierIQ — to the target company's AI interaction surface. That mapping has to be precise and product-specific every time.

Supplementary: AI-assisted portfolio work

This isn't a sixth screen. It's a question that can surface during any of them — particularly Screens 2 and 4 — when the interviewer wants to understand authorship.

If an interviewer asks whether you used AI tools to build your portfolio artifacts, Anthropic's current guidance draws a useful line: candidates may use AI to refine their own work but should not use it to create experience they didn't have. Using AI tools to build self-directed portfolio artifacts before entering a hiring process is not prohibited. Using AI during a take-home assessment is prohibited unless the company explicitly says otherwise. Using AI during a live interview is prohibited unless told otherwise.

"I use AI tools in my design process, including when building portfolio work. The design judgment — what to build, why, what tradeoffs to make — is mine. The tools accelerate execution."

A true statement that claims exactly what you can claim.

Pre-Interview Reference Card

Scan this before you walk in.

Deploy first: "What does the technical work look like for this role day-to-day?"

If asked about AI-assisted portfolio work: "I use AI tools in my design process. The design judgment is mine. The tools accelerate execution."

Stop rules:

• If they confirm production-code authorship is a regular expectation: stop reframing. Boundary.
• If they confirm evaluation infrastructure is a primary responsibility: stop reframing. Boundary.
• If they keep pushing after a concrete, product-specific interaction-judgment mapping: they may be screening for something they haven't named. Ask again, more directly.

When the reframe fails, the interviewer hasn't concluded your background is weak. They haven't heard evidence for the specific thing they're evaluating. The diagnostic question finds out what that thing is before the assessment hardens into "not technical enough" — which, once it forms in the room, is nearly impossible to walk back.