The Constructive Knowledge Trap: How One Age Signal Creates Liability Across Every Platform

Picture a common scenario: a fourteen-year-old downloads your iOS app. Apple’s Declared Age Range API tells your backend this user falls in the 10–14 bracket. Your app applies the appropriate content restrictions, and everyone moves on.

Later that evening, the same user opens your website on their laptop. The browser provides no age signal whatsoever. Your web app treats them like any other visitor — no restrictions, no guardrails.

Here’s the problem: you already know they’re fourteen. And under an emerging legal framework, you can’t un-know it just because they switched platforms.

How we got here

California’s AB 1043, signed into law in late 2024, represents a shift in how regulators think about age compliance. Unlike earlier frameworks that focused on self-reported age gates or ID verification, AB 1043 introduces the concept of constructive knowledge — the legal principle that a company “knew or should have known” a user’s age based on information reasonably available to it.

The timing isn’t coincidental. In 2023, Apple launched the Declared Age Range API, giving developers access to the age bracket a user (or their parent) declared during Apple ID setup. Google followed with its own Play Age Signals, surfacing similar information to Android developers. For the first time, platform-level age signals became commercially available at scale.

AB 1043 was written in full awareness of these signals. The statute doesn’t require a specific verification method — instead, it asks whether a company had access to information from which a minor’s age could reasonably be inferred. If a platform-level API hands you an age bracket, that threshold is met.

The platform gap

The core tension is structural. iOS and Android now provide age-related information through their respective developer APIs. Web browsers provide nothing.

There is no W3C age signal spec. There is no browser-level API that surfaces a user’s age bracket. Chrome, Firefox, Safari — none of them expose this information, and there are no active proposals to change that. The web remains what it has always been: a largely anonymous environment where users arrive with no platform-attested identity signals.

This creates a three-platform world with a two-platform signal layer:

For companies that only operate on mobile, this asymmetry is irrelevant. But most companies aren’t mobile-only. And the moment you receive an age signal on one platform, the constructive knowledge clock starts ticking across all of them.

What this means for companies

The legal logic is straightforward, even if the technical implications are not.

If your iOS app receives a signal that a user is under 16, and that same user later visits your website, you have constructive knowledge of their age on the web. The statute doesn’t care that the browser didn’t provide the signal. It cares that you, the company, had access to the information.

This creates a liability chain with several uncomfortable properties:

• Retroactive scope. Knowledge obtained on platform A applies to all subsequent sessions on platform B, even if platform B never surfaced the signal.
• Account-level attribution. If the user is logged into the same account on both platforms, the link is clear. But even without a shared account, device-level or household-level inference could trigger the standard.
• Obligation asymmetry. You have the same obligations on the web as on mobile, but none of the same tooling to fulfill them.

The net effect: companies that integrate platform age signals on mobile — as the platforms increasingly encourage them to do — take on compliance obligations on the web that they have no native way to satisfy.

Practical challenges

Even companies that understand the liability chain face a set of hard engineering problems.

Cross-platform identity resolution. Connecting a mobile app user to a web session requires either authenticated accounts or probabilistic matching. Many companies deliberately avoid tight cross-platform identity linking for privacy reasons — creating a direct tension with the need to propagate age knowledge.

The web’s signal desert. Even if you identify a returning user on the web, you still need to decide what to do about new users who arrive with no mobile history. The browser gives you nothing — no age signal, no platform attestation, no parental controls metadata. You’re back to guessing.

Defining “commercially reasonable.” AB 1043’s standard isn’t perfection — it’s what a reasonable company would do given the tools available. But that bar is rising. As more age assurance solutions enter the market, the definition of “commercially reasonable” expands. What was defensible last year may not be defensible next year.

Partial knowledge is worse than no knowledge. Paradoxically, companies that do nothing — that never query platform age APIs — may have a stronger “we didn’t know” defense than companies that partially implement age signals on mobile but neglect the web. Partial adoption creates the exact constructive knowledge that triggers liability.

What can be done

The answer isn’t to avoid platform age signals — that ship has sailed, and regulators are only going to push harder for adoption. The answer is to close the gap by extending age assurance to the one platform that doesn’t provide it natively: the web browser.

A viable cross-platform age assurance approach needs several properties:

• Unified coverage. It must work across iOS, Android, and web — not as three separate integrations, but as a single system that produces consistent verdicts regardless of platform.
• Signal-based, not document-based. Solutions that require ID uploads or biometric scans create conversion friction and privacy risk. A signal-based approach that leverages contextual data, device signals, and behavioral patterns can achieve the same statutory threshold without collecting PII.
• Zero data retention. Any solution that stores user data to solve one compliance problem creates another. The age assurance layer should process signals in real time and retain nothing.
• Audit-ready output. Regulators want evidence, not assertions. Every age determination should produce a structured, cryptographically signed receipt that maps directly to the statutory requirements.

This is the approach we’ve taken with the Arcadia Age API (A3) — a single API that returns age assurance verdicts across all three platforms with sub-second latency, no PII retention, and built-in audit metadata. The goal isn’t just to help companies comply on mobile; it’s to ensure that compliance extends everywhere their users go.

Looking ahead

AB 1043 is the first statute to operationalize constructive knowledge at this level, but it won’t be the last. Similar frameworks are advancing in multiple states, and the EU’s evolving Digital Services Act is moving in the same direction. The companies that build platform-agnostic age assurance infrastructure now won’t just be compliant with California’s law — they’ll be ready for whatever comes next.

The constructive knowledge trap is real, but it’s solvable. The key is to stop thinking about compliance platform by platform and start thinking about it the way the law does: as something that follows the user, wherever they go.