Coaching consumer requirements for the unapproved Person-resolution draft
Coaching reviewed Platform's local docs/coordination-drafts/contracts/identity/coach-person-resolution-api.md and docs/coordination-drafts/contracts/service-auth/adr-0051-v1.6.0-amendment.md. This is review feedback on an unpublished draft, not acknowledgment of that interface version. The earlier ADR position remains distinct. No interface or mapping event is cleared.
Consumer requirements
Both current creation actions accept a single name and phone; the visible console form exposes one Name field. Requiring given_name and family_name is viable only with explicit structured inputs in Coaching. Coaching must not silently split a full-name string or invent a family name. Please document whether single-part names are intentionally unsupported in v1 and their validation outcome. If that limitation is intended, Coaching will show the two required fields and fail validation before any identity request when a required value is missing. The form adaptation is Coaching work; it does not justify weakening Platform's compatible-name rule.
The published retry contract needs a precise operation lifecycle. An unknown result after timeout, connection loss, or 5xx means Coaching must retain the exact submitted identity request and key, reconcile it through identical POST replay, and prohibit a different request under that key. Reload, navigation, token refresh, an action retry, or a failed local Coach transaction must not generate a replacement key for the unresolved attempt. Corrections can start a new attempt only after the old result is known and handled explicitly. A terminal review is distinct from an unknown result: the same key will replay review even after manual remediation, so the contract must state the recovery route (for example a newly keyed attempt after Platform confirms remediation), with no consumer-selected candidate override. Please specify the hash comparison rules for omitted versus null optional fields and normalized versus raw identity material, journal retention/replay availability, and exactly which 400/422 failures guarantee no committed journal or Person mutation. A client must not infer these properties from HTTP status alone. Coaching will own its durable attempt state; a hidden input or in-memory retry key alone is insufficient.
The auth amendment is compatible in principle with Service Authentication Contract's existing workload exchange. For publication and release, make the binding explicit: Vercel team issuer and production Coaching proof subject, proof audience https://platform.sguildswim.com/api/auth/service-token/exchange, capability platform.identity.person-resolutions.create, resulting sub=system:coaching, aud=platform, tenant_id=tnt_sguild, Organization array exactly [org_01900000-0000-7000-8000-000000000001] for this v1 policy, only the named scope, and at most 300 seconds lifetime. The checkout is linked to the Vercel project named coaching; that local metadata is not evidence that the production proof or policy has been configured. Coaching currently has no workload-exchange client. Its implementation will validate the exchange claims, keep tokens/proofs only in memory, send the two matching routing headers, and refresh authorization while retaining the operation identity. Production Ready evidence must include successful exchange plus wrong project/environment/audience/Organization rejection. An operator cookie, static root mint secret, or local development bypass cannot substitute for that workload path.
Success and lifecycle checks
The caller needs a usable canonical name on every success. The current Sales mapper can render canonical given/family names when display_name is null, so a nullable display name alone is not an additional Sales compatibility blocker. A success must nevertheless guarantee usable canonical name material after the revised exact-name rules; no null-name record should become a fully usable Coach claim.
Please preserve the existing transactional person.created publication requirement when mint and journal are joined. Person resolution must not register an active Coach role before Coaching commits its role and status. The existing operational bridge writes Person tenancy and coach-role projection separately; it must not be treated as the exact portal-resolution behavior. The identity role taxonomy makes Coaching the producer of active Coach lifecycle facts. Any missing active-role publication in Coaching is a separate producer-side acceptance item, not permission for the resolution endpoint to create a Coach or predict its active status. The default portal status is hiring, not active.
The coordinator's requested fixes for archived/merged replay, precise name matching, name-only candidates, input limits, and privacy wording remain prerequisites and are not repeated as approvals here. No portal code, new endpoint, production write, or deployment was performed during this review. Both existing Coaching delivery commitments retain their original gates.