[View HTML version](/api/results) · [Browse API reference](/api/v1) · [OpenAPI specification](/api/v1/openapi.yaml)

# 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](/api/v1) 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:

```json
{
  "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.