My Account — Personal details across sync edge cases
One Citizen, eight states — one per distinct rendered face. Each opens the same Composed Personal Details View with a different fixture behind it, alongside a pane showing the field envelope, Integration Link status and sync trace that produced it.
Scenarios 4 to 6 are worked examples under “Edge-case examples” in docs/mdm/mdm-profile-logical-mapping.md. Scenarios 1 to 3 are the three Profile Assurance levels. Nothing here is agreed, and camden-held values are a design dependency — no Semarchy read contract exists yet.
Cases that produce a face another scenario already renders are not screens here. Their sync mechanics are in the sync walkthrough — docs/diagrams/profile-sync-walkthrough.html.
1. Registered, not linked
none
Florence has registered and typed her own details. Profile Assurance is none.
Shows: The thin self-typed face. No candidates, no fallbacks, nothing camden-held. The envelope shape is identical to a verified Profile — it simply contains less.
2. Linked via Council Tax
linked
A Council Tax reference has been accepted under its Reference Link Policy. Profile Assurance is linked.
Shows: The Verified Gate. Camden-held values now exist and are matched to this Profile, and the face still shows none of them. A guessed or stolen reference number must not expose a home address.
3. Verified
verified
Florence has completed a Holder-Bound Approved Proofing Route. Profile Assurance is verified.
Shows: The full composed view. Camden-held Name and Date of Birth are now the face and are correction-only; address and phone gain camden-held candidates alongside the Citizen's own, resolved by a Primary Selection.
4. Registration name differs from the golden name
verified
Florence registered as “Flo”. A Council Tax link found an existing migrated Profile whose Semarchy golden first name is “Florence”. The existing Profile survives and the registration Citizen ID becomes a permanent alias.
Shows: The one-time reconciliation. The entered name is offered for confirmation as a Profile-owned Preferred Name — it is never promoted silently, because it is at least as likely to be a typo as a preference.
Edge-case example 2 — Existing Profile found after registration
5. Two possible existing Profiles
none case open
The evidence supplied matches more than one existing Profile. Profile chooses neither.
Shows: Nothing is linked, nothing is consolidated, and no candidate information is revealed — not even that a second candidate resembles the Citizen. The Principal stays on the registration Citizen ID and a Link Review Case decides.
Edge-case example 3 — Two possible existing Profiles
6. Semarchy disagrees with an approved correction
verified withholds case open
Florence's surname correction was approved in Profile. Semarchy has since sent a different surname.
Shows: The approved Profile value stays on the face while the disagreement is resolved. Arrival order is not a survivorship rule, so the newer external value does not win by being newer.
Edge-case example 8 — Semarchy disagrees with an approved Profile correction
7. Correction request in progress
verified
Florence has asked us to correct her Governed Name. The request is with a caseworker.
Shows: Submitting a correction changes no governed fact and triggers no downstream identity update. The face still shows the current value; only an approved outcome becomes eligible for synchronization.
8. Selected destination cannot be used
verified
Florence's chosen phone number is failing delivery, and she has started changing her email but not yet confirmed it.
Shows: Preference resolution returns “action required” rather than silently switching channel, and a pending contact value is not used for communications. Contact Confirmation is separate from Profile Assurance and applies only to values the Citizen supplied.