Content pages — Legal & compliance

Card: Content pages · 4 items · Source: PADI Mobile Scope Alignment v-ceb35f4d Consumer: the unified PADI app — Expo React Native, shipping as an update to the existing PADI main app.

This card pairs with Communications (COMM-01) in the reading order; COMM-01 is not covered here.

All four items are W26 parity and carry the Now chip — the whole card is confirmed for Q1 2027. None has a detail drawer, and none carries SPK or DEP. On the artefact's reading this is the most settled card in the study.

It is not. One of the four is buildable today, one has no page to link to, one is a category error on mobile, and the fourth is where the real work is.

The test

1. Does the existing mobile app call an endpoint / open a page for this? → usable.
2. If not — does a PADI web property serve one? → usable.
3. Only if neither → a genuine gap PADI must close.

For this card step 2 is unusually cheap to check, because legal pages are public URLs with no auth. So rather than infer, every claim below was probed live on 2026-09-10.

What the apps do today

One legal page exists, and it is a webview link. Not four.

Reached from More → About → Legal → Privacy — legalHeadingView and privacyItemView at MoreAboutViewController.swift:135-154, opening an in-app browser at :210-211. Android's equivalent is MoreNavigation.kt:204, plus the registration screen at AuthNavigation.kt:54 and the China dialog at MainScreen.kt:163.

No Terms of Use, no Cookie Policy, and no legal index appears anywhere in either codebase.

There is no content API. Nothing in either app consumes a CMS. pro-cms.padi.com is in the iOS host registry (Configuration.swift:62-63) but is used only as a host comparison when deciding how to handle a webview navigation (PDWebViewController+Helpers.swift:55) — it fetches no content. Legal text reaches the diver as a rendered web page or not at all.

The localisation finding — the sharpest thing in this card

The app supports 12 languages. Language.swift:27-38: English, Dutch, French, German, Italian, Spanish, Japanese, Korean, Chinese Simplified, Chinese Traditional, Arabic and Hebrew — the last two right-to-left.

The app serves one privacy policy, in English, to all of them. The URL resolver branches Japanese-vs-everything (WebViewInputType.swift:99-106), and .privacy has no Japanese case, so it falls through default: return enUrlString. Every diver outside China reads the English policy regardless of the language they set.

But localised policies already exist. The English page links to them itself, and they resolve — probed live, 2026-09-10:

Chinese Traditional is served off separate domains the English page links to — padi.com.cn/zh-hant/privacy and padi.com.tw/zh-hant/privacy.

So this is a client defect with a ready fix, not a gap. The URL is a template: https://www.padi.com/{lang}/privacy. Ten of the app's twelve languages are already served and simply not requested. Japanese and Hebrew are the two real holes — and Japanese is the one language the current app bothers to branch on.

POC coverage: none, and that is the right answer

No proof-of-concept touches this card, and none is needed. Opening a URL in an in-app browser is not a feasibility question — the current apps already do it, and LEGAL-01 is the one item here that is genuinely just that.

Where a POC would earn its place is LEGAL-04: versioned documents, a recorded acceptance, and a re-acceptance prompt when a version changes. That is real client work over a platform capability that does not exist yet, and it is the part of this card worth a spike once PADI-21 is answered.

LEGAL-01 — Privacy Policy

Area 01 Identity, Profile & Account · Flags W26 parity, Now API status: Existing — mobile · Feasibility: buildable today; fix the locale while you are there

What it needs. A reachable, current privacy policy.

Available. https://www.padi.com/privacy — live-probed 200, public, no auth. Mobile-proven on both platforms. Plus the ten localised variants above.

Gap. None. This is the most straightforwardly buildable item in the study so far.

Notes for the RN client.

• Request /{lang}/privacy from the diver's selected language, falling back to /privacy on a 404 — which is what Japanese and Hebrew will do until PADI publishes them (PADI-19).
• Collapse the two iOS constants. WebViewPrivacyURL and RegisterPrivacyPolicyUrl are the same page with a stray trailing ?. Two constants for one document is how they drift apart.
• Keep the China path separate and deliberate. The .com.cn assets are static HTML on Alibaba OSS Beijing (DNS: ecards-h5.oss-cn-beijing.aliyuncs.com). They did not respond from outside China during probing — 000, no HTTP response — which is expected for that host and inconclusive, not evidence they are broken. Note that www.padi.com/zh-hans/privacy now returns 200, so whether the separate .com.cn files are still needed is worth asking (PADI-18).
• RTL layout: Arabic and Hebrew are app languages. A webview handles direction itself; a native rendering would not, for free.

Verdict. Buildable now. Recommend it for Q1 with the locale template — carrying the hardcoded English URL forward would ship a known defect into a new app.

Questions: PADI-19 (Japanese and Hebrew policies) · PADI-18 (is the .com.cn path still required)

LEGAL-02 — Terms of Use

Area 01 · Flags W26 parity, Now API status: Gap · Feasibility: nothing to link to yet

Confirmed absent from the apps. No Terms of Use URL, screen, string or link in either codebase.

And — probed live — absent from the web too. Every candidate path 404s on the main property:

The only Terms page in the estate belongs to PADI Adventures, a different property with different commercial terms. It is not the main PADI Terms of Use and should not be linked as though it were.

Separately, the app does contain a ~4,000-word eLearning parent/guardian Terms and Conditions — hardcoded as a single string in strings.xml:1074 (padi_term_condition). That is a different document: consent for enrolling a minor, not terms of use for the app. It is treated under LEGAL-04.

Gap. The page itself. This is a web dependency, not a mobile one — the Nov 2026 launch has to publish a Terms of Use before the app can link to one. Mobile's share is a row in a list.

Verdict. Not buildable, and not Axelerant-mobile's to fix. The item is confirmed Now for Q1 2027 while the artefact it points at does not exist. Raise it as a web-side prerequisite rather than a mobile estimate — and note it is cheap to close on the mobile side the moment a URL exists.

Questions: PADI-18 (will a Terms of Use exist at launch, and at what URL)

LEGAL-03 — Cookie Policy

Area 01 · Flags W26 parity, Now API status: Gap · Feasibility: buildable as a link; questionable as a requirement

Confirmed absent from the apps, and probed absent from the web — www.padi.com/cookie-policy and /cookies both 404.

The more useful observation is that this item does not survive the crossing intact. Cookies are a browser storage mechanism. A React Native client has no cookie jar in the sense a cookie policy describes; it has:

• iOS: the IDFA and App Tracking Transparency. The current app already ships a privacy manifest declaring NSPrivacyCollectedDataTypeTracking (PADI/PrivacyInfo.xcprivacy) — Apple requires it, and it is the platform's own disclosure surface.
• Android: the advertising ID and the Play Data Safety declaration.
• Both: SDK telemetry. Datadog is present and initialised with TrackingConsent.GRANTED hardcoded (PadiApplication.kt:318) — analytics consent asserted in code rather than asked for.

So "Cookie Policy" carried to mobile as parity is a category error: the document is about a mechanism the app does not use, while the disclosures the app does owe — tracking identifiers, ATT, Data Safety — are not what the item names.

That hardcoded TrackingConsent.GRANTED is the substantive issue hiding under this item, and it belongs with the consent platform (PADI-9), not with a cookie page.

Verdict. As written, not buildable and arguably not meaningful. Recommend recasting it as a tracking-and-telemetry disclosure appropriate to a native app, and scoping the ATT/Data Safety work explicitly (SCOPE-16). If PADI publishes a cookie policy for the web and simply wants it linked, that is one row in a list and trivially done — but it should be a deliberate choice, not parity by default.

Questions: SCOPE-16 (recast for mobile, or link the web page as-is) · PADI-9 (consent platform)

LEGAL-04 — Legal & compliance pages

Area 01 · Flags W26 parity, Now API status: Gap · Feasibility: the delivery mechanism is the work, not the pages

This is the item that matters, and its title hides that.

What exists. A Legal heading in More → About with one child (Privacy). Two hardcoded China PIPL documents. One enormous hardcoded T&C string. No index, no versioning, no update path.

Three defects, all confirmed in source:

1. Legal text is compiled into the binary. strings.xml:1074 holds ~4,000 words of eLearning parent/guardian Terms and Conditions — including COPPA language and an acceptance clause — as a single Android string resource. Changing a word of it requires an app release and store review. For a document PADI Legal owns, that is the wrong medium.
2. The consent copy links nowhere. strings.xml:637 — "By creating a PADI account, you are agreeing to our <a href="#">Privacy Policy.</a>" — and strings.xml:1152, the China PIPL agreement, use the same href="#" placeholder. A diver is asked to agree to a policy behind a dead link at the moment of account creation. That is the single most raiseable defect in this card.
3. Nothing records what was accepted. No policy version identifier, no acceptance timestamp, no record of which language the diver was shown. The only consent captured at registration is optIn: Boolean on SignUpRequest. So there is no way to answer "which version of the privacy policy did this diver accept, and when" — which is the question that matters when a policy changes.

Gap. Not the pages — the governance: a versioned, localised, remotely-updatable set of legal documents, plus a record of acceptance and a re-acceptance prompt when a version changes.

The pages themselves can come from the web (LEGAL-01 proves the pattern works). What is missing is everything around them, and defect 3 is the same missing consent platform as MYP-09, PREF-03, AUTH-08 and AUTH-10 — the fifth item to land on it.

Notes for the RN client. Two viable shapes, and it is a real decision (SCOPE-17):

• Webview list — a Legal screen listing documents, each opening www.padi.com/{lang}/{doc} in an in-app browser. Cheap, always current, inherits the web's localisation and RTL handling. Loses offline access, which matters given PLT-01 is committed and divers are frequently offline.
• Native rendering from a content API — and this is now available. The November 2026 front end reads Drupal at ${BASE_URL}/{locale}/jsonapi/{path} with no authentication on published content (padi.com/src/shared/services/drupal.ts:19-21). So a legal page modelled as a Drupal node is readable by the unified app, in every Crowdin language, the day it ships. Gains offline caching and consistent styling; costs nothing PADI has to build.

Recommend the webview list for Q1 with the locale template — it is cheaper and inherits RTL handling for Arabic and Hebrew. Native rendering is now a real option rather than a blocked one, and worth revisiting once the legal pages are actually modelled in Drupal.

Verdict. Not buildable as specified, because "legal & compliance pages" as written asks for pages while the actual need is versioning and acceptance records. Split it: the link list is buildable now; the acceptance and versioning belongs with the consent platform.

Questions: PADI-21 (policy versioning and acceptance records) · SCOPE-17 (webview list or native rendering) · INT-7 (dead links and the hardcoded T&C)

Summary

One of four is buildable. The artefact marks all four confirmed for Q1 2027.

That is the finding to carry to the readout, and none of the three shortfalls is a mobile engineering problem:

• LEGAL-02 Terms of Use — the page does not exist, on any PADI property except Travel. Probed, not assumed. A web-side prerequisite; mobile's share is one row in a list.
• LEGAL-03 Cookie Policy — no page exists, and the document describes a browser mechanism the app does not use. Recast it as tracking/ATT disclosure or drop it.
• LEGAL-04 Legal & compliance — the pages are the easy part. Versioning, localisation and acceptance records are the requirement, and the acceptance half is the consent platform that now blocks five items across three cards.

What mobile should fix regardless of scope decisions:

1. The dead href="#" links in the account-creation and China PIPL consent copy (strings.xml:637, :1152). A diver agreeing to a policy they cannot open.
2. The hardcoded English privacy URL. Ten of the app's twelve languages already have a localised policy live on the web; the app asks for none of them.
3. ~4,000 words of legal text compiled into the binary (strings.xml:1074), changeable only by shipping a release.

Two questions close most of this card, and both are for PADI rather than us: will Terms of Use and a Cookie Policy exist at the November launch and at what URLs (PADI-18), and will Japanese and Hebrew privacy policies be published (PADI-19).