Verification.flow
Prompts.ts
Trust.md
Verification

How HumanPass works in product reality.

This page explains the real verification loop: what runs in the browser, what flows to the backend, and where the current product should stay conservative in public claims.

Verification Flow
01

Session starts in the product

A host product or dashboard flow creates a session, opens the hosted verify route, and prepares to receive the final result.

02

The browser runs live checks

The verification runtime initializes the selected profile, detector, and anti-spoof path, then guides the user through a prompt sequence.

03

Signals are evaluated and finalized

Prompt completion, liveness confidence, anti-spoof results, and policy signals are assembled before the session is finalized.

04

The app receives a usable result

The host surface can use the session result, token, or operator review flow according to the integration path being demoed.

Prompt Strategy

Profile-aware prompts without pretending unsupported features exist.

Specter keeps its current proven flow untouched.
Phantom uses simple directional prompts for a lighter alternate path.
Argus uses a more deliberate fallback flow with stronger center hold behavior.
Fortress uses stricter policy and longer confirmations instead of fake missing-model claims.
Public Honesty
Specter

This remains the proven baseline and safest demo path.

Phantom

This uses a real alternate profile path with simple directional prompts, but it should still be presented as expanding unless separately rehearsed.

Argus + Fortress

These are meaningful alternates with profile-specific policies, but they should remain clearly marked as experimental modes.

Demo Guidance

Show the live verification loop, not imaginary infrastructure.

The strongest current explanation is simple: HumanPass verifies inside the browser, returns a product-safe result, and already has real operator and integration surfaces around it.