A working demo is not a completed customer workflow: keep a three-layer acceptance record

The problem: one green checkmark, three claims

A demo can be green while the customer workflow has never run. In GridZen's own published status, real session creation, signed callbacks and authoritative retrieval are evidenced on the hosted identity route, but a new person passing the full hosted journey and a customer business action remain unverified. Operator tests are not customer demand. If your acceptance record has one row called "identity onboarding", you cannot tell which of these you have proved. The decision for you as the reader: which layer are you actually ready to sign off, and what blocks the next one?

Proposed design: a three-layer acceptance record

This is a proposed application design, not implemented GridZen behavior. Keep one record per pilot with three layers. Layer 1, local fixture: evidence that your handler treats approval, duplicates, corrections and expiry correctly using synthetic data. Layer 2, approved route: evidence that a verified merchant account submitted a pilot application, that the owner reviewed purpose, downstream agreements, supplier rights, capabilities, free allowance and expiry, and that the route is confirmed live. Applications never enable production automatically. Layer 3, real downstream action: evidence that a real user, under a permitted purpose, completed a session, your service re-read the authoritative decision, applied your own policy and performed one bounded business action. Each layer has its own owner, date and evidence reference, and a layer can never be marked complete by evidence from a lower one.

Worked hypothetical: filling in Layer 1

Hypothetical: a small marketplace team runs the downloadable example's identity task. Creation returns mode synthetic_fixture, state simulated, session fixture-session, hosted_link pointing at an example.invalid address, link_executable false and next send_real_provider_link_only_after_authorization. An Approved synthetic event with explicit policy yields status approved, deadline 60, permission_granted true, grant_count 1, live_permission_changed false, policy_version 1, allow_action true. Replaying the same event returns the identical record, grant_count still 1. A later Declined correction yields status declined, permission_granted false, grant_count 1. For a session left pending past its deadline, recover returns status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh and provider_polled false. The team records these values verbatim in Layer 1. Note live_permission_changed false on every row: that field is the fixture telling you Layer 3 has not happened.

Failure handling the record must cover

Failures belong in Layer 1 too. An event for an unknown session raises BINDING_MISMATCH; reading an unknown session raises SESSION_NOT_FOUND. Events must use synthetic identifiers starting with fixture-; anything claiming another mode or source raises PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED, because the fixture has no real signature verifier. Policy changes with a wrong expected version raise STALE_POLICY_VERSION, and an explicit decision without current approved evidence raises CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED. Recover expires state locally; it never polls a provider. Your record should note which caller-owned behavior handles each error, for example routing to manual review rather than retrying blindly.

What the fixture does not prove

The permission in the fixture is a local record in SQLite, not a live seller or user permission. Passing every Layer 1 row says nothing about Layer 2 eligibility, provider allowances or downstream rights, which must be checked before activation. Also keep this example distinct from the anonymous no-signup HTTP trial: that trial returns synthetic responses over three scenarios and is a different artifact from the downloadable example with its four phone branches and identity state machine. Cite which one you ran.

Practical acceptance checklist

Layer 1: every fixture output above recorded with field values; duplicate leaves grant_count unchanged; correction clears permission_granted; expiry reports provider_polled false; both error codes handled. Layer 2: pilot application submitted from a verified merchant account; owner review outcome recorded; route availability separately confirmed; idempotency UUID used per request and existing record read after interruptions. Layer 3: real session completed by a permitted user; authoritative decision re-fetched; your policy version and explicit decision logged; one downstream action performed and reversible. Leave Layer 3 open until all of it exists.

Next step

Run the matching synthetic tutorial in the customer-pilot guide, fill in Layer 1, and inspect how your code handles each failure. Create a sandbox account only when you need saved records. Then decide whether a sandbox integration fits your task before applying for a real pilot route.

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.