Which part of verification orchestration should your application own?

The problem: one status, three questions

A status such as Approved answers a narrow question about provider evidence. It does not say whether the message was authentic, whether it belongs to this tenant and subject, or whether it is inside its deadline. It says even less about whether your rules allow the action now. Under the Bring Your Own Provider guide, the customer keeps its provider relationship and authorizes a defined integration scope. GridZen uses an approved adapter and route to normalize evidence. The current alpha does not accept arbitrary provider keys in a browser or request body. Having a public API or an available account is not evidence of permission to sell the resulting data.

Proposed decision table

This table is a proposed application design, not implemented behavior. Provider evidence. The provider owns it, under your own account and contract. You check that the product, country, event and permitted identifiers match the scope you recorded. Delivery. The orchestration layer owns it. In GridZen's production route, this covers verifying signed notifications, re-fetching authoritative decisions, handling deadlines and deduplicating events. Business permission. Your application owns it. It needs explicit policy, a policy version, a binding to tenant and subject, and a decision made on current evidence. The rule that follows: no row may promote itself into the next one. Approved is not unconditional permission, and live end-to-end customer action remains unverified.

Worked hypothetical scenario and expected fixture outputs

Hypothetically, a team onboards sellers and runs the downloadable fixture locally against SQLite. All identifiers must start with fixture-. Create: the call returns mode synthetic_fixture, state simulated, session fixture-session, and a hosted_link on example.invalid. It also returns link_executable false and next send_real_provider_link_only_after_authorization. An event fixture-approved with policy true: the session returns status approved, deadline 60, permission_granted true, grant_count 1, live_permission_changed false, policy_version 1 and allow_action true. Replaying the same event: the output is identical and grant_count stays 1. A later Declined correction: status becomes declined and permission_granted becomes false. grant_count stays 1 as history. In a separate session left pending past its deadline, recover at now 61 returns status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh and provider_polled false. The permission fields are local fixture records, not live business permission.

Failure handling your application keeps

The fixture raises explicit errors instead of guessing. An event for an unknown session returns BINDING_MISMATCH. Reading an unknown session returns SESSION_NOT_FOUND. Any source other than fixture_callback, or any mode other than synthetic_fixture, raises PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. The fixture accepts only synthetic callbacks and never verifies real signatures. The decide and revise_policy calls require an explicit integer policy version and an explicit boolean. A stale version raises STALE_POLICY_VERSION. Deciding without current approved evidence inside the deadline raises CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED. The handoff call returns verified false and next_action read_current_evidence_and_policy_before_explicit_decision. Recover expires a session locally; it does not poll a provider. Refreshing from a provider is your authorized route's job.

What is and is not implemented

Implemented in the fixture: SQLite persistence, tenant and subject binding, event deduplication, revocation by Declined, local expiry, and versioned policy checks. Evidenced on GridZen's real hosted identity trial: real session creation, signed notifications, authoritative reads and expiry. That trial is for eligible US and GB businesses that accept a separate Didit addendum. It is limited to 2 requests per verified business domain and 10 shared lifetime requests, and to confirmed free modules, with no customer charges. Not verified: a newly Approved real user, and any customer business action. Note also that the anonymous three-scenario HTTP trial is a different artifact from the four-branch downloadable example. Before live use, the guide requires approval of retention, deletion, access logging, policy ownership and operational recovery.

Acceptance checklist

- Record the provider product, country, event, permitted identifiers, account owner, credential handling and downstream evidence scope. - Confirm that server-side processing on the customer's behalf is allowed. - Run the fixture and match the outputs above, including duplicate grant_count 1 and provider_polled false. - Test the failure paths: missing inputs, upstream errors, unknown IDs and stale policy. - Inspect traces for raw identifiers. - Keep business permission in your own rules, with explicit versioned decisions. - Decide whether a saved sandbox request fits your task. Only then consider a real trial.

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/bring-your-own-provider/ 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.