Six cards in. The Q1 subset holds.

Feasibility for the unified Expo React Native app. The question per item is not what today's apps do — it is whether an endpoint already exists that the new client can call.

Logged In Experience15 items

Ten of fifteen have an endpoint today — three proven by the current mobile apps, seven by PADI web front ends. None is unconditional. Select a verdict to filter the board.

15 IDs, 13 distinct capabilities. MYP-07/PREF-02 and MYP-09/PREF-03 are each one capability under two identifiers. Estimating all 15 rows separately double-counts two of them. MYP-10 and MYP-12 look like a pair but resolve to different endpoints — separate builds.

The gaps: three hold, one withdrawn

Every gap claim was re-tested against the spec, the live-tested matrix, the web capture and the four repos, on the principle that we cannot call something a gap if PADI already serves it. Three hold. The fourth — membership billing history — is withdrawn to unverified: the endpoint that would carry it is GraphQL, and field absence cannot be asserted without introspecting the schema.

Two checks stand between this and a defensible gap list, both minutes of work with a valid idToken: introspect pros/graphql, and read GET /v2/courses/{packageId}/details. Until then MYP-05's billing gap should not be put to PADI as a demand.

Identity & Authentication12 items

Only five are in Q1 2027 — and all five are buildable today, none needing a new PADI API. Two of them looked like gaps until it was established that the app already calls AWS Cognito’s API directly, which puts ChangePassword, GlobalSignOut and RevokeToken within reach by a proven path. What PADI owes here is a two-line configuration answer (PADI-11), not development.

AUTH-07 does not exist — the IDs run 01–06 then 08–13. And no item on this card carries SPK or DEP, where all fifteen in Section 1 carried both: the artefact treats identity as settled. For AUTH-01–05 that is right. For AUTH-06 it hides five features with three different answers, and for AUTH-08 it hides a production defect.

Content pages4 items

All four are confirmed for Q1 2027 by the artefact. Only one is buildable. Every claim here was probed live against the public URLs on 2026-09-10 rather than inferred — legal pages need no auth, so there was no excuse not to.

Ten of the app’s twelve languages already have a localised privacy policy live on the web — ar de es fr it ko nl zh-hans all return 200 at padi.com/{lang}/privacy. The app requests none of them: the URL is hardcoded English. Japanese and Hebrew are the two real holes (both 404), and Japanese is the one language the current client bothers to branch on.

And a diver agreeing to the privacy policy at account creation is clicking a dead link — href="#" in the consent copy on both the registration and China PIPL screens (INT-7).

Universal Finder6 items

Every one carries PRK — the client has not given direction. That is the right posture for a product decision and the wrong conclusion about feasibility: five of the six are already built and running in production, three of them proven from a PADI mobile app. The card is not waiting on discovery. It is waiting on one question: Drupal or Diviac (SCOPE-18).

The tension to put to the client. FIND-01/02/03 are scoped as new Drupal 11 content types while a production equivalent — Django, Elasticsearch, place hierarchy, maps, autosuggest — runs on travel.padi.com, and the PADI app’s Dive Shop Locator already links into it. FIND-01’s scope defers that integration to Phase 2 without saying why. That is a build-versus-reuse decision nobody has stated as one.

Identity, Profile & Account6 items

The Q1 2027 Delta lane for this area — six items specified on web and pulled into app scope. The area’s six device-side items, ID-01–ID-06, sit in the Post Q1 2027 lane and are not on this card.

Only one of the six is limited by anything the app does. The other five wait on platform PADI has not built or decisions PADI has not taken — so a client-side estimate would price the smallest part of the work, and in three cases work that cannot begin. Three of them converge on one missing substrate: FAM-01 needs a parent–child model, a minor’s account then needs consent (AUTH-10) and a signed waiver (AUTH-11) — and the artefact sequences FAM-01 ahead of the FAM-06 fix it depends on (SCOPE-24).

And one needs no PADI API at all. AUTH-06’s biometric unlock is device capability end to end — the only thing on this card the app can deliver unblocked, currently buried in an item whose other four features are not (SCOPE-11).

PROF-01 is an ownership question, not a build question. Its whole data model — diver sizes with unit handling — already runs on PADI Travel, in a different auth realm, while the PADI apps record no sizes at all. So the app can build the screen cheaply; what it cannot decide is whether doing so commits Q1 to carrying a second token lifecycle (SCOPE-23, SCOPE-7). The same answer settles two post-Q1 items, so it should be taken once.

Certifications & eCard2 items

The Q1 2027 Delta lane for area 02. Its other five items are Post Q1 2027, and two more — MYP-03, MYP-10 — are carried forward and analysed under Logged In Experience. CERT-04 does not exist, the same discontinuity as AUTH-07.

CERT-01 is the most de-risked item in this study. It is the area’s only Now flag — confirmed for Q1 — and the offline behaviour is already implemented on the unified app’s own stack: padi-cert-offline-poc is Expo + Realm with a unit-tested reconcile core, archive-not-delete durability and the stale-eCard fix built in. What is left is integration — lift the sync core, pin the field mapping, source a real token. Certifications are read-only, so the app needs a cache here, not a write queue — which is why PLT-01 should be scoped knowing this area consumes only its read half.

CERT-05 is not an engineering problem for the app. Presenting a pass is routine work in Expo RN and the data is already on the device from CERT-01. But a client cannot mint a wallet pass — an .pkpass needs an Apple-issued signing certificate, a Google object a signed JWT from an issuer account — and nothing in eleven web repositories signs one (PADI-25). The IAP flag has a concrete cause too: the eCard purchase link-out is built and commented out at every call site, button hidden — the signature of a store-policy problem the unified app will meet identically, and the same decision PADI-7 has left open since April.

Findings that govern every item

One missing system, five items

MYP-09, PREF-03, AUTH-08, AUTH-10 and LEGAL-04 all resolve to the same absent capability — consent capture, policy versioning, acceptance records, data export and erasure. The source says “Privacy systems not documented.” Four separate estimates would be four guesses at one unknown; estimate the platform once (SCOPE-13).

Much of this is already built

Four proofs-of-concept sit in poc/, three of them on the target stack — Expo ~57 / RN 0.86 / React 19. Where one exists it is the strongest evidence in this study, because it settles feasibility independently of whether an endpoint path later changes.

Most of this scope is undecided, and that is how to read the verdicts. Of the artefact’s 146 items, 58 are parked and only 26 are confirmed for Q1 2027. Parked items move — paths get renamed, structures change, and PADI-1 says an unknown subset is being rebuilt regardless. So a verdict here is not a claim that a URL survives. It is a claim about capability, resting on what the existing apps and web front ends already do, and on what we have proven ourselves.

The evidence base: web-source

Step 2 of the test used to be answered from a browser capture — the weakest usable class. existing-web-apps/ holds eleven web repositories, so it can now be answered from source, cited to file:line. That has already overturned verdicts on MYP-05, AUTH-11 and AUTH-13.

And it closes PADI-20. The November 2026 front end reads Drupal at {locale}/jsonapi/{path} with no authentication on published content (padi.com/src/shared/services/drupal.ts:19-21). Any content type the web team builds is readable by the unified app, in every language, the day it ships.

No PADI-authored API contract exists

Every "target API" in this study is Axelerant's own discovery — endpoints captured from the browser Network tab and cross-checked against the PadiWW source. Documentation was requested from PADI on 2026-04-24 and asked for again on 2026-07-13. None appears in the corpus. Treat every target endpoint as observed behaviour, not a commitment.