## How Age Assurance works  
Age Assurance is a configurable workflow that confirms whether a user meets an age threshold. It starts with passive, low-friction signals and escalates to active verification only when required.

Each method produces one of two outcomes:

- A **threshold result** — `isSuccess: true` with Boolean threshold flags such as `age18Plus`, `age21Plus`, and `age25Plus`.
- A **no-result outcome** — the method found no usable data, and the evaluation falls through to the next method.

Socure remains neutral on regulatory policy. Your workflow defines the state rules, thresholds, and escalation paths that apply to your business during implementation.

## Available methods  
An Age Assurance workflow can combine passive and active methods, or use a single method on its own.

### Passive methods  
Passive methods resolve an age threshold from existing identity signals and require no photo or document capture.

1. ### Device-based assurance  
RiskOS™ matches a device to a historical identity in Socure's Identity Graph and infers an age threshold.  
Because it needs no user input, device-based assurance is typically the first method in a waterfall when jurisdiction rules allow it.
   
   - **Input:** device session token, captured by the [Digital Intelligence](https://help.socure.com/riskos/docs/digital-intelligence) SDK and passed in the request  
   - **Returns a result** when the device is associated with a known identity.

2. ### Phone-based assurance  
RiskOS™ resolves an age threshold from an identity linked to the phone number. A one-time passcode (OTP) can confirm the user controls the phone.  
Typically used when a device signal is unavailable.
   
   - **Input:** phone number (optional name)  
   - **OTP** runs only when an identity is found. See [One-Time Passcode (OTP)](https://help.socure.com/riskos/docs/one-time-passcode-otp).

3. ### Email-based assurance  
RiskOS™ resolves an age threshold from an identity linked to the email address, with an optional OTP possession check.  
Typically used as an additional passive fallback.
   
   - **Input:** email address (optional name)  
   - **OTP** runs only when an identity is found.

### Active methods  
Active methods estimate or read an age from a capture the user provides through the [Predictive DocV](https://help.socure.com/riskos/docs/predictive-document-verification) Capture App. They run only when a passive method can't resolve age or a jurisdiction requires a capture. Both include liveness and injection checks.

1. ### Selfie-based age estimation  
RiskOS™ estimates an age from a selfie and returns a threshold result with an `accept`, `reject`, or `resubmit` decision.  
Typically used where a document is not required.
   
   - **Input:** selfie image with consent

2. ### Document + selfie verification  
RiskOS™ reads the age from a verified government document, with or without a selfie, and returns a threshold result with an `accept`, `reject`, or `resubmit` decision.  
Typically used where a jurisdiction requires a government document.
   
   - **Input:** government document (± selfie)  
   - The date of birth is used internally and is **not** returned to your application.

## How the waterfall works  
A waterfall runs methods in sequence and escalates to the next only when a method returns no hit or has no input:

- Workflows generally begin with passive methods.
- Passive methods execute in the order configured for your workflow.
- A successful threshold result ends the evaluation and returns a decision.
- A no hit — or no matching input — falls through to the next method.
- Active verification occurs only when required — when no passive method resolves age, or a jurisdiction mandates a capture.

```
Yes

No hit or no input

Yes

No

Evaluation request received

Run next passive method

Threshold result returned?

Return final decision (ACCEPT / REJECT)

Another passive method available?

Active verification (selfie or document)
```

You aren't limited to a waterfall — you can **cherry-pick** a single method or run only the ones a use case needs. The exact sequence depends on the workflow configured during your implementation. Common patterns include:

- **Passive-only** — device, phone, and email with no active fallback, for jurisdictions that accept passive assurance.
- **Passive with active fallback** — escalate to a selfie or document when no passive method returns a result.
- **Active-only** — a single selfie or document step, for jurisdictions that mandate a capture.

## How routing works  
Between steps, the workflow evaluates **routing conditions** — rules that read the request and prior results at runtime and decide which step runs next. Conditions evaluate several kinds of input.

### Request inputs  
Conditions branch on whether a request input is present or on its value — for example, whether a device signal, phone number, or email is available — to route to the matching method.

### Method results  
After a method runs, a condition reads its result — for example, whether `isSuccess` is `true` and the required threshold flag (such as `age18Plus`) is met — to end the evaluation, fall through to the next passive method, or escalate to an active method.

### Jurisdiction rules  
Conditions can read the user's location or state to apply the rules that govern your business in each jurisdiction — for example, allowing a passive-only flow in one state and requiring a document capture in another.

### Customer-specific business rules  
Custom fields you include in the evaluation request can steer routing to match your own business logic — for example, forcing a passive-only path or selecting document over selfie. Socure configures how these fields influence routing during your implementation, so use only the fields defined for your workflow.

> 💡
>
> **Tip:**
>
> Because conditions evaluate inputs and results at runtime, the same workflow can respond differently to each request — applying a jurisdiction rule or escalating to an active method based on what the request contains.