Identity, Profile & Account

Area: 01 Identity, Profile & Account · 6 items · Source: PADI Mobile Scope Alignment v-ceb35f4d Subject: the unified PADI app — Expo React Native. Every verdict below is about what that app can build, not about what today's apps do.

What this card covers, and what it does not

The scope artefact sorts every item into one of three release lanes — Carried forward from web, Q1 2027 Delta, Post Q1 2027. This card is the six items in the Q1 2027 Delta lane: PROF-01, AUTH-06, AUTH-08, AUTH-10, AUTH-11, FAM-01. Each is specified on web and pulled into app scope.

The area also holds six device-side items, ID-01–ID-06. They sit in the Post Q1 2027 lane and are not analysed here.

The artefact's "By feature" view regroups the same items by area rather than by release decision — its own blurb says "Same item set as the release view, sorted a different way." It is a second rendering of one list, not a second list.

Four of the six are already analysed in Identity & Authentication — AUTH-06, AUTH-08, AUTH-10 and AUTH-11. They are carried here with their verdicts restated in one line each, not re-analysed, so the area reads as one page.

Only one of the six has a stated requirement. AUTH-11 has a detail drawer; the other five arrive as a title and a set of flags. Two of those flags are load-bearing and worth naming up front: PROF-01 carries DEP (an API or engineering dependency) and FAM-01 carries SPK — the artefact is explicitly asking for a feasibility check on it.

How to read the evidence in this card

The unified app is a new client. It inherits no code from kms-ios-padi, kms-android-padi, travel-rn or padi.aware.flutter — the first two are being replaced, and none of them is a head start on implementation.

What they are is proof that an endpoint answers a real client holding a real token. That matters when the alternative is a requirement with no named API. Where this card cites another app, read it as "the endpoint is proven callable and the data shape is known" — never as "the work is done".

The exception is a POC: code in poc/ is written in Expo React Native against PADI's real hosts, so it settles the client question as well as the endpoint question.

PROF-01's data model exists — on Travel, not on PADI

The item reads "View and edit preferences such as weight, foot size and gear preferences". That structure is already in production, in PADI Travel:

• The diver's own sizes — height, weight, shoeSize, wetsuitSize, bcdSize, with unit fields, written to account/preferences/account-detail (travel-rn/app/components/form/ProfileAdvancedInputs.js:172-211, ProfileFormNew.js:126-128).
• The same fields server-side, in a section diviac literally names "Equipment info section" (diviac/.../travel_v2/account/serializers/account_profile.py:90-116), exposed at POST/PUT /account/profile/ (account/urls.py:44).
• Units are already modelled — distance_height_unit, weight_unit, shoe_size_unit, driven from /account/preferences/measurements/ (MeasurementUnitsForm.js:92).

The PADI apps have none of it. Their only equipment data is per-dive-log, and it is not sizing: suit_type is an exposure type (fullsuit 3/5/7mm, shorty, semi-dry, drysuit) and weight_type is subjective (light / good / heavy) — kms-ios-padi/PADI/model/view/Equipment.swift:42-70, EquipmentEnums.swift:11-18. Nothing records a diver's sizes.

So the item is not a build question. It is an ownership question: does the unified app adopt Travel's profile model, or does PADI build its own on the gateway? — SCOPE-23.

The cost of each answer is real. Adopting Travel's puts diver preferences in a different auth realm from profile, certifications and membership, which pulls the second realm of SCOPE-7 into a settings screen. Building PADI's own duplicates a model that already works.

Answering this also settles two post-Q1 items. ID-05's gear half and ID-06 resolve to the same Travel structure — in Travel a buddy record is a diver record. The decision should be taken once, with that in view, rather than three times.

PROF-01 — View and edit preferences such as weight, foot size and gear preferences

Flags PRK parking, Q1 delta, DEP Verdict for the unified app: buildable — but not until someone says which platform owns the data. API status: Existing — web

What the unified app has to deliver

A settings screen where a diver enters their height, weight, shoe size, wetsuit and BCD size in their own units, and has those values available to the rest of the app.

What it can rely on

The whole model is already served, with units, by PADI Travel — the fields, the serializers and the endpoints cited above. A client that holds a Travel JWT can read and write them today. Nothing has to be designed; the shape is settled by a working implementation.

What the unified app has to build

Small, if the answer is Travel: a form, unit conversion at the edges, and the screen itself. The real cost is not the screen — it is the token. The Travel realm needs a Travel JWT, not the Cognito idToken the rest of the app carries, so this one settings screen obliges the app to hold and refresh a second auth realm (AUTH-02, SCOPE-7). That is architecture work the app would otherwise defer.

If the answer is instead that PADI builds its own, the app's work is unchanged and the wait is on PADI — the fields are well specified by Travel's implementation and could be lifted wholesale.

What blocks it

Nothing in availability. The DEP flag is correct but misleading: the dependency is an ownership decision, not a missing endpoint (SCOPE-23). Reading sizes from Travel while profile, certifications and membership come from the PADI gateway splits a diver's identity across two realms and two data models — a decision with consequences well beyond this item.

Parked, and rightly so — not because it is hard, but because building it commits the app to an answer nobody has given.

Questions: SCOPE-23 (adopt Travel's model, or build PADI's) · SCOPE-7 (does Q1 include the Travel realm)

AUTH-06 — Login using biometrics, passkeys, MFA, magic links and federated login

Flags Q1 delta, DEP Verdict for the unified app: one of the five features ships; four wait on PADI. API status: Gap (partial)

Analysed in full under Identity & Authentication.

For the unified app: five features under one ID with three different answers. Biometric unlock is pure client work — no PADI API at any point — so the app can ship it in Q1 on its own schedule. Passkeys, magic links and federated login are PADI platform builds the app can only consume. MFA depends on whether the auth facade surfaces Cognito's challenge flow at all. Estimating this as one item prices four unknowns alongside one certainty — split it (SCOPE-11).

AUTH-08 — Delete / recover account

Verdict for the unified app: cannot be delivered — there is nothing to call. Flags PRK parking, Q1 delta · API status: Gap

Analysed in full under Identity & Authentication.

For the unified app: there is no deletion endpoint to call. Today's apps fake it by emailing a human, using hardcoded admin credentials pointed at staging hosts from production builds — a path the unified app must not reproduce, and one that wants fixing in the current apps regardless (INT-5).

AUTH-10 — Comply with GDPR and local data requirements on account creation

Verdict for the unified app: cannot be delivered — the platform it would call does not exist. Flags PRK parking, Q1 delta · API status: Gap

Analysed in full under Identity & Authentication.

For the unified app: the only consent the registration API accepts is optIn: Boolean. There is no consent platform to record against, no policy versioning, no acceptance record — so the app cannot be made compliant by building a screen. One of five items across three cards resting on that same absent capability; estimate it once as SCOPE-13, not five times.

AUTH-11 — Parent-Signed Waivers for Child Profiles

Verdict for the unified app: cannot start — a legal prerequisite gates it, not an engineering one. Flags DSC discuss, Q1 delta · Jira E28 · Impact High · Effort Low · API status: Blocked

Analysed in full under Identity & Authentication.

For the unified app: PADI Legal sign-off is a stated, non-negotiable prerequisite, so no amount of client readiness starts this. Document storage exists (TrueVault); signature capture, consent-scoped sharing and the family data model do not. And it cannot be built before FAM-01 below, which is itself blocked.

FAM-01 — Create a child account linked to an adult account

Verdict for the unified app: cannot be delivered — the relationship it would create has nowhere to live. Flags Q1 delta, SPK · API status: Gap

The one item in this area the artefact explicitly flags for a feasibility check, and the only Family item targeted at Q1. This is the answer to that flag.

What the unified app has to deliver

A parent, signed in, creates an account for their child and thereafter manages it from their own — the child appearing in the parent's app as someone they are responsible for.

What it can rely on

Two primitives, and neither carries the feature:

• guardianEmail on SignUpRequest (kms-android-padi/.../data/api/request/SignUpRequest.kt)
• custom:guardian_email as a Cognito claim (kms-ios-padi/PADI/data/params/IDToken.swift:11-50)

Both let a client notify a guardian during registration. Neither links two accounts. There is no parent–child relationship, no roster, no role model, and no endpoint that creates an account on another account's behalf. The unified app has nothing to call and nothing to read back.

What blocks it

The artefact says the model is broken, in its own words. FAM-06, in the same card, is titled "Parent–Child Data Model Fix" — and it is sequenced after this item. So the scope list asks the app to create a child account in Q1 and to fix the model that would hold it later (SCOPE-24).

And it does not fail alone. A minor's account needs consent and age handling — the AUTH-10 gap — and a signed waiver — the AUTH-11 block. Three of this card's six items converge on the same missing family substrate, which is PADI's to build.

Verdict. Not buildable, and the SPK flag was warranted. The finding to put back to the client is the ordering: FAM-01 sits ahead of its own prerequisite, and that should be raised before anyone estimates it.

Questions: SCOPE-24 (can FAM-01 precede FAM-06) · PADI-9 (consent records) · PADI-16 (waiver storage)

Summary

Only one of the six is limited by anything the app does. The other five are waiting on platform PADI has not built or decisions PADI has not taken — so client-side estimates for them would price the smallest part of the work, and in three cases would price work that cannot begin.

And one of the six needs no PADI API at all. AUTH-06's biometric unlock is device capability end to end. It is the only thing on this card the unified app can deliver on its own schedule, and it is currently buried inside an item whose other four features are blocked.

What has to be answered

1. Whose profile model? (SCOPE-23) PROF-01 resolves to Travel's diver structure, in a different auth realm from everything else the app holds. One answer settles this item and two post-Q1 ones with it — and it decides whether Q1 has to carry a second token lifecycle.
2. Can FAM-01 precede FAM-06? (SCOPE-24) The artefact targets create a child account at Q1 and "Parent–Child Data Model Fix" after it.
3. When does the consent platform exist? AUTH-08 and AUTH-10 are two of five items across this study resting on the same absent system. Estimate it once, as SCOPE-13.

Three of the six converge on one missing substrate

FAM-01 needs a parent–child relationship model. A minor's account then needs consent handling (AUTH-10) and a signed waiver (AUTH-11, blocked on PADI Legal). None of the three is independently deliverable by anyone, and the artefact sequences FAM-01 ahead of the FAM-06 fix it depends on. That ordering should be raised before any of it is estimated.