**Verdict.** Conditional fail for publication. A restricted Enterprise usage profile over WM-PER-001 is the correct shape: reuse the person-anchor, do not mint a new catalogue ID, and do not treat the published Person model as an installed enterprise person master. EM-PEO-01 remains queued (Claude/Grok not-started; boundary decision pending). Mapping status is conceptual-candidate only. The card is fit only if the restrictions, matching contract and fixtures below are bound before any publication claim.

**Mastership.** Person-anchor mastership stays on the WM-PER-001 natural-person entity and its domain-scoped reference identifier, whose issuing authority warrants persistence and non-reuse. The person is distinct from any record, identifier, document or credential about them. Registered-identity facts belong to the registrar of record; personal-sphere contacts and self-declarations belong to the person. HRIS, ATS and LMS are source systems of local bindings and purpose-limited projections, never universal person masters. An employee number is employer-scoped; changing employer does not change Person. AccountBinding is outside WM-PER-001 — party roles, customer and account relationships, authenticators, sessions and login are out of scope — and may remain an identifier-unassigned sibling candidate. Do not infer Person from Account. Do not treat a source row key, display name or email as the person.

**Matching contract.** Deterministic same-person linking is allowed only when both records carry a non-reassigned scheme-qualified identifier that matches on exact scheme, schemeVersion, issuer, scope and value inside the same authority/domain, with a no-reuse policy and declared referent kind Person. Compare qualified keys only; do not infer issuer, tenant or namespace; do not normalise. Display name, preferred name, email, phone and match-score cannot activate an asserted claim or auto-merge. Failing that test, create a proposed link only: state proposed; rule version; purpose; interval; authorising role; evidence references; and confidence if the host policy encodes it — otherwise record explicit absence of a numeric score so absence is not read as zero. A probable-entity-match cannot enter asserted state. Merge or split requires a durable record-linkage decision (inputs, threshold, authorising role, reversal path). Name plus date of birth is not an identifier.

**Name, contact and pseudonym rules.** Legal name is a time-bounded structured NameForm (parts; role birth/current/former/alias; script; ordering; validity; name-change instrument). A name change closes the prior validity interval and retains the former name; in-place overwrite is forbidden. Self-declared and display names never replace a legal name. Display name is a rendering, not an identity key; the brief field `display_name` is candidate-not-normative. ContactPoints are person-controlled, purpose-limited, visibility-scoped and separately verified; reference WM-PER-010, do not absorb it. Email and phone are contact values, not person identifiers. Pseudonyms and local IDs are scheme-qualified derived identifiers with correlatability class, relying-party or sector scope, and rotation; they are sufficient only inside that declared scope and are never deterministic merge keys.

**Privacy.** Disclosure is purpose-bound and deny-by-default. Every read names purpose, lawful basis and relying-party class and returns the narrowest projection. HR, customer and technical roles reference the person under a disclosure agreement; the employer does not own all person data. Special-category data and former-name fields are withheld from default projections. A same-as or proposed link is its own sensitivity class because linkage can defeat a pseudonym. Consent is scoped and withdrawable; statutory HR processing cannot be refused by withdrawal but remains purpose-limited.

**Scenario.** Three systems — HRIS, ATS, LMS — hold records for two namesakes who share a display name and a similar email local-part; one later records a legal-name change with a change instrument. Expected: two Person anchors remain distinct; each local record stays a source binding, identifier-unassigned where no scheme-qualified key exists; the name change versions NameForm, closes the prior legal-name interval and retains history; no system auto-merges on display name or email; the uncertain ATS–HRIS–LMS correspondence remains a proposal with rule version, state and authorising role. The card’s negative case — two users with the same display name merged automatically — must fail closed. An AccountBinding without a person identifier stays a sibling candidate, not a Person.

**Profile restrictions.** This is a restricted Enterprise usage profile over WM-PER-001 0.3.0-research.1, not a new subject model and not whole-parent conformance. In-profile: Person anchor reference; time-bounded NameForm with history; purpose-bound ContactPoint (reference, not absorb); IdentityEvidence references; scheme-qualified identifiers with reuse policy; proposed or asserted linkage records. Out-of-profile: replacing the civil registrar; biological or health data; household or kinship as objects; employment, customer or account facts as person attributes; authenticators and sessions; behavioural scoring; universal EMPI; biometrics as merge keys. Civil-status, nationality, legal-capacity and vital-event layers stay optional for enterprise. The contact-point ownership conflict between WM-PER-010 and WM-XCT-024 remains open.

**Blockers.** (1) EM-PEO-01 research is queued; reuse/extend/new is undecided; no published restricted-profile package exists over WM-PER-001. (2) `brief.json` lists HRIS, ATS and LMS as `candidate_master_systems`. That listing is a candidate list, not confirmed mastership, and it contradicts person-anchor mastership; rewrite as local bindings only. (3) Semantic crosswalk, mastership-and-rights matrix, and namesake-plus-name-change fixtures are absent. (4) WM-PER-001 is reviewable-draft, not a canonical Vercy release; source and coverage holds remain open. (5) AccountBinding is not an EM-PEO-01 candidate type (Person, NameForm, ContactPoint, IdentityEvidence) and must stay an identifier-unassigned sibling. (6) Do not invent a catalogue ID.