UK Age Appropriate Design Code Compliance

Executive Summary

⚠️ IMPORTANT CLARIFICATION: Provii is an AGE VERIFICATION SERVICE (not a service FOR children)

UK Children’s Code Applicability to Provii: ❌ NOT APPLICABLE

Provii is NOT subject to the UK Children’s Code because:

1. Service excludes children by design: Age verification REJECTS users below 18+/21+ thresholds (depending on configuration)
2. Not “likely to be accessed by children”: ICO guidance states the Code applies to services “likely to be accessed by children” - Provii actively EXCLUDES children
3. Zero knowledge architecture: NO personal data is processed from anyone, including children who attempt to access age-restricted services
4. No child data processing: Even for edge cases (12+/13+ thresholds), Provii only verifies zero knowledge proofs and signs encrypted credentials - the issuer handles identity proofing and PII

ICO Children’s Code Scope (from ICO guidance):

“The code applies if your online service is likely to be accessed by children.”

Provii’s Business Model:

• ✅ Age verification for ADULT content (proves users are 18+, 21+)
• ✅ Prevents children from accessing age-restricted services
• ✅ Users below threshold are REJECTED - no service provided, no data collected
• ✅ Even rejected verification attempts collect NO PII (zero knowledge architecture)

This Document’s Purpose:

While Provii is NOT subject to the Children’s Code, this document demonstrates how our privacy-by-design architecture exceeds the Code’s privacy standards and enables clients (gaming platforms, social media, e-commerce) who ARE subject to the Code to achieve compliance through zero knowledge age verification.

Key Value Proposition: Services subject to the Children’s Code can use Provii to verify user age without collecting personally identifiable information (PII), thereby simplifying compliance with Standards 1-15.

Introduction

About the Children’s Code

The UK Age Appropriate Design Code (also known as the Children’s Code) came into force on September 2, 2020, under the Data Protection Act 2018. It sets 15 standards for online services “likely to be accessed by children” to ensure their data protection rights are upheld.

Regulatory Authority: Information Commissioner’s Office (ICO)

Scope: Applies to:

• Information society services (websites, apps, connected toys, social media platforms, online games, streaming services, online marketplaces, etc.)
• Services offered to UK children or likely to be accessed by children
• Services that process personal data of UK children

Age Definition: The Code primarily focuses on children under 18, with heightened protections for children under 13.

Key Principles:

1. Best interests of the child must be a primary consideration
2. High privacy by default
3. Transparency about data use in age-appropriate language
4. Data minimisation
5. No detrimental use of data
6. No profiling unless in child’s best interests

References:

• ICO Children’s Code Guidance
• Data Protection Act 2018, Section 123
• GDPR Article 8 (Conditions for children’s consent)

Applicability to Provii

Direct Applicability: ❌ NOT APPLICABLE

Provii is NOT subject to the UK Children’s Code because:

1. Not “likely to be accessed by children” (ICO threshold test):

• Provii is an age verification service for ADULT content
• Primary use case: Prove users are 18+ or 21+ to access age-restricted services
• Children below threshold are REJECTED - no service provided to them
• ICO guidance: Code applies to services children will use - Provii actively excludes children

2. No child data processing:

• Zero knowledge architecture means NO personal data is processed from anyone
• Date of birth is transmitted once during issuance to compute a cryptographic commitment, then immediately discarded (never stored or logged)
• Even users who are rejected (below threshold) have NO data collected
• No profiling, tracking, or data storage related to age verification attempts

3. B2B infrastructure service:

• Provii provides verification APIs to businesses (relying parties)
• Not a consumer-facing service with user accounts or profiles
• No content, games, social features, or services that children would access

4. Even for edge cases (e.g., 12+/13+ thresholds for certain jurisdictions):

• Provii only verifies zero knowledge proofs and signs encrypted credentials
• Issuer handles identity proofing and PII processing, NOT Provii
• Provii never sees date of birth or any personally identifiable information

ICO Children’s Code Scope (from official guidance):

“The code applies if your online service is likely to be accessed by children.”

Provii’s Reality:

• ✅ Service designed to EXCLUDE children (age verification for adult content)
• ✅ No child users (children are rejected, not served)
• ✅ No child data processing (zero knowledge = no PII processing)
• ✅ Result: Children’s Code does NOT apply

Strategic Importance: While NOT subject to the Code, Provii:

1. Enables compliance for clients who ARE subject to the Code (gaming platforms, social media, e-commerce)
2. Demonstrates privacy excellence that exceeds Children’s Code requirements
3. Demonstrates privacy-by-design in regulated markets

Provii’s Unique Position:

• We are the privacy infrastructure that enables other services to comply with the Children’s Code
• Our zero knowledge architecture provides better privacy than the Code requires
• We help clients meet Standards 1-15 without collecting children’s PII

Standard-by-Standard Compliance

Standard 1: Best Interests of the Child

Requirement: The best interests of the child should be a primary consideration when you design and develop online services likely to be accessed by children.

Maelstrom AI’s Approach

Maelstrom AI’s architecture serves children’s privacy interests through architectural guarantees rather than policy promises:

1. Zero knowledge Age Verification: Children prove they meet age thresholds (e.g., “13+”, “18+”) without revealing their date of birth

• Protects children from identity theft
• Prevents data brokers from collecting children’s DOBs
• Reduces risk of age-based discrimination

2. No Central Database: No honeypot of children’s personal data exists

• No risk of data breach exposing children’s information
• No government surveillance of children’s identities
• No corporate profiling based on age or DOB

3. User Control: Children (and parents) control the wallet and credentials

• Credentials stored locally on device
• No remote access by Maelstrom AI or third parties
• User can delete wallet at any time

4. Privacy by Design: System is designed to be unable to collect children’s PII

• Not a policy choice - an architectural fact
• Cryptographic guarantees prevent PII collection
• Open source code allows verification

Evidence

Location: /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md

Quote:

“Provii’s zero knowledge architecture is its primary privacy mechanism - the system is designed so that it cannot collect PII, rather than relying on policy to protect it.”

Code Evidence:

• provii-crypto/crypto-verifier/src/lib.rs - Zero knowledge proof verification reveals only binary age threshold (over/under), not actual DOB
• provii-verifier/src/routes/verify.rs - Server processes proofs without accessing DOB

Privacy Impact Assessment:

• Traditional age verification: Collects name, DOB, ID document - High risk to children
• Provii: Collects zero PII - Minimal risk to children

Docs Sandbox Child-Impact Analysis:

• Child-focused DPIA for the docs interactive sandbox: DPIA. Children’s Code Standard 2 (Docs Sandbox)
• Concludes the sandbox is not likely to be accessed by children in the ICO sense (developer onboarding surface), rejects raw DOB strings at the schema boundary, and operates a zero-retention SLA for any DOB-shaped payload
• Confirms the best-interests posture extends to every Provii surface, including the pre-contractual developer onboarding surface

Status

✅ EXEMPLARY COMPLIANCE

Maelstrom AI goes beyond Children’s Code requirements by making privacy architecturally guaranteed rather than policy-based.

Standard 2: Data Protection Impact Assessments

Requirement: If you provide an online service likely to be accessed by children, undertake a DPIA specifically in respect of the child safety and data protection risks that might arise from your data processing, and keep this under review.

Maelstrom AI’s Approach

Current Status: Formal child-focused DPIA published for the docs interactive sandbox at DPIA. Children’s Code Standard 2 (Docs Sandbox). The previous gap-flag (“formal DPIA documentation recommended”) is now closed for the surface that carried the residual risk.

Assessment Conclusion: Maelstrom AI now maintains formal DPIA coverage across every surface on which the Children’s Code could plausibly bite:

1. Production verification infrastructure: Traditional DPIA not strictly required. no PII processing, no high-risk processing, privacy-enhancing technology. Evidence retained in /trust/security/dpia.md and the risk register.
2. Docs interactive sandbox: Formal child-focused DPIA now published at /trust/compliance/standards/childrens-code/dpia-children. Concludes the sandbox is not likely to be accessed by children in the ICO sense, accepts fixture IDs only (no raw DOB), and operates a zero-retention SLA for any DOB-shaped payload.
3. Companion sandbox DPIA: /trust/security/dpia-docs-sandbox covers the GDPR Article 35 analysis for the docs sandbox including developer-facing risks.

Risk Assessment Conducted:

• Location. /trust/security/risk-register.mdx
• Scope. Privacy risks from IP logging, credential tracking, issuer correlation, and docs sandbox exposure (entries RISK-2026-DOCS-H/M-NN)
• Mitigations. IP hashing (90-day retention), nullifiers (replay prevention), RedJubjub issuer signatures with nullifiers (issuer unlinkability), schema-level rejection of raw DOB strings at the sandbox boundary

Child-Specific Risk Analysis:

Evidence

Privacy Risk Assessment:

• /trust/security/risk-register.mdx - risk assessment including docs sandbox entries
• /trust/security/risk-methodology.mdx - Risk assessment methodology
• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md - Privacy by Design analysis

DPIA Coverage:

• DPIA. Children’s Code Standard 2 (Docs Sandbox). child-focused DPIA for the docs interactive sandbox
• Docs Sandbox DPIA. GDPR Article 35 DPIA for the docs sandbox surface
• Production DPIA. production wallet and verifier

Status

🟡 FULLY COMPLIANT (documentary). Formal child-focused DPIA is published for the docs sandbox (previously flagged gap), and production surfaces are covered by the existing risk assessment and Article 35 DPIA. The documentary layer of Standard 2 is therefore satisfied.

Residual dependency on planned technical enforcement. The DPIA conclusions assume that the sandbox-production isolation layers tracked under UC-186 reach operational status. UC-186 is currently Planned under the docs sandbox Phase 0A delivery workstream, with four implementation layers in progress:

• Cargo feature flag gating sandbox-only modules at compile time Planned)
• build.rs assertion rejecting production builds that include sandbox symbols Planned)
• CI bundle-grep step failing promotion if any sandbox symbol reaches a production artefact Planned)
• Runtime middleware prefix rejection at the production ingress (already deployed, covered by UC-186 layer 4 negative tests)

Full “FULLY COMPLIANT” status is withheld until UC-186 layers 1 to 3 are operational and the compile-time, build-time, and CI-time enforcement chain is evidenced end-to-end. The DPIA will be reassessed at that point per its reassessment trigger list, and the status here upgraded to ✅ accordingly.

Standard 3: Age-Appropriate Application

Requirement: Take a risk-based approach to recognising the age of individual users and ensure you effectively apply the standards in this code to child users.

Maelstrom AI’s Approach

Provii’s Core Function: We ARE the age-appropriate application mechanism for other services.

Age Verification Methods:

1. Credential Issuance: Trusted third parties (banks, government agencies, in-person verification) issue age credentials

• Issuer validates date of birth from authoritative sources
• User receives cryptographic credential proving DOB
• Credential never reveals DOB to verifiers

2. Zero knowledge Proof: Users prove “age >= threshold” without revealing DOB

• Threshold configurable per service (13+, 16+, 18+, 21+, etc.)
• Cryptographically secure (Groth16 zk-SNARKs on BLS12-381 curve)
• Binary result: PASS or FAIL (no age information leaked)

3. Challenge-Response Flow: Each verification is fresh and unlinkable

• Service requests verification for specific age threshold
• User wallet generates proof for that threshold
• Proof cryptographically bound to requesting service
• No cross-service tracking possible

Age Accuracy:

• Age determined at issuance by trusted credential issuer
• Cryptographic proof guarantees age claim is valid
• No self-declaration (proof cannot be forged)
• No circumvention (replay prevention via nullifiers)

Evidence

Age Verification Flow:

• /trust/compliance/evidence/age-verification/flow-evidence.md - Complete flow documentation
• provii-crypto/crypto-verifier/src/lib.rs - Age threshold proof verification
• provii-crypto/crypto-protocol/src/lib.rs - Challenge generation and binding

Code Evidence (Age Threshold Verification):

pub fn verify_age_snark(
    proof_bytes: &[u8],
    cutoff_days: i32,  // Age threshold (e.g., 4745 days = 13 years)
    rp_hash: [u8; 32],
    issuer_vk_bytes: [u8; 32],
    cred_nullifier: [u8; 32],
) -> Result<VerifyResult>

How Clients Use This:

• Gaming platform: Verify age >= 13 (COPPA compliance)
• Alcohol retailer: Verify age >= 18 or 21 (local laws)
• Social media: Verify age >= 13 (Children’s Code high privacy for under-13s)

Status

✅ FULLY COMPLIANT

Provii provides cryptographically secure, unforgeable age verification that enables clients to apply Children’s Code standards appropriately.

Standard 4: Transparency

Requirement: The privacy information you provide to users, and other published terms, policies and community standards, must be concise, prominent and in clear language suited to the age of the child. Provide additional specific ‘bite-sized’ explanations about how you use personal data at the point that use is activated.

Maelstrom AI’s Approach

Radical Transparency: Maelstrom AI goes beyond typical privacy notices through:

1. Open Source Code: All core components publicly available

• provii-verifier (backend verification)
• provii-issuer (credential issuance)
• provii-mobile (client wallet)
• provii-crypto (cryptographic primitives)
• GitHub: our GitHub organisation (under the MaelstromAI enterprise account)

2. Published ISMS: Entire Information Security Management System is public

• Security policies
• Risk assessments
• Control implementations
• Compliance documentation
• Location: /trust/

3. Architecture Documentation: Complete system design published

• Data flow diagrams
• Privacy guarantees
• Cryptographic specifications
• Trust model

Privacy Communication (Age-Appropriate):

For Children (13+):

“Your birthday is sent to us once when you first set up the app so we can do the special maths to create your proof. We throw it away straight after and never keep it. After that, your birthday stays on your phone and is never sent again.”

For Parents:

“Provii uses zero knowledge cryptography to verify your child’s age without collecting their personal information. The system is mathematically designed to be unable to see or store dates of birth.”

For Technical Audiences:

“Groth16 zk-SNARKs prove age >= threshold without revealing DOB. Server-side: IP addresses hashed, retained 90 days. No PII collected or stored.”

Bite-Sized Explanations (Just-in-Time):

• Wallet install: “Your credentials stay on your device”
• Proof generation: “Proving you’re [age]+ without sharing your birthday”
• After verification: “Website confirmed your age. They didn’t see your birthday.”

Evidence

Documentation:

• /trust/security/information-security-policy.mdx (Lines 111-121) - “Radical Transparency” principle
• /trust/overview/architecture.mdx - Public architecture documentation
• /trust/overview/trust-model.mdx - Privacy guarantees explained

Policy Quote:

“We make our security practices public because:

• We have nothing to hide (no PII to protect through obscurity)
• Open scrutiny improves security
• It builds trust through verifiability”

Public Resources:

• Public documentation: https://docs.provii.app
• Open source repos: our GitHub organisation (under the MaelstromAI enterprise account)
• ISMS published: /trust/

Docs Sandbox Transparency Posture:

• DPIA. Children’s Code Standard 2 (Docs Sandbox) is published alongside the sandbox itself, so anyone evaluating the sandbox can inspect the child-impact analysis before they run a fixture through it
• Sandbox cookies (__Host-docs_session, Cloudflare edge cookies) are disclosed in the Cookie Policy with purpose, scope, and duration
• Sandbox processing activity documented in the Privacy Policy Section 2.5 with lawful basis, retention, and cross-border handling
• Cloudflare bot protection justified in Legitimate Interest Assessment Part 4

Status

✅ EXEMPLARY COMPLIANCE

Complete transparency through open source code and published documentation. Privacy information available at multiple literacy levels, with the docs interactive sandbox surfaces separately disclosed in cookie, privacy, and LIA documents.

Standard 5: Detrimental Use of Data

Requirement: Do not use children’s personal data in ways that have been shown to be detrimental to their wellbeing, or that go against industry codes of practice, other regulatory provisions or Government advice.

Maelstrom AI’s Approach

Detrimental Uses - Not Architecturally Possible, by Design:

❌ Cannot Profile: No PII collected = no profiling possible ❌ Cannot Track: Random IDs per verification = no cross-site tracking ❌ Cannot Sell Data: No personal data to sell ❌ Cannot Target Ads: No behavioural data collected ❌ Cannot Manipulate: No knowledge of user identity or behaviour ❌ Cannot Discriminate: Only binary age threshold revealed

Data Use Policy: All data collected (IP addresses, challenge IDs, nullifiers) is used exclusively for:

1. Cryptographic verification of age proofs
2. Anti-abuse protection (rate limiting, replay prevention)
3. System diagnostics and security monitoring

What Data is NOT Used For:

• Marketing or advertising
• User profiling or analytics
• Third-party data sharing
• Cross-site tracking
• Behavioural analysis
• Identity resolution
• Predictive modeling
• Social graph mapping
• Location tracking
• Sentiment analysis

Purpose Limitation Enforcement:

• Architecture prevents repurposing (no PII to repurpose)
• Unlinkability prevents tracking
• Open source code allows verification

Evidence

Privacy Architecture:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 99-138) - UC-002: Purpose Limitation

Quote:

“What Data is NOT Used For: ❌ Marketing or advertising ❌ User profiling or analytics ❌ Third-party data sharing ❌ Cross-site tracking ❌ Behavioural analysis ❌ Identity resolution”

Code Evidence:

• provii-verifier/src/routes/verify.rs - Verification processes only cryptographic proofs, no PII
• provii-verifier/src/security/log_sanitizer.rs - IP addresses hashed for privacy

Competitive Comparison:

Status

✅ EXEMPLARY COMPLIANCE

Architectural guarantees prevent detrimental uses. Not a policy promise - a technical fact.

Standard 6: Policies and Community Standards

Requirement: Uphold your own published terms, policies and community standards (including but not limited to privacy policies, age restriction, behaviour rules and content policies).

Maelstrom AI’s Approach

Published Policies:

1. Information Security Policy

• Location: /trust/security/information-security-policy.mdx
• Scope: All Maelstrom AI operations
• Key Principles: Zero knowledge First, Privacy by Design, Radical Transparency
• Review: Annually

2. Data Retention Policy

• Location: /trust/security/data-retention.mdx
• IP addresses: 90 days maximum; critical security event logs are retained for up to 365 days
• Challenge records: 5-minute active TTL, automatically expired and purged after use
• No PII retention (none collected)

3. Cryptography Policy

• Location: /trust/security/cryptography-policy.mdx
• Standards: NIST-approved algorithms
• Zero knowledge proofs: Groth16 on BLS12-381

4. Access Control Policy

• Location: /trust/security/access-control.mdx
• Least privilege principle
• Role-based access control (RBAC)
• Quarterly access reviews

5. Incident Response Policy

• Location: /trust/security/incident-response.mdx
• Incident classification
• Response procedures
• Notification requirements

Policy Enforcement Mechanisms:

1. Automated Controls:

• Data retention: Automatic deletion via TTL, cleanup workers
• Access control: Cloudflare Access, GitHub branch protection
• Rate limiting: Cloudflare Workers rate limits
• Logging: Structured logs with sanitisation

2. Code Reviews:

• All code changes reviewed via GitHub pull requests
• Security-focused reviews for cryptographic code
• CI/CD pipeline enforces tests, linting

3. Audit Trail:

• Git history for policy changes (version control)
• Access logs retained 90 days; critical security event logs retained up to 365 days
• Security event monitoring via Cloudflare

4. Public Accountability:

• Policies published at /trust/
• Open source code on GitHub
• Community can verify compliance

Community Standards:

• Provii does not host user-generated content
• Issuers must meet trust requirements
• Verifiers must not discriminate based on age alone
• Wallet users control their own credentials

Evidence

Policy Documentation:

• /trust/security/ - All policies published
• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 343-382) - UC-008: Privacy Governance

Governance Structure:

• ISMS Owner: Overall accountability
• Privacy Officer: Implementation of controls
• Developers: Policy compliance in code

Review Process:

• Annual policy review
• Risk assessments conducted annually
• Management review of ISMS effectiveness

Status

✅ FULLY COMPLIANT

Clear governance structure, published policies, automated enforcement, public accountability.

Standard 7: Default Settings

Requirement: Settings must be ‘high privacy’ by default (unless you can demonstrate a compelling reason for a different default setting, taking account of the best interests of the child).

Maelstrom AI’s Approach

Privacy is NOT Configurable - It’s Automatic

Maelstrom AI goes beyond “high privacy by default” to “privacy is the only option”:

1. No Settings to Configure:

• Privacy is architectural, not a user choice
• Users cannot accidentally reduce their privacy
• No “accept all cookies” equivalent
• No privacy-invasive features exist

2. Automatic Privacy Protections:

• Zero knowledge proofs: Automatic (no opt-in)
• Minimal information disclosure: Automatic (binary age threshold only)
• Unlinkability: Automatic (random IDs per verification)
• Local credential storage: Automatic (wallet architecture)
• IP address hashing: Automatic (server-side)

3. No Privacy-Reducing Options:

• Cannot share DOB (technically impossible)
• Cannot enable tracking (no tracking mechanisms)
• Cannot reduce encryption (all communication TLS 1.3)
• Cannot disable proof verification (required for service)

4. User Control Without Privacy Trade-offs:

• Users control: When to verify, which credentials to use, wallet backup
• Users cannot control: Privacy level (always maximum)

Comparison to Traditional Services:

Evidence

Privacy by Default Implementation:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 256-311) - UC-006: Privacy by Design & Default

Quote:

”#### 2. Privacy as the Default Setting

• ✅ Evidence: System reveals minimum information by default
• Implementation: Proofs reveal only binary age threshold (over/under), not actual age or DOB
• No opt-in required: Privacy is automatic, not configurable”

Code Evidence:

• provii-crypto/crypto-verifier/src/lib.rs - Proof reveals only cutoff_days (threshold), not DOB
• Zero knowledge proofs mathematically prevent information leakage
• No configuration option to reveal more data

Docs Sandbox Default Posture: The docs interactive sandbox inherits the same “privacy is the only option” design. A developer cannot flip a switch to make the sandbox accept a real DOB, to retain fixture inputs, or to weaken the environment stamping on attestations. See the Children’s Code DPIA for the docs sandbox for the schema-rejection, zero-retention, and synthetic-stamping controls that enforce the default.

Status

✅ EXEMPLARY COMPLIANCE

Privacy is not just the default - it’s the only option. Architectural enforcement exceeds Children’s Code requirements. The docs sandbox inherits the same non-configurable privacy posture.

Standard 8: Data Minimisation

Requirement: Collect and retain only the minimum amount of personal data you need to provide the elements of your service in which a child is actively and knowingly engaged. Give children separate choices over which elements they wish to activate.

Maelstrom AI’s Approach

EXEMPLARY - Architectural Data Minimisation

Provii represents the gold standard for data minimisation through zero knowledge architecture:

What We Collect - Server Side:

1. IP Addresses - Hashed with SHA-256, retained 90 days for anti-abuse only

• Not linked to user identity
• Not shared with third parties
• Automatic deletion after 90 days

2. Credential Nullifiers - One-way cryptographic hashes

• Prevent credential reuse/replay
• Cannot be reversed to reveal DOB
• Not personally identifiable

3. Challenge IDs - Random UUIDs

• Single-use verification session identifiers
• No link to user identity
• Expire after use (5 minutes maximum)

What We DO NOT Collect: ❌ Names ❌ Email addresses ❌ Physical addresses ❌ Phone numbers ❌ Dates of birth (transmitted once during issuance for Pedersen commitment, then immediately discarded; never stored or transmitted during verification) ❌ Identity document numbers ❌ Biometric data ❌ Government-issued IDs ❌ Social security numbers ❌ Financial information ❌ Location data (beyond IP for anti-abuse) ❌ Device identifiers (advertising IDs, fingerprints) ❌ Browsing history ❌ Social connections ❌ Any traditional PII

Client-Side Only (Never Transmitted):

• Date of Birth (DOB) - Transmitted once during issuance for Pedersen commitment computation, then immediately discarded. never stored or logged; not transmitted during verification
• Credential private keys - Never leave device
• Proof generation happens on-device

Data Minimisation by Design:

• Zero knowledge proofs reveal only binary age threshold (over/under)
• No “collect now, minimise later” approach. Collection is architecturally impossible
• Not a policy choice - a cryptographic guarantee

Retention Minimisation:

• IP addresses: 90 days (shortest practical for abuse prevention)
• Challenge records: 5 minutes maximum TTL
• Nonce records: 5 minutes
• No long-term PII storage (none collected)

Evidence

Data Minimisation Architecture:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 32-95) - UC-001: Data Minimisation

Quote:

“Server-Side Processing (Maelstrom AI-Operated Services):

COLLECTED PII: None

NOT COLLECTED:
❌ Names
❌ Email addresses
❌ Physical addresses
❌ Phone numbers
❌ Dates of birth (DOB)
❌ Identity document numbers
❌ Biometric data
❌ Government-issued IDs
❌ Social security numbers
❌ Any traditional PII
```"

Code Evidence:

• provii-verifier/src/security/log_sanitizer.rs (Lines 81-111) - IP address hashing for privacy
• provii-verifier/src/routes/verify.rs - Processes proofs without accessing DOB
• provii-crypto/crypto-verifier/src/lib.rs - Verification reveals only threshold result

Comparison to Traditional Age Verification:

Status

✅ EXEMPLARY COMPLIANCE - GOLD STANDARD

Provii achieves the theoretical minimum for age verification: prove age threshold without revealing any PII. This is the best possible compliance with Standard 8.

Standard 9: Data Sharing

Requirement: Do not disclose children’s data unless you can demonstrate a compelling reason to do so, taking account of the best interests of the child.

Maelstrom AI’s Approach

Zero Data Sharing - Nothing to Share

Maelstrom AI’s approach to data sharing is simple: We don’t collect children’s data, so we have nothing to share.

What Gets Shared - NONE:

• ❌ No PII shared with third parties
• ❌ No data broker partnerships
• ❌ No advertising networks
• ❌ No analytics platforms receiving PII
• ❌ No cross-border data transfers of PII

What Gets Processed by Vendors:

1. Cloudflare (Infrastructure Provider):

• Processes: Encrypted traffic, challenge IDs, zero knowledge proofs
• Does NOT receive: Names, DOBs, identity documents
• Role: Edge network, Workers platform, KV storage
• Privacy: No PII transmitted

2. GitHub (Development Platform):

• Processes: Code, CI/CD pipelines
• Does NOT receive: User data, PII
• Role: Version control, automated builds
• Privacy: No user data involved

3. Stripe (Payment Processing) - For verifier billing only:

• Processes: Verifier billing information (B2B)
• Does NOT receive: User (child) data
• Role: Business payment processing
• Privacy: Children not involved in billing

Issuer Data Flow (Credential Issuance):

• Issuers (banks, government agencies) verify DOB from authoritative sources
• Trust-based issuance: DOB transmitted once to issuer for Pedersen commitment computation, processed ephemerally and immediately discarded
• User receives credential; nullifiers prevent issuer from tracking later usage
• No persistent data sharing between Maelstrom AI and issuers (unlinkable verifications)

Verifier Data Flow (Age Verification):

• Verifier receives: Binary age threshold result (PASS/FAIL)
• Verifier does NOT receive: DOB, actual age, credential details
• No data shared back to Maelstrom AI (decentralised verification)
• Verifier cannot track user across sessions (random IDs)

Cross-Border Transfers:

• Only non-PII transferred (ZK proofs, challenge IDs, nullifiers)
• Cloudflare global network = data may traverse borders
• GDPR Chapter V compliance: No PII transferred = minimal risk
• Standard Contractual Clauses with Cloudflare

Evidence

Data Sharing Analysis:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 419-452) - UC-010: Cross-Border Data Transfers
• /trust/compliance/evidence/vendors/third-party-evidence.md - Vendor assessment

Quote:

“What Gets Transferred Internationally:

1. Zero knowledge Proofs - Cryptographic data (not personal data)
2. Challenge IDs - Random UUIDs (not personal data)
3. Credential Nullifiers - One-way hashes (not personal data)
4. IP Addresses - Hashed, minimal retention”

Vendor Governance:

• /trust/security/supplier-management.md - Vendor management policy
• Cloudflare: Data Processing Agreement (DPA), Standard Contractual Clauses (SCCs)

Status

✅ EXEMPLARY COMPLIANCE

Zero PII sharing. Architectural impossibility of sharing children’s personal data.

Standard 10: Geolocation

Requirement: Switch geolocation options off by default (unless you can demonstrate a compelling reason for geolocation to be switched on by default, taking account of the best interests of the child), and provide an obvious sign for children when location tracking is active. Options which make a child’s location visible to others must default back to off at the end of each session.

Maelstrom AI’s Approach

Geolocation - Not Collected or Used

Maelstrom AI does not collect, process, or use geolocation data:

What We Don’t Collect:

• ❌ GPS coordinates
• ❌ Precise location
• ❌ Cell tower triangulation
• ❌ Wi-Fi access point mapping
• ❌ Bluetooth beacon proximity
• ❌ IP-based geolocation (beyond country for rate limiting)

IP Addresses (Limited Geographic Context):

• Purpose: Anti-abuse, rate limiting, DDoS protection
• Granularity: Country-level only (via Cloudflare)
• Retention: 90 days, hashed
• Not used for: Location tracking, geotargeting, analytics
• Not shared with: Third parties, advertisers, verifiers

Mobile Wallet (No Location Permissions):

• Android: No ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION requested
• iOS: No NSLocationWhenInUseUsageDescription or background location
• User cannot accidentally enable location (no feature exists)

Why No Geolocation:

• Not necessary for age verification
• Increases privacy risk without benefit
• Violates data minimisation principle
• Potential for tracking/stalking children

Verifier Location Context:

• Verifiers may use IP geolocation for compliance (e.g., alcohol laws vary by state)
• This is verifier’s responsibility, not Maelstrom AI’s
• Maelstrom AI does not provide location data to verifiers

Evidence

Privacy Architecture:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 586-641) - “What’s NOT Collected”

Quote:

”``` ├─ Behavioural Data │ ❌ Browsing history │ ❌ Search queries │ ❌ Location history │ ❌ App usage patterns │ ❌ Social connections

Code Evidence:

• provii/ - No location permission requests in Android or iOS manifests
• provii-verifier/src/routes/challenge.rs (Lines 213-221) - IP extraction for anti-abuse only

Mobile App Permissions (Android):

<!-- NO location permissions requested -->
<!-- Only permissions: INTERNET, CAMERA (for QR codes) -->

Status

✅ EXEMPLARY COMPLIANCE

Geolocation not collected. Goes beyond “off by default” to “architecturally excluded.”

Standard 11: Parental Controls

Requirement: If you provide parental controls, give the child age-appropriate information about this. If your online service allows a parent or carer to monitor their child’s online activity or track their location, provide an obvious sign to the child when they are being monitored.

Maelstrom AI’s Approach

Parental Controls - Enabling, Not Providing

Provii does not provide direct parental controls because:

1. Provii is infrastructure, not a consumer-facing service
2. Age verification is typically one-time per service
3. Wallet is user-controlled (parent or child can manage)

What Provii Enables for Clients:

Clients using Provii can implement parental controls while preserving privacy:

1. Age-Gated Access:

• Verify child is under 13 - Require parental consent (COPPA)
• Verify child is 13-17 - Apply high privacy settings (Children’s Code)
• Verify adult (18+) - Standard settings

2. Privacy Respecting Monitoring:

• Parents can control child’s device access to services
• Provii proves age without revealing it to parent
• No centralised monitoring dashboard (privacy preserving)

3. Wallet Management:

• Parents can hold wallet for young children
• Transfer control to child at appropriate age
• No remote monitoring (local control)

Transparency for Children:

• If parent controls wallet: Child knows (physical device access)
• If parent uses device management: OS-level transparency (not Provii-specific)
• If service applies parental controls: Service’s responsibility to notify

What Provii Does NOT Do:

• ❌ No remote monitoring by Maelstrom AI
• ❌ No parental dashboard showing child activity
• ❌ No location tracking for parents
• ❌ No screen time reporting
• ❌ No content filtering

Recommendation for Clients: When implementing parental controls using Provii age verification:

1. Clearly notify child when parental controls are active
2. Age-appropriate explanation of what is monitored
3. Option for parent-child conversation about controls
4. Respect increasing autonomy as child ages

Evidence

Wallet Architecture:

• /trust/core/provii-mobile.mdx - Wallet is user-controlled, local storage
• User controls when to generate proofs
• No central database for parent access

Privacy by Design:

• System cannot monitor because no tracking exists
• Parents cannot access something Maelstrom AI doesn’t have

Client Guidance (Recommended): For services using Provii:

• Implement age-appropriate parental controls at application level
• Use Provii age verification to determine which controls apply
• Transparently notify children per Standard 11

Status

🟡 NOT APPLICABLE (Enabling Standard)

Provii is infrastructure that enables clients to implement compliant parental controls. Direct applicability to Provii: N/A. Applicability to clients using Provii: Clients’ responsibility with Provii’s age verification as enabling technology.

Standard 12: Profiling

Requirement: Switch options for profiling off by default (unless you can demonstrate a compelling reason for profiling to be on by default, taking account of the best interests of the child) and only allow profiling if you have appropriate measures in place to protect the child from any harmful effects (in particular, being fed content that is detrimental to their health or wellbeing).

Maelstrom AI’s Approach

Profiling - ARCHITECTURALLY PREVENTED

Maelstrom AI’s approach to Standard 12 is that profiling is architecturally prevented by design:

Why Profiling is Impossible:

1. No Personal Data Collected:

• Cannot profile without data
• No names, ages, locations, behaviours, interests
• Only cryptographic proofs processed

2. Unlinkability:

• Random IDs per verification
• Cannot connect verifications to same user
• Cannot build profile over time

3. Zero Behavioural Data:

• No browsing history
• No search queries
• No content interactions
• No social connections
• No purchase history

4. Minimal Information Disclosure:

• Only reveal: “User is over threshold” (binary)
• Do not reveal: Actual age, DOB, identity, demographics

Comparison to Profiling-Capable Systems:

What About Issuers/Verifiers?:

• Issuers. Cannot profile users due to trust-based issuance with nullifiers (no persistent user identifiers)
• Verifiers. Receive only binary age result, cannot build profiles
• Provii. Sees only unlinkable cryptographic proofs

Automated Decision-Making:

• Age verification is deterministic cryptographic check, not profiling
• No machine learning models
• No predictive analytics
• No “similarly situated users” comparisons

Evidence

Profiling Analysis:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 454-482) - UC-011: Automated Decision-Making

Quote:

“Maelstrom AI does NOT engage in automated decision-making as defined by GDPR Article 22 because:

1. No Profiling: System doesn’t build user profiles or predict behaviour
2. No Legal Effects: Age verification results don’t have legal or similarly significant effects
3. Human Oversight Available: Verifiers can implement manual review if desired
4. User Control: Users choose when to generate and submit proofs”

Architectural Evidence:

• No user database (no profiles to store)
• No analytics platform (no behaviour tracking)
• No recommendation engine (no content personalisation)
• No advertising integration (no ad targeting)

Code Evidence:

• provii-verifier/src/routes/verify.rs - Processes proofs, no profile building
• No machine learning models in codebase
• No data science / analytics pipelines

Status

✅ EXEMPLARY COMPLIANCE - NOT APPLICABLE (IMPOSSIBLE)

Profiling is architecturally prevented by design. This is a strong form of compliance: the mechanism for profiling is not present in the system rather than merely disabled by default.

Standard 13: Nudge Techniques

Requirement: Do not use nudge techniques to lead or encourage children to provide unnecessary personal data, weaken or turn off their privacy protections, or extend their use.

Maelstrom AI’s Approach

No Nudge Techniques - Minimal Interaction Design

Provii’s wallet and verification flow are designed for function over engagement:

What We Don’t Do:

• ❌ No dark patterns
• ❌ No manipulative design
• ❌ No “privacy dialogs” with biased options
• ❌ No emotional manipulation (“Your friends are sharing!”)
• ❌ No timed pressures (“Limited time offer!”)
• ❌ No gamification of data sharing
• ❌ No rewards for reducing privacy
• ❌ No social proof manipulation
• ❌ No default-to-share toggles
• ❌ No hidden privacy settings

Wallet UX Principles:

1. Clarity:

• Simple, direct language
• No confusing options
• Clear purpose for each action

2. User Control:

• User initiates all actions
• No automatic data sharing
• Easy to understand what happens

3. No Extended Engagement:

• Age verification is one-time per service
• No reason to return to wallet daily
• No social features or engagement loops

4. Privacy Transparency:

• “Your DOB is sent once during setup, then discarded. never stored” - Clear, upfront
• No hidden data collection
• No “agree to continue” with buried implications

5. No Friction for Privacy:

• Privacy is automatic (no extra steps)
• Cannot accidentally reduce privacy
• No trade-off between functionality and privacy

Specific Anti-Nudge Design:

Client Guidance: Services using Provii should:

• Not nudge children to verify repeatedly (once is enough)
• Not use age verification as engagement mechanic
• Not reward users for sharing data beyond age threshold

Evidence

Wallet Design Philosophy:

• Functional, minimal UI
• Purpose: Age verification only
• No engagement optimisation
• No data collection prompts

Privacy by Design:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 256-311)
• Privacy is automatic, not a choice users must make

No Dark Patterns:

• Open source wallet code on GitHub
• Community can audit UX decisions
• Public accountability for design choices

Status

✅ FULLY COMPLIANT

Minimal interaction design, no engagement optimisation, no data collection prompts, no dark patterns.

Standard 14: Connected Toys and Devices

Requirement: If you provide a connected toy or device ensure you include effective tools to enable compliance with this code.

Maelstrom AI’s Approach

Not Applicable - No Connected Toys/Devices

Maelstrom AI does not manufacture or provide connected toys or devices.

Potential Future Applicability: If Provii were integrated into connected devices (smart speakers, game consoles, IoT toys):

Recommended Implementation:

1. Device-Based Age Verification:

• Device verifies child’s age before allowing access
• No sharing of child’s age with cloud services
• Local credential storage on device

2. Parental Setup:

• Parent verifies during device setup
• Age-appropriate content filtering applied
• No tracking of child’s usage

3. Privacy by Design:

• Device does not transmit child’s PII
• Zero knowledge age verification
• Local processing preferred over cloud

Current Status:

• Wallet app runs on smartphones (general-purpose devices, not toys)
• No IoT integration
• No smart toy partnerships

Evidence

Scope of Operations:

• /trust/security/isms-scope.mdx - Scope: Verification services, wallet app
• No connected toys or devices in scope

Status

🟡 NOT APPLICABLE

Maelstrom AI does not provide connected toys or devices. Standard 14 not applicable to current operations.

Standard 15: Online Tools

Requirement: Provide prominent and accessible tools to help children exercise their data protection rights and report concerns.

Maelstrom AI’s Approach

User Rights Tools - Simplified by Architecture

Maelstrom AI’s zero knowledge architecture makes most data protection rights automatic rather than requiring tools:

Rights Automatically Satisfied:

1. Right to Access (GDPR Article 15):

• Status: Not applicable - no personal data held by Maelstrom AI servers
• User-Held Data: All credentials stored in wallet under user control
• Implementation: Users can export wallet data locally (JSON)

2. Right to Deletion (Article 17 - “Right to be Forgotten”):

• Status: Automatic - no PII to delete
• IP Addresses: Auto-deleted after 90 days
• Challenge Records: 5 minutes active TTL, audit trail auto-deleted after 5 minutes
• Wallet Data: User can delete wallet app (deletes all local credentials)

3. Right to Portability (Article 20):

• Status: Full portability - credentials are standard JSON
• Implementation: Wallet can export credentials
• No vendor lock-in: Cryptographic credentials are portable

4. Right to Rectification (Article 16):

• Status: Not applicable - Maelstrom AI doesn’t store personal data to rectify
• Implementation: Users update DOB in wallet; new credentials auto-generated

5. Right to Restrict Processing (Article 18):

• Status: Not applicable - minimal processing occurs
• Implementation: Users control when to generate and submit proofs

Tools Provided:

1. Wallet Controls:

• View stored credentials
• Delete credentials
• Export wallet data (backup)
• Generate new credentials

2. Transparency Tools:

• View what data is shared during verification (binary age result only)
• See which services have requested verification (local logs)
• Understand privacy guarantees (in-app help)

3. Support Channels:

• Documentation: docs.provii.app
• Email: support@provii.app
• GitHub Issues: Community support
• Response time: 30 days for data subject requests

Concern Reporting:

• Security issues: security@maelstrom.au
• Privacy concerns: privacy@maelstrom.au
• Abuse reports: abuse@provii.app
• Issuer complaints: issuers@provii.app

Age-Appropriate Accessibility:

• Simple wallet interface (no complex menus)
• Clear language (“Delete all data” not “Invoke right to erasure”)
• Help documentation at multiple literacy levels
• Support for parents assisting children

For Clients Using Provii: Services must provide their own tools for:

• Account deletion (service-specific)
• Data access requests (service holds data, not Maelstrom AI)
• Parental control settings (service-specific)
• Reporting concerns about service

Evidence

User Rights Implementation:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md (Lines 219-254) - UC-005: User Rights

Quote:

“Right to Deletion (Article 17 - “Right to be Forgotten”):

• Status: Automatic - no PII to delete
• IP Addresses: Auto-deleted after 90 days
• Challenge Records: 5 minutes active TTL, audit trail auto-deleted after 5 minutes
• Wallet Data: User can delete wallet app (deletes all local credentials)”

Data Retention Policy:

• /trust/security/data-retention.mdx (Lines 144-153) - Data subject request procedures

Wallet Architecture:

• /trust/core/provii-mobile.mdx - User controls documented
• Local credential storage
• User-initiated proof generation

Support Documentation:

• Public documentation at docs.provii.app
• User guides for wallet operations
• Privacy information accessible

Status

✅ FULLY COMPLIANT

Tools provided for user rights. Most rights automatic due to zero-PII architecture. Clear support channels for concerns.

How Provii Enables Client Compliance

Overview

Provii is privacy infrastructure that enables other services to comply with the Children’s Code without collecting children’s PII.

For Gaming Platforms

Challenge: Gaming platforms must comply with Children’s Code for UK players under 18.

How Provii Helps:

1. Standard 3 (Age-Appropriate Application):

• Verify player age without collecting DOB
• Apply appropriate privacy settings based on age threshold
• Differentiate under-13, 13-17, 18+ without storing age

2. Standard 8 (Data Minimisation):

• No need to collect player DOB, ID documents
• Only store: “Verified over 13” or “Verified over 18”
• Reduce data breach risk

3. Standard 12 (Profiling):

• Cannot profile based on exact age (not revealed)
• Reduces profiling risk for children

4. Standard 9 (Data Sharing):

• No DOB to share with advertisers/partners
• Cannot accidentally leak child age data

Example Implementation:

Player Account Creation:
1. User creates account
2. System requests age verification via Provii
3. Player scans QR code, proves age >= 13
4. System stores: "age_verified_13plus: true" (no DOB)
5. Apply Children's Code privacy settings for under-18s

Benefits:

• COPPA compliance (under-13 identification)
• Children’s Code compliance (13-17 high privacy)
• Reduced liability (no child PII stored)

For Social Media

Challenge: Social media platforms must identify children under 13 (COPPA), apply Children’s Code to under-18s.

How Provii Helps:

1. Standard 1 (Best Interests):

• Verify age without creating dossier on child
• No identity theft risk from stored DOBs

2. Standard 5 (Detrimental Use):

• Cannot use age for targeted advertising (age not revealed)
• Cannot sell child age data to brokers (not collected)

3. Standard 7 (Default Settings):

• Identify under-18s, apply high privacy automatically
• No opt-out of privacy for children

4. Standard 13 (Nudge Techniques):

• Cannot nudge children to share age data (already verified)
• One-time verification, not repeated asks

Example Implementation:

Account Setup Flow:
1. User signs up
2. Age verification required
3. User proves age via Provii
4. System applies settings:
   - Under 13: Parental consent required (COPPA)
   - 13-17: High privacy, no targeted ads (Children's Code)
   - 18+: Standard settings
5. No DOB stored, only tier (under13/13-17/18+)

Benefits:

• Automated COPPA compliance
• Children’s Code compliance without PII collection
• Reduced regulatory risk
• User trust (privacy-preserving)

For E-Commerce (Age-Restricted Products)

Challenge: Online retailers selling age-restricted products (alcohol, tobacco, knives, etc.) must verify age.

How Provii Helps:

1. Standard 8 (Data Minimisation):

• Verify customer is 18+/21+ without storing DOB
• No ID document scans stored
• Reduce PII breach risk

2. Standard 9 (Data Sharing):

• No DOB to leak to payment processors, shipping partners
• Cannot accidentally share child data

3. Standard 4 (Transparency):

• Clear communication: “Prove you’re 18+, we don’t see your birthday”
• Build customer trust

Example Implementation:

Checkout Flow (Age-Restricted Item):
1. Customer adds alcohol to cart
2. Age verification required at checkout
3. Customer proves age >= 21 via Provii
4. System records: "age_verified_21plus: true" for this order
5. Order proceeds, no DOB stored in customer profile

Benefits:

• Regulatory compliance (age-restricted sales)
• Reduced PII collection (Children’s Code alignment)
• Customer privacy
• Lower data breach liability

For Streaming Services

Challenge: Streaming platforms must apply age ratings, protect children from harmful content.

How Provii Helps:

1. Standard 3 (Age-Appropriate Application):

• Verify user age, apply content filters
• Differentiate child/teen/adult without storing exact age

2. Standard 12 (Profiling):

• Cannot build detailed age profiles (only thresholds)
• Reduces profiling risk for children

3. Standard 11 (Parental Controls):

• Parents can verify child’s age tier
• Platform applies appropriate content restrictions
• No tracking of child viewing habits to Maelstrom AI

Example Implementation:

Profile Setup:
1. User creates profile for child
2. Age verification via Provii (child or parent)
3. System applies content ratings:
   - Under 13: G, PG only
   - 13-15: Up to PG-13
   - 16-17: Up to R with parental opt-in
   - 18+: All content
4. No DOB stored, only content tier

Benefits:

• Automated age-appropriate content filtering
• Children’s Code compliance
• Reduced PII storage
• Parental control enablement

Technical Differentiation

Provii vs Traditional Age Gates

Compliance Comparison:

Provii Wins: 14 out of 14 applicable standards

Privacy Architecture Comparison

Traditional Age Verification Process:

1. Collect: Full name, DOB, address, ID document scan, selfie
2. Store: All PII in central database
3. Verify: Manual or automated ID check
4. Result: "Verified" + stored PII
5. Risks:
   - Data breach exposes all child PII
   - Identity theft
   - Profiling / tracking
   - Data broker sales
   - Government surveillance

Provii Zero knowledge Process:

1. Collect: DOB transmitted once during issuance (immediately discarded after commitment computation)
2. Store: NOTHING (only cryptographic proofs)
3. Verify: Zero-knowledge proof (binary result)
4. Result: "Verified over [threshold]" + NO PII
5. Risks:
   - Data breach reveals NO PII (none stored)
   - Identity theft: IMPOSSIBLE
   - Profiling: IMPOSSIBLE
   - Data broker sales: IMPOSSIBLE
   - Government surveillance: NOTHING to surveil

Privacy Score:

• Traditional: 2/10 (high risk)
• Provii: 10/10 (minimal risk)

Market Differentiation

For Clients:

1. Regulatory Compliance:

• Children’s Code (UK)
• COPPA (US)
• GDPR Article 8 (EU)
• Future regulations (KOSA, Online Safety Act)

2. Risk Reduction:

• No child PII = no data breach liability
• No profiling = no discrimination claims
• No tracking = no surveillance concerns

3. User Trust:

• Privacy-preserving = user trust
• Open source = verifiable claims
• “We don’t see your birthday” = clear value prop

4. Cost Savings:

• No PII storage = lower compliance costs
• No DSAR handling = lower operational costs

For Maelstrom AI:

1. Unique Positioning:

• Zero knowledge age verification platform
• Privacy-first in age verification market
• Enables compliance for clients

2. Regulatory Advantage:

• Exceeds Children’s Code requirements
• Future-proof for increasing privacy regulations
• Public documentation demonstrates compliance

3. Regulatory Access:

• Children’s Code alignment documented
• Enterprise procurement (compliance requirement)
• Government/education market access

Compliance Matrix

Summary Table

Overall Score: 14/15 Fully Compliant or Exemplary (93.3%), 1/15 Enabling (Parental Controls)

Gap Analysis

Current Gaps

1. Standard 2: UC-186 Technical Enforcement

• Gap. Formal child-focused DPIA is published; the residual gap is that UC-186 compile-time, build-time, and CI-time sandbox isolation layers (layers 1–3) are Planned but not yet operational
• Risk. Low (the runtime isolation layer 4 is deployed; DPIA conclusions will be re-assessed once layers 1–3 are evidenced)
• Recommendation. Complete UC-186 layers 1–3 (Cargo feature flag, build.rs assertion, CI bundle-grep step) and update the Standard 2 status to ✅ Fully Compliant
• Effort. Medium (engineering work already scoped under Phase 0A)
• Priority. Medium (strengthens compliance posture; required before full documentary closure)
• Timeline. Planned Phase 0A delivery

2. Standard 11: Parental Controls

• Gap. Provii does not provide parental controls directly
• Risk. None (infrastructure provider, not consumer service)
• Status. Enabling standard - clients implement using Provii age verification
• Recommendation. Develop guidance for clients on implementing Children’s Code-compliant parental controls
• Effort. Medium (client guidance documentation)
• Priority. Medium (sales enablement)
• Timeline. Planned H2 2026

3. In-Wallet Privacy Notice

• Gap. In-wallet privacy notice not formally documented
• Risk. Low (functionality exists, needs documentation)
• Recommendation. Ensure wallet displays age-appropriate privacy information:
• “Your date of birth is sent once during setup for the special maths, then thrown away. never kept”
• “Maelstrom AI servers cannot see your personal information”
• “Only binary age threshold (over/under) is revealed”
• Effort. Low (UI text update + documentation)
• Priority. Medium (user transparency)
• Timeline. Planned H1 2026

Strengths to Highlight

1. Zero knowledge Architecture (Standards 1, 5, 8, 9, 12)

• Core technical differentiator
• Architectural guarantees > policy promises
• Mathematically provable privacy

2. Privacy by Design (Standard 7)

• All 7 Privacy by Design principles implemented
• Privacy is automatic, not configurable
• No trade-offs between functionality and privacy

3. Radical Transparency (Standard 4)

• Open source code
• Published ISMS
• Public documentation
• Community auditability

4. Data Minimisation (Standard 8)

• GOLD STANDARD compliance
• Architectural impossibility of collecting PII
• Theoretical minimum for age verification

5. Unlinkability (Standards 5, 9, 12)

• Random IDs prevent cross-site tracking
• Profiling architecturally prevented by design
• User privacy preserved across verifications

Recommendations

For Maelstrom AI

1. Complete UC-186 Sandbox Isolation Layers 1–3 (Priority: High)

• Timeline: Planned Phase 0A delivery
• Effort: Engineering work scoped under Phase 0A
• Impact: Closes the residual Standard 2 gap; allows DPIA reassessment and status upgrade to ✅ Fully Compliant

2. Document In-Wallet Privacy Notices (Priority: Medium)

• Timeline: Planned H1 2026
• Effort: 1-2 hours
• Impact: Formalises existing privacy communication

3. Create Client Guidance for Parental Controls (Priority: Medium)

• Timeline: Planned H2 2026
• Effort: 8-16 hours
• Impact: Client compliance support

4. Publish Children’s Code Compliance Statement (Priority: High)

• Timeline: Planned H1 2026
• Effort: 1 hour (this document)
• Impact: Regulatory positioning

5. Engage ICO for Confirmation (Priority: Low)

• Timeline: Planned 2027
• Effort: Moderate (correspondence, potential review)
• Impact: Regulatory validation, market credibility

For Clients Using Provii

1. Implement Age-Appropriate Settings:

• Use Provii to determine age tier (under-13, 13-17, 18+)
• Apply Children’s Code standards to under-18s
• High privacy by default for children

2. Develop Parental Controls:

• Use Provii age verification to enable/disable parental features
• Transparently notify children when monitoring is active (Standard 11)
• Respect increasing autonomy as child ages

3. Minimise Additional Data Collection:

• Use Provii’s zero-PII verification
• Don’t collect DOB separately (redundant, increases risk)
• Store only age tier, not exact age

4. Transparency Communication:

• Explain to users: “We verify your age without collecting your birthday”
• Highlight privacy advantage of Provii integration
• Age-appropriate privacy notices (Standard 4)

5. Document Compliance:

• Create internal compliance documentation
• Reference Maelstrom AI’s Children’s Code compliance
• Include in Data Protection Impact Assessments

Conclusion

Provii as Enabler of Children’s Code Compliance

Provii represents a approach shift in age verification privacy:

From: “Trust us with your child’s data” To: “We mathematically cannot see your child’s data”

Compliance Achievements:

1. 14 out of 15 standards: Fully Compliant or Exemplary
2. Standard 8 (Data Minimisation): GOLD STANDARD - theoretical minimum
3. Standard 12 (Profiling): Architecturally prevented by design
4. Standard 7 (Default Settings): Privacy is the only option, not just default

Business Value:

1. Regulatory Compliance:

• Children’s Code (UK)
• COPPA (US)
• GDPR Article 8 (EU)
• Future-proof for increasing privacy regulations

2. Risk Reduction:

• No child PII = no data breach liability
• No profiling = no discrimination claims
• No tracking = no surveillance concerns
• Architectural guarantees > policy promises

3. Market Differentiation:

• Zero knowledge age verification platform
• Privacy-first positioning
• Public compliance documentation
• Open source verifiability

4. Client Enablement:

• Gaming platforms achieve Children’s Code compliance
• Social media reduces PII collection risk
• E-commerce verifies age without storing DOBs
• Streaming services apply age-appropriate content filters

The Provii Advantage:

“Provii enables Children’s Code compliance not through policy, but through architecture. We don’t promise to protect children’s data - we cannot collect it in the first place. This is privacy by mathematical proof, not by corporate promise.”

Final Assessment:

Maelstrom AI demonstrates exceptional alignment with the UK Age Appropriate Design Code through the Provii zero knowledge architecture that makes privacy guarantees cryptographically provable. We enable other services to verify children’s age without collecting their personal information, thereby helping them comply with the Children’s Code while reducing risk and building user trust.

Compliance Score: 14/15 Standards Fully Compliant or Exemplary (93.3%)

Recommendation: Publish this compliance documentation and complete remaining gaps (UC-186 layers 1–3, in-wallet notices).

Document Information

Document Control:

• Title. UK Age Appropriate Design Code - Compliance Matrix
• Version. 1.1
• Date. 2026-02-13
• Last Updated. 2026-02-13
• Status. Draft for Review
• Classification. Public
• Owner. Privacy Officer
• Next Review. 2026-11-21

Evidence Base:

• Privacy Architecture Evidence (UC-001 through UC-011)
• Age Verification Flow Evidence (UC-083 through UC-093)
• Data Lifecycle Evidence (UC-017, UC-102-105)
• ISMS Policies (Information Security, Data Retention, Cryptography)
• Code Repositories (provii-verifier, provii-crypto, provii-mobile)

References:

1. ICO Age Appropriate Design Code: https://ico.org.uk/for-organisations/guide-to-data-protection/ico-codes-of-practice/age-appropriate-design-a-code-of-practice-for-online-services/
2. Data Protection Act 2018, Section 123
3. GDPR Article 8 (Children’s consent)
4. Maelstrom AI ISMS: /trust/
5. Provii Architecture Documentation: docs.provii.app/overview/architecture
6. Provii Trust Model: docs.provii.app/overview/trust-model

Appendices (Available Separately):

• Appendix A: Detailed Code Evidence for Each Standard
• Appendix B: Client Implementation Guides (Gaming, Social Media, E-Commerce)
• Appendix C: Comparative Analysis (Provii vs Traditional Age Gates)
• Appendix D: Privacy by Design Assessment (7 Principles)
• Appendix E: Data Protection Impact Assessment (DPIA) Template

End of Document