A small B2B team has a working synthetic identity onboarding run and wants to request a real hosted identity pilot. The decision is not whether the fixture passes, but what evidence you should demand before anyone treats a pilot result as permission to act on a real user. This article proposes a synthetic-to-approved-pilot acceptance checklist. It shows the exact fixture outputs to verify and names the evidence that is still missing. The checklist is a proposed application design, not implemented GridZen behavior. It does not grant production access.
The problem: a green fixture is not a pilot
The tempting shortcut is to run the synthetic example, see status approved, and request a pilot as if the integration were proven. The fixture only accepts synthetic callbacks: event IDs must start with fixture-, the source must be fixture_callback, and the mode must be synthetic_fixture. Any other mode or source raises PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. It has no real signature verifier. Its recover step expires a session locally and never polls a provider. A permission granted in the fixture is a local record; every output reports live_permission_changed false. So the question for the reader is: which caller-owned behaviors have you tested, and which still need real evidence?
Worked hypothetical scenario and expected outputs
Hypothetically, a team onboarding sellers runs the four-branch downloadable example locally. This is separate from the anonymous three-scenario HTTP trial. Creating the session should return mode synthetic_fixture, state simulated, session fixture-session, link_executable false and next send_real_provider_link_only_after_authorization. A fixture-approved event with policy true should return status approved, deadline 60, permission_granted true and grant_count 1. Replaying the same event should return an identical record with grant_count still 1. A later Declined correction should return status declined with permission_granted false and grant_count 1. In a separate run where the session stays pending past the deadline, recover should return status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh and provider_polled false. An event for an unknown session should raise BINDING_MISMATCH, and a read of an unknown session should raise SESSION_NOT_FOUND.
Failure handling your application must own
Proposed design: treat unknown, review and expired as non-grant states that route to human review or an authorized provider refresh. Never treat them as silent approvals or rejections. Bind every event to tenant and subject. Deduplicate by session and event before granting anything. Make a correction to Declined revoke the local grant. After an interruption, read the existing record rather than creating a new session, and use one idempotency UUID per request. If a phone check is part of signup, the fixture's unknown and provider_failure branches return valid null. Route them to review_or_existing_otp or bounded_retry_then_review; neither sends an OTP.
What GridZen has actually validated
According to the guide, a real basic phone check succeeded through the deployed API and MCP. A previously approved operator identity session was refreshed and read through the customer interfaces. For hosted identity, real creation, signed notifications, authoritative reads and expiry are evidenced. Still unvalidated: human completion of a new session, the real final webhook for a newly Approved user, and an end-to-end customer business action. Operator tests are not customer demand. Approved is never unconditional permission; your rules decide.
Pilot terms to check, not assume
A verified merchant account may submit a pilot application. The owner reviews purpose, downstream agreements, supplier rights, capabilities, free allowance and expiry. Applications never enable production automatically. The current hosted identity trial for eligible US/GB businesses is bounded: 2 requests per verified business domain and 10 shared lifetime requests, with separate Didit addendum acceptance. It covers confirmed free modules only, and customer payments are disabled. Bank-account matching, KYB and automatic business approval are not available. Free allowances do not grant resale rights or guarantee future terms.
Practical acceptance checklist
Before applying, confirm each item. 1) All seven fixture outputs above match exactly, including the two error codes. 2) Your handler refuses grants without explicit policy and an account binding. 3) Duplicate events do not increment grant_count. 4) Declined revokes access. 5) Expired, unknown and review states reach a review queue. 6) Recovery reads existing records and never creates duplicate sessions. 7) You have read the capabilities and documented your purpose and downstream agreements. 8) You have recorded the missing evidence: a real signed final webhook, a newly Approved user and a live business action. Verify these during the bounded pilot before relying on them. Your next step is to run the synthetic example and inspect your failure handling. Request a saved sandbox only if the task fits.
Run the checked synthetic example
Download and extract https://gridzen.ai/downloads/verification-delivery.zip, enter verification_delivery, then run with Python 3.10+. This local example makes no network calls. Use a fresh database for an independent identity run.
python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite
Sources and scope
https://gridzen.ai/guides/customer-pilot/
https://gridzen.ai/guides/current-capabilities/
Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "identity_onboarding", "scenario": "success"}'
This is synthetic integration testing, not identity verification or production authorization. Real payments are disabled.
Create a free sandbox account · Integration guide
Written and tested by the GridZen team with AI assistance.
Top comments (0)