Designs the trust arc for AI products: from first wow moment through production-grade reliability. Covers the three trust types users need to cross before they rely on an AI product, specific mechanisms for each, and how to make limitations a trust signal rather than a liability. Use when designing AI onboarding, diagnosing why trial-to-paid is low despite high engagement, or building transparency documentation.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Designs the trust arc for AI products: from first wow moment through production-grade reliability. Covers the three trust types users need to cross before they rely on an AI product, specific mechanisms for each, and how to make limitations a trust signal rather than a liability. Use when designing AI onboarding, diagnosing why trial-to-paid is low despite high engagement, or building transparency documentation.
triggers
["/ai-trust-design","user is designing onboarding for an AI product","trial-to-paid conversion is low despite high engagement","user wants to build trust signals into an AI product","user is writing a limitations page or transparency doc for an AI product"]
AI Trust Architect. Every AI product faces the same structural problem: users are impressed before they trust, and they trust before they pay. "Wow" is free. Trust is earned. This skill designs the bridge between them.
Note: capability claims precision, limitation statement requirements, and the demo edge-case principle are in pmm/DOMAIN.md (AI product content section). This skill covers the product and onboarding design layer — the mechanisms that build trust inside the product experience itself.
Contract
This skill guarantees:
The three trust types are identified and distinguished — interventions are matched to the specific trust type blocking conversion
The distrust spike is treated as a designed stage, not an accident to avoid
Limitation statements follow the specific/contextual format — vague legal disclaimers are flagged
Output identifies which trust type is the actual conversion blocker before recommending a mechanism
Before starting
Confirm (ask or infer):
Conversion problem — which transition is failing? Discovery → trial / trial → active / active → paid / paid → enterprise?
ICP — developer trialist / business user / enterprise buyer? (different trust types block different ICPs)
Current onboarding design — does the product have a first-run experience? A playground? A limitations page?
Available evidence — what capability evidence exists? (benchmarks, case studies, usage data)
Inputs
Required before proceeding:
Description of the AI product and its primary use case
Which conversion step is underperforming
Current onboarding or first-run design (if any)
ICP or user type experiencing the drop-off
The three trust types
Most AI products conflate these and address none of them properly:
Trust type
User question
When it blocks conversion
Capability trust
"Can it actually do what it claims?"
Prevents first trial; users won't start if they don't believe
Reliability trust
"Will it work consistently, not just in demos?"
Blocks production adoption after initial trial
Safety trust
"What happens when it's wrong, and is that recoverable?"
Blocks enterprise purchase and high-stakes use cases
Decision logic:
Discovery → trial drop: capability trust gap
Trial → active/paid drop: reliability trust gap
Active/paid → enterprise drop: safety trust gap
Do not apply reliability mechanisms to a capability trust problem, or vice versa.
Decision logic — matching mechanism to trust type
Capability trust mechanisms
These establish "it actually works" before the user invests time:
CAPABILITY TRUST DESIGN
Curated first-run experience:
The first output should be as close to perfect as possible.
Do NOT show the full capability range in onboarding — show the
highest-reliability use case first. Broad capability claims attract;
high-quality first output converts.
Social proof from technical peers:
An engineer's benchmark result is worth 100 marketing claims.
Surface case studies and community results from users with similar
technical contexts — not generic testimonials.
Live playground with real inputs:
A locked demo that always works is weaker than a playground where
users see the model working on their own inputs — even if the output
is imperfect. Imperfect real output > perfect scripted demo.
(This is the playground-as-trust-signal principle.)
Reliability trust mechanisms
These address: "will this work consistently for production use?"
RELIABILITY TRUST DESIGN
Accuracy / confidence indicators:
Show the model's certainty where meaningful.
An AI that says "I'm not confident about X" is more trustworthy than
one that asserts everything with equal confidence.
Failure mode documentation:
Explicitly describe when the model fails, under what conditions, and
what the user should do. "This model struggles with X" builds more
trust than silence about X — users will discover it anyway.
Regression testing visibility:
If accuracy metrics are tracked, publish them. Users who know you
measure reliability trust you more.
Version consistency:
For API products, version pinning is a reliability trust feature
as much as a technical one. Users need to know that a prompt that
worked last week still works today.
Safety trust mechanisms
These address: "what happens when it's wrong?"
SAFETY TRUST DESIGN
Explicit use case scoping:
State clearly what the product is and is not appropriate for.
"This is not suitable for [high-stakes use case]" is a trust signal —
it tells the user you've thought about where the product breaks.
Human-in-the-loop design:
For high-stakes actions, the user must always have a review step.
AI products that skip this to feel more autonomous lose enterprise trust.
Error transparency:
When the model is wrong, acknowledge it clearly. Products that make it
hard to identify AI errors lose trust faster than products where errors
are visible and recoverable.
Data handling transparency:
Where does user input go? What is it used for?
For enterprise, this is a prerequisite, not a nice-to-have.
The trust arc
FIRST CONTACT → WOW → DISTRUST SPIKE → TRUST BUILDING → RELIABLE USE → ADVOCACY
The distrust spike is not a bug — it is the natural response to seeing a powerful demo. After the initial wow, users think: "That was impressive in a controlled setting. Will it work for MY situation? What if it's wrong?" Products that acknowledge this spike design better onboarding. Products that pretend it doesn't exist lose users who experience it alone.
Stage
What the user needs
Design response
Wow
Understand what is possible
Curated demo path with high success rate
Distrust spike
Acknowledgment that their skepticism is valid
Explicit limitations page; "when to trust this output" guidance
Trust building
Evidence of reliability in their use case
Examples from users like them; sandbox with their own data
Output shareability; benchmark results to reference
Making limitations a growth asset
The counterintuitive principle: stating limitations increases conversion for serious users.
Serious users (the ones who will pay and stay) are evaluating whether they can trust the product. A product that acknowledges limitations credibly signals:
The team understands the product well enough to know where it breaks
The product is honest — which implies the claims it does make are real
The user won't be surprised in production
Limitation statements that build trust: specific, contextual, with guidance.
Good: "This model performs poorly on [specific input type] — for those cases,
try [alternative approach]."
Bad: "Outputs may not be accurate." (tells the user nothing useful)
Gate: any limitation statement that uses only a general disclaimer without specifying the failure condition and the user action is flagged. Require a specific version before publishing.
Output format
## AI Trust Diagnosis
**Product:** [Name]
**Conversion step underperforming:** [Discovery→trial / Trial→active / Active→paid / Paid→enterprise]
**Trust type blocking conversion:** [Capability / Reliability / Safety]
**ICP:** [Developer trialist / Business user / Enterprise buyer]
### Trust arc stage assessment
Current stage where users drop: [Stage name]
Evidence: [What signals indicate this stage?]
### Mechanisms to implement
Priority 1: [Mechanism — specific design action]
Priority 2: [Mechanism — specific design action]
Priority 3: [Mechanism — specific design action]
### Limitations content audit
Current limitation statements: [Specific / Vague / None]
Required rewrites: [List any vague disclaimers with specific replacement]
### Validation
[ ] Trust type correctly identified before mechanism selection
[ ] Limitation statements are specific (failure condition + user action)
[ ] Distrust spike is designed for, not hoped away
Brain reads / writes
If a companion brain repo is connected:
Before starting:
Read knowledge/icp-map.md — ICP segment determines which trust type is typically the conversion blocker (enterprise buyers need safety trust; developer trialists need capability trust)
Read playbooks/messaging.md — capability claims must be consistent with approved messaging
Brain not connected: proceed normally.
Anti-patterns
Anti-pattern
Why it fails
Fix
Applying reliability mechanisms to a capability trust problem
Users who don't believe the product works won't stay long enough to experience consistency
Diagnose the trust type first; match mechanism to the specific gap
Showing full capability range in onboarding
Users experience edge cases before they've built baseline capability trust; they leave
Show the highest-reliability use case first; expand after trust is established
Vague limitation disclaimers
"Outputs may not be accurate" tells the user nothing; they assume the worst
Replace with: "This model performs poorly on [specific case] — for those cases, [action]"
Hiding the distrust spike
Users experience doubt alone; product feels like it promised something it didn't deliver
Acknowledge skepticism explicitly in onboarding; give users language to evaluate the product
Treating "wow" as the conversion moment
Users who are impressed are not yet converted; the gap between wow and trust is where most churn happens
Design the trust-building stages as explicitly as the wow stage
Enterprise pitch without safety trust established
Enterprise buyers have safety objections that capability and reliability evidence cannot address
Build safety mechanisms before entering enterprise sales conversations
Validation criteria
Conversion step identified before trust type is named
Trust type correctly matched to ICP and conversion stage
Mechanisms are specific to the diagnosed trust type — not generic "build trust" recommendations
Limitation statements are specific (failure condition stated + user action given)
Distrust spike addressed with a design response, not ignored
References & Sources
Tier 2 (operator source — adapted, not authoritative):
