Results and revisions

Result meanings

Verification failures return unsure, not no. API errors do not establish a result. A reason never overrides the result.

Result	Meaning
`yes`	The threshold was met under the accepted checks.
`no`	The threshold was not met under the accepted checks.
`unsure`	The service could not give a reliable answer.

Original yes and no results both use reason: verified. See the API reference for all fields and reason codes.

The Verification’s evaluation_date is the civil date used for the age predicate: age >= age_threshold. It is fixed when the verification is created. original.evaluated_at is the actual UTC time when ZeroAge made the decision, which can be before or after the selected age date.

Document validity is checked when verification happens. A future evaluation_date does not schedule processing or promise future document validity. The document must be valid when verification occurs, independently of the selected age date.

Original and current

View	Meaning
`original`	The decision made when the check ends. It never changes.
`current`	The latest assessment of that decision. It can change when new facts arrive.

Both views are null while the check is pending or processing.

This example shows an original yes followed by a later certificate concern. Only the evaluation date, result fields, and revision are shown:

{
  "revision": 2,
  "evaluation_date": "2026-10-08",
  "original": {
    "result": "yes",
    "reason": "verified",
    "evaluated_at": "2026-10-08T10:02:00Z"
  },
  "current": {
    "result": "unsure",
    "review_status": "needs_review",
    "reasons": ["certificate_revoked"],
    "assessed_at": "2026-10-15T09:00:00Z"
  }
}

clear means no later concern is reported, even when the original result is unsure. It does not guarantee complete monitoring. needs_review means a later concern needs customer review. It uses current.result: unsure and does not establish that the person is under the age threshold.

Handle revisions

The revision is 0 before a result, 1 when the check ends, and increases for later material assessment changes. Store the largest processed revision for each verification.

Incoming revision	Action
Newer	Update the stored current assessment.
Older	Ignore it.
Same revision, identical data	Treat it as a no-op.
Same revision with conflicting data	Reconcile by looking up the Verification.
Missing revision or an unexplained gap	Reconcile by looking up the Verification.

Integration notes

Request expiry is the completion deadline, separate from result lifetime and monitoring.
The evaluation date and original result are immutable. A historical no does not become yes when a birthday passes. Create a new check for a new evaluation date.
A later concern reassesses the same age predicate and evidence. It does not move the target evaluation date to the current date.
Ignore unknown object properties. Treat unknown enum values as an integration mismatch that needs review.
Do not infer age, identity, or document details from reason codes.