Age Assurance — Overview
Unified age compliance API for web, iOS, and Android. Fills the browser gap where no OS signal exists. Passive signal fusion — no verification walls, no stored PII.
What is the Arcadia Age API?
The Arcadia Age API is a unified age compliance layer for web, iOS, and Android — built around a two-phase Signal Fusion engine designed for California AB 1043 (Digital Age Assurance Act) compliance.
On native apps, A3 normalizes Apple's Declared Age Range API and Google's Play Age Signals into a single, consistent response. On the web — where no OS age signal exists — A3 provides full age assurance through behavioral biometrics, input complexity, device context, and other supplementary signals.
The result is one API call, one response format, and one audit trail — regardless of whether your user is on Safari, Chrome, iOS, or Android.
Building for the web? The @a3api/signals browser SDK is a drop-in npm package (<5KB gzipped) that passively collects these signals from standard browser events. Install it, call getSignals(), and forward the payload to your backend — no user interaction required.
The API implements the statutory framework in two distinct phases:
| Phase | Statute | What happens |
|---|---|---|
| Phase 1 | §1798.501(b)(3)(A) | OS signal is treated as the primary age indicator. This is the default. |
| Phase 2 | §1798.501(b)(3)(B) | Supplementary evidence is scored independently. The OS signal is overridden only when evidence meets the "clear and convincing" legal standard. |
This two-phase design ensures the API never overrides the OS signal based on weak or ambiguous evidence, preserving the statutory primacy of the OS-provided signal.
Key Properties
| Property | Detail |
|---|---|
| Architecture | Stateless lambdalith (single Lambda per service) |
| Data retention | Zero — user data is never stored, logged, or persisted |
| Audit strategy | Cryptographic Receipt — a signed verification_token is returned to the customer |
| Latency | Sub-200 ms cold start; single-digit ms warm |
| Region | us-west-2 (default) |
Verdicts
The API returns one of four verdicts describing the relationship between the OS signal and the supplementary evidence:
| Verdict | Statute Reference | Meaning |
|---|---|---|
CONSISTENT | §1798.501(b)(3)(A) | Supplementary evidence corroborates the OS signal. The OS signal remains the primary indicator. |
OVERRIDE | §1798.501(b)(3)(B) | "Clear and convincing" evidence contradicts the OS signal. The developer SHALL use the assessed age bracket. |
REVIEW | §1798.501(b)(3)(A) | Evidence partially contradicts the OS signal but does not meet the "clear and convincing" threshold. OS signal remains primary; developer may apply lighter restrictions (see below). |
PROVISIONAL | §1798.502 | OS signal is not yet available (transition period Jan–Jul 2027). Assessment is based solely on supplementary evidence. |
REVIEW ≠ reject. A REVIEW verdict does not require you to block the
user or trigger a manual review. The OS signal remains legally primary, so
full access based on the OS bracket is compliant. However, you may choose to
apply lighter business-logic adjustments — such as switching to non-adult ads,
limiting sensitive features, or re-assessing on the next session. See the
full REVIEW guidance
for common approaches.
Age Brackets
The API uses the four statutory age brackets defined in §1798.500(b):
| Bracket | Statute | Value |
|---|---|---|
| Under 13 | §1798.500(b)(1) | under-13 |
| 13–15 | §1798.500(b)(2) | 13-15 |
| 16–17 | §1798.500(b)(3) | 16-17 |
| 18+ | §1798.500(b)(4) | 18-plus |
The response includes both os_signal_age_bracket (echoed from input) and
assessed_age_bracket (the engine's determination). When the verdict is
OVERRIDE, these two will differ — the developer should use
assessed_age_bracket as the primary indicator.
Signal Fusion Categories
The engine evaluates five categories of supplementary evidence, each weighted by how difficult it is to fake:
| Category | Weight | What it measures | Evidence type |
|---|---|---|---|
| Behavioral Metrics | 43% | Touch mode: touch precision, scroll velocity, form completion speed, pressure variance, multi-touch frequency. Pointer mode: click precision, mouse velocity, path straightness, hover dwell time, typing speed, keystroke rhythm. Face estimation fallback (both modes). | Internal (face estimation: external) |
| Input Complexity | 28% | Autocorrect reliance, word-length/syllable distributions | Internal |
| Contextual Signals | 10% | IP reputation, timezone consistency, referrer source | Potentially external |
| Account Longevity | 9% | Account age (days since creation) | Internal |
| Device Context | 10% | OS version, device model, accessibility settings, display scale | Internal |
The "internal" vs "potentially external" distinction matters legally.
§1798.501(b)(2)(B) references "internal clear and convincing information."
The API response includes an internal_evidence_only flag so you know
whether the assessment relied on external databases (IP reputation,
referrer classification) or only on signals your app collected directly.
Interaction Modes
The engine supports three interaction modes that determine which behavioral sub-signals are scored and which thresholds are applied:
| Mode | Value | Platform | Key signals |
|---|---|---|---|
| Touch | touch | Mobile/tablet | Touch precision, touch scroll velocity (0–5000+ px/s), pressure variance, multi-touch frequency |
| Pointer | pointer | Desktop/laptop | Click precision, mouse velocity, path straightness, hover dwell time, pointer scroll velocity (0–1500 px/s), typing speed, keystroke rhythm |
| Hybrid | hybrid | Convertible devices | All signals from both modes |
Set interaction_mode explicitly, or omit it and the engine will auto-detect
from which behavioral signals are present. This ensures correct threshold
calibration — for example, 1000 px/s scroll velocity is moderate on touch but
rapid on a mouse wheel.
Device Normalization
Not all touchscreens are created equal. A budget Android device (e.g., Galaxy A14, Redmi 12C) has a lower-quality digitizer that produces inherently lower touch-precision readings — even when the user is an adult with fully developed motor skills. Without compensation, the engine would flag these users with a "Precision Delta" tag and potentially trigger a false override.
The engine solves this with a Hardware Quality Offset applied during touch-precision scoring:
| Hardware Tier | Offset | Example devices |
|---|---|---|
| HIGH (flagship) | +0.00 | iPhone 15 Pro, Galaxy S24, Pixel 9 Pro |
| MID (mid-range) | +0.05 | iPhone SE, Galaxy A54, Pixel 7a, OnePlus 12 |
| LOW (budget) | +0.10 | Galaxy A14, Moto G Power, Redmi 12C, Tecno Spark |
| UNKNOWN | +0.00 | No device_model provided or unrecognized model |
The tier is detected from the device_context.device_model string (matched against
known model patterns). When device_model is absent, the engine falls back to
OS-based inference: iOS devices default to MID (Apple hardware has consistently
good touchscreens); Android devices without a model match remain UNKNOWN.
The offsets are intentionally conservative (0.00–0.10). They prevent the most egregious false flags on budget hardware without masking genuinely child-like interaction patterns. A child on a Galaxy A14 with 0.20 precision will still score 0.30 after normalization — well below the 0.40 threshold.
To take advantage of device normalization, include device_model in your
device_context payload. The SDK should use the hardware's reported model string
(e.g., Build.MODEL on Android, UIDevice.current.model or uname on iOS).
Consent Synchronizer
Under §1798.501(c), parental consent is a "living" signal — a parent can
approve, deny, or revoke consent at any time via the OS parental-control
framework (Apple Screen Time, Google Family Link) or a third-party identity
wallet. The API accepts an optional parental_consent_status and
consent_source so that when the verdict is "Minor," the developer immediately
knows whether the parent has already approved access — no second consent system
required.
| Field | Values | Notes |
|---|---|---|
parental_consent_status | pending, approved, denied, revoked | Optional — omit for 18+ users or when no consent flow exists |
consent_source | os-system, third-party-wallet, in-app | Required when parental_consent_status is present |
Zero-Retention Architecture
The Arcadia Age API is a Pass-Through Processor — it computes scores and returns results, but stores zero user data. This design is built on four pillars:
| Pillar | What it does | Who stores it |
|---|---|---|
| Cryptographic Receipt | Every response includes a verification_token — an HMAC-SHA256 signed payload containing the verdict, evidence tags, and confidence score. | You store it in your logs. |
| Aggregated Analytics | The API emits hourly verdict counts (e.g., "1,400 OVERRIDE verdicts at 2 PM") with no session IDs, no behavioral values, and no country codes. | A3 infrastructure (counts only). |
| Billing Ledger | A SHA-256 hash of your API key + timestamp + request status is logged for billing reconciliation. Zero assessment data. | A3 billing system (isolated). |
| Customer-Side Storage | Your application stores the verification_token alongside your own user records. | You control retention. |
If a dispute arises, send the verification_token back to A3.
We verify the HMAC signature and decode the payload to see exactly what
happened — without ever having stored a single byte of user data.
This makes A3 a Pass-Through Processor under most Data Processing
Addendums (DPAs), bypassing the majority of enterprise security checklists.
Jurisdiction Awareness
Age-threshold laws vary by geography. The API requires a user_country_code
(ISO 3166-1 alpha-2) so the fusion engine can apply the correct regulatory
regime — for example, California's 13/16/18 brackets versus other US states
that may define different thresholds.
The A3 API is currently available in the United States only. Requests with EU/EEA/UK country codes are automatically rejected with a 403 Forbidden response. See our Terms of Service for geographic availability.
Use Cases
- Web applications — browsers have no OS age signal. The
@a3api/signalsbrowser SDK passively collects behavioral and contextual signals, and A3's signal fusion engine provides full age assurance for any website serving California users. - Cross-platform unification — instead of integrating Apple's Declared Age Range API, Google's Play Age Signals API, and a separate web solution, use A3 as a single normalization layer. One API, one response format, one audit trail.
- Content gating — restrict or adjust content when the assessed bracket indicates a minor.
- Age-gated purchases — add a risk signal before checkout flows, using the specific bracket (under-13, 13–15, 16–17) to apply the right restrictions.
- Audit trails — store the
verification_tokenin your logs to demonstrate compliance if the AG investigates. The token is cryptographically signed and contains the full verdict, evidence tags, and confidence score — no raw user data. - Transition period — use
not-availableas the OS signal during Jan–Jul 2027 and still get a provisional assessment from behavioral data. - Enterprise DPA compliance — tell your customers' legal teams: "We are a Pass-Through Processor. We provide a cryptographically signed receipt. We store zero user data."