Interpreting evidence
An Assurance Profile describes the evidence used for an action decision. Read claim status together with coverage, freshness, reason codes, and limitations. The active policy determines how those observations become an allow, challenge, hold, or denial.
For sandbox and shadow evaluation, operator continuity compares current behavior with the subject's behavioral reference without assigning an identity probability. Operator-change and automation signals describe the current observations. Read collection coverage, comparison results, and camera calibration quality according to their definitions, alongside your application's account authentication and business controls.
Match the conclusion to the evidence
| Observation | What it tells you | What to check next |
|---|---|---|
| The sandbox flow completes | Enrollment, decisions, challenges, and proof handling are connected in your integration | Exercise your intended devices, users, failure conditions, and business process |
| A proof passes local verification | Its signature and expected request binding are valid | Check current proof state and consumption, then application permissions and transaction state |
| A passkey challenge completes | The authenticator ceremony confirmed the bound request | Resolve the child authorization; apply account recovery and credential ownership controls |
| A shadow evaluation passes its criteria | The selected traces meet the criteria recorded for that evaluation | Review sample representativeness, outcome labels, and failure cases |
| Camera calibration reports ready | Local screen estimation passed its measurement checks | Continue monitoring local screen-estimation quality; use account authentication for identity assurance |
The canonical Assurance Profile uses categorical claims with their limitations. The browser SDK reports collection status and coverage so you can guide evidence collection; the backend requests the action decision.
Design a useful evaluation
State the decision you need to make, such as whether accepted evidence is available often enough for a proposed challenge policy. Define the workflow, population, consent basis, devices and browsers, observation period, expected missing-evidence response, and people responsible for review.
Record policy and SDK versions, sample size, exclusions, and how outcome labels were assigned. Keep calibration input separate from held-out measurements. Examine cohorts and failure cases alongside aggregate results. If the sample excludes a device type or accessibility workflow, preserve that boundary when applying the result.
Use synthetic input for repeatable integration, request-binding, and refusal tests. Use representative participants and independently reviewed outcomes when measuring how a policy behaves for your users. Customer labels such as confirmed_attack and false_challenge require a documented basis: the service records the label, while your review process establishes its meaning.
Present results clearly
Describe the measured workflow, population, observation period, criteria, and result together. For example: “For the participating desktop users, the payout-change shadow evaluation met the recorded outcome-coverage criterion.” Include challenge and hold rates, missing-evidence cases, and exclusions needed to interpret that result.
Report each criterion against the sample and property it measures. Use Evaluate GrayPass for the evaluation workflow and report fields, and the threat model for the trust assumptions to include in your assessment.