# FROZEN SEMANTIC AUDIT — EM-ORG-02  *Single independent frozen auditor. Material-bound. No identifiers, standards claims or external facts introduced.*  ---  ## 1. Verdict  **REVISE.**  The decision is right; the artifact that carries it is not. The reconciled candidate states correct semantics in prose while the pinned base texts it depends on still publish the opposite in required, cardinality-bearing elements. Every load-bearing guard in `constraints` (subject/record separation, single personality writer, single succession writer, six status planes, as-of replay) is unbacked by any element in the digests pinned in `basePins`. The candidate therefore asserts a semantics that the frozen bases contradict, and the fixture set does not test the contradictions. That is a revise, not an accept.  ---  ## 2. PROFILE over WM-ORG-001, WM-ORG-010, WM-ORG-011 — **CONFIRMED**, no new identifier  **PROFILE is the correct disposition** and is confirmed on the frozen material:  - **WM-ORG-010 is not a merge/retire candidate.** The registration record has an independent key (authority + assigned number), an independent status enumeration (`registration-record-status-code`), independent currency clocks (`initial-registration-date`, `last-update-timestamp`, `next-renewal-date`), independent evidence, and can lapse while the subject persists. That is a distinct lifecycle, not a projection of WM-ORG-001's. - **WM-ORG-011 is not a merge/retire candidate.** Presence carries site bindings, availability, local activity and reporting grain — none of which are registration or subject facts, and all of which survive when no registration exists. - **WM-ORG-001 remains the only subject master.** It is the only base holding canonical-key selection, entity resolution with explicit non-match, continuity decision and dissolution.  **No new identifier is confirmed as correct.** The contour needs exactly three subjects — legal subject, registration record, operating presence — and three identifiers already exist. `candidate_types` `LegalStanding` and `SuccessionRelation` do not require identifiers: standing is a dated assertion on the subject plane plus one per registration record, and succession is an append-only edge set on WM-ORG-001. **Grok's study names a "012 relationship" model. That identifier does not exist in the dossier, is not in `target_model_ids`, and is struck. It must not survive into any revision.**  One qualification carried forward as a hard scope limit, not a new model: WM-ORG-011's evidence depth (`index-and-publication-metadata`, single-provider waiver, 9 sources, no independent external review, templated deferred-schema data elements) does not support mastership of anything a legal, standing or obligor answer depends on. PROFILE is confirmed *with* WM-ORG-011 narrowed to non-load-bearing presence facts.  ---  ## 3. Semantic defects, with remediation and fixture expectation  ### A. Duplicate subject identity  **D01 — 010's published identity rule is unamended.** `register-anchored-legal-entity-identity` states the master identity of the *registered legal person* is the pair (registration authority, identifier). The candidate's constraint 2 contradicts the text it pins. A constraint cannot override a pinned digest. *Remediation:* re-subject the finding to master the **record**: rename the subject of the finding to the registration record, restate the key as record-identifying, and bind the candidate constraint to that base edit with a new source digest. Until the edit lands, `basePins` for WM-ORG-010 is evidence *against* the candidate. *Fixture:* `ORG02-IMPORT-MINT` and `ORG02-SECOND-EXTRACT` must be executed against the amended base text and must fail against the current one; record both runs.  **D02 — 010's composition is a subtype narrowing, not a reference.** `CHILD`, `required: true`, purpose "specialises the parent organization concept… mirroring org:Organization → org:FormalOrganization → rov:RegisteredOrganization". Under that relation every registered subject exists twice (once as 001 subject, once as 010 narrowed subject), and a subject with **zero** registrations is unrepresentable — which the dossier's own scope (informal collectives, statute-formed bodies) requires. *Remediation:* replace with a non-inheriting upward `REFERENCE` from record to subject, cardinality record→subject = 1, subject→records = 0..n. Claude's study identified this; the reconciled candidate dropped it. Restore it to `constraints` and `migrationPlan`. *Fixture:* new — subject with zero registration records (informal collective) accepted; new — a registered subject that materialises two subject rows rejected.  **D03 — no `subjectRef` element exists, and the migration plan points the reference the wrong way.** `migrationPlan` entry `{from: WM-ORG-010, to: WM-ORG-001, fields: ["subject identity reference only"]}` places the link on the subject, producing a many-valued subject-side record list — the same dual-mastership surface the profile is trying to close. No WM-ORG-010 selected finding contains any subject reference element. *Remediation:* add a required `subjectRef` (cardinality 1, resolution-state-qualified: `linked` | `unlinked` | `non-match`) to the re-subjected 010 identity finding. Rewrite the migration entry as a field **added to 010**, not moved to 001. WM-ORG-001 may hold only a derived, non-authored index. *Fixture:* new — 010 record without `subjectRef` rejected; new — `unlinked` record accepted and retained; new — subject-side record list written directly rejected.  **D04 — registry `parent_ids` asserts inheritance for both 010 and 011.** `vr.wm-org-010.parent_ids = WM-ORG-001` and `vr.wm-org-011.parent_ids = WM-ORG-001`. Parenthood in the registry plane implies identity inheritance for both the record and the presence. *Remediation:* clear `parent_ids` on both; express the relation only as typed `REFERENCE` in `composition`, and record the registry change in the reservation. *Fixture:* new — registry parent edge from 010 or 011 to 001 rejected by the validator.  **D05 — 011 can stand in as the party.** `operator-attachment-accountable-parties` is `required: true` and authors `{operator ref, legal entity ref, role, profile}` locally, and `establishment-kind-identity-set` is `required: true` with issuer-qualified identifiers and aliases. A presence record can therefore assert who the accountable legal entity is. *Remediation:* demote both to resolved read-only references into WM-ORG-001 (`legal entity ref` resolvable only, never asserted); keep `operator ref` as a reference; forbid alias authorship on the presence plane. *Fixture:* new — presence asserting an accountable legal entity not resolved from 001 rejected; new — presence alias used as a subject-resolution key rejected.  ### B. Identifier collision  **D06 — the equality tuple degenerates when validity is absent.** `identifierContract.equalityTuple` requires overlapping validity, but 010's `identifier-validity-interval` is `0..n`/not required and 001's `alias-identifier` carries no validity element at all. With validity absent the tuple silently reduces to (scheme, authority, number) — which matches a number an authority has reassigned after dissolution, a case 010's own question text anticipates. *Remediation:* make validity mandatory on every identifier assertion on both planes; where a source supplies none, require an explicit `validity-unknown` state, and define unknown validity as **non-matching**, yielding `unresolved` rather than a link. *Fixture:* new — identical (scheme, authority, number) with validity unknown on either side yields `unresolved`, never a match. `ORG02-NONOVERLAP` covers only the populated-interval case and is insufficient alone.  **D07 — the subject canonical key may be a register number.** `canonical-key-selection` tier 1 is "authoritative master-system identifier", which in practice is the register number. The subject key then changes on transfer, annulment, duplicate resolution or re-domiciliation, and two registers yield two candidate keys. *Remediation:* require the subject canonical key to be scheme-qualified *and* immutable for the life of the subject; where the selected key is a registration identifier, require a dimension-assigned internal key as the stable resolution anchor and retain every prior key as a validity-bearing alias that remains resolvable. *Fixture:* new — canonical key change on register transfer with all prior keys still resolving to the same subject; new — two registers producing two subject keys rejected.  **D08 — no non-reassignment constraint survived reconciliation.** Both provider studies state that retired identifiers are never reassigned and remain resolvable. `successionContract.retiredIdentities` says only "resolvable". Reassignment is unguarded. *Remediation:* add an explicit constraint: a retired identifier value may never be bound to a different subject or record; an authority-side reuse is recorded as a distinct dated assertion under a new record, never as a rebind. *Fixture:* new — reissued number bound to a second subject rejected; the first subject's historical resolution unaffected.  **D09 — cross-plane identifier equality is unscoped.** `identifierContract` names no plane. A branch register number appears as 010's record key and as 011's `identity-set` identifier; an EUID appears on 001. The same tuple therefore matches across subject, record and presence planes. *Remediation:* scope equality evaluation **within a single plane**; cross-plane sameness requires an explicit typed, dated, evidenced assertion, as already required for cross-scheme sameness. *Fixture:* new — presence identifier equal to a registration record key does not merge the presence into the record; new — cross-plane link accepted only with explicit evidence.  **D10 — residual registration fields left on the subject.** `migrationPlan` moves "register authority and number", "registration-record status", "extract evidence", "alternate scheme numbers". It does **not** move 001's `register-entry-date` or `cross-register-identifier` (EUID). Both were named in Claude's study and dropped in reconciliation. EUID is a cross-register join key sitting on the subject plane — a direct duplicate-subject and collision surface. *Remediation:* add `register-entry-date` and `cross-register-identifier` to the 001→010 move list. Note that 001's EUID element also carries an unresolved provisional hold, so it must not be relied on in either plane until that hold is discharged. *Fixture:* new — EUID used to join two subject records rejected; new — post-migration 001 record containing any register-plane field rejected.  **D11 — plane and scheme lists are closed.** `statusPlanes` enumerates six; `identifierContract.forbiddenSoleKeys` enumerates four. DUNS, GLN, EUID and any further scheme have no plane, and a fixed six-slot model breaks on the fourth registration scheme. *Remediation:* restate as a generative rule — one status plane per (scheme, authority) registration record, plus one subject plane, plus one observation/extract plane — and keep the six named planes as illustrative instances only. *Fixture:* new — a fourth scheme record (for example a cross-register or logistics scheme present in the bases) accepted with its own independently dated status, without extending an enumeration.  ### C. Status-plane leakage  **D12 — 010 authors subject status as a required field.** `registration-status-and-entity-status` has `entity-status-code` cardinality `1`, `required: true`. That is a second write path for subject status, prohibited by `mastership.forbiddenDualWrites`. Grok's "projection, not a second write path" demotion exists only in prose and never entered `constraints` or `migrationPlan`. *Remediation:* demote `entity-status-code` on 010 to a source-reported **claim** about the subject (claim value + source + observation time), explicitly non-authoritative, accepted onto 001 only by an evidenced, authorised subject update. *Fixture:* new — 010 `entity-status-code` written as authoritative rejected; new — subject status changed only via an authorised 001 update carrying the 010 claim as evidence. `ORG02-STATUS-LEAK` tests the overwrite direction only and does not test the required-field authorship.  **D13 — the registration plane survives on the subject.** 001 retains `record-registration-status` `0..n`, `register-code` `0..n`, `register-entity-number` `0..n` as owned elements. The migration lists the status but the accompanying key fields make the plane reconstructable on the subject after migration. *Remediation:* remove all four as owned elements from 001 in the same migration step; permit only a derived, non-authored index. *Fixture:* new — post-migration 001 asserting a registration status rejected.  **D14 — 011 carries a third registration status plane.** `registration-evidence-register-evidence` is `required: true` and includes `status` and `checked at`. The presence model therefore masters a register status. *Remediation:* reduce to a read-only `evidenceRef` into a 010 record, as `migrationPlan`'s "retained" list already intends; delete the locally authored `status` and `unit kind`. The candidate never states this deletion — its "removed" list contains only personality and branch-number-as-subject. *Fixture:* new — presence authoring a register status rejected; new — presence resolving status by dereferencing 010 accepted.  **D15 — restoration exists only on the record plane.** 010 has `restoration-event` `0..n`. 001's `dissolution-and-expiry` has no restoration element. Restoration is a *subject* status change; with no subject-side carrier, a record restoration is the only representation available and will be read as subject revival. *Remediation:* add a subject-plane restoration lifecycle event and continuity decision on 001; keep 010's `restoration-event` as the record-side event with its own dates. Note 010's own deferred research records that restoration and reinstatement lack global grounding — this remains a declared gap, so the element must be marked alignment-only. *Fixture:* new — record restoration with no subject-side event does not revive the subject; new — subject restoration and record restoration carried as two independently dated assertions.  **D16 — lossy status normalisation has no required carrier.** Both bases *ask* how a national status maps into normalised status and what is lost; neither has an element requiring retention of the source value and the loss note. The candidate's `openHolds` names the crosswalk as unapproved but sets no element requirement. *Remediation:* require, on every normalised status assertion, the source value verbatim, the source vocabulary and version, and a declared mapping-loss note; forbid normalisation that discards the source value. *Fixture:* new — normalised status without source value rejected; new — national status with no normalised equivalent retained as source-only with `unmapped` rather than coerced.  **D17 — the absent-plane rule was dropped.** Grok's study states that missing on one plane is `unknown`, never copied from another. This is absent from `constraints`, `statusPlanes` and the fixture set. *Remediation:* add the constraint verbatim; forbid inference of any plane's value from any other plane. *Fixture:* new — subject status absent while a record status is present yields `unknown` on the subject plane, never the record's value; and the converse.  ### D. False personality and unsupported standing  **D18 — 010 asserts personality as a required field.** `legal-personality-and-capacity` carries `Has legal personality` (`1`, required), `Formation theory` (`1`, required) and `Member liability regime` (`1`, required). Every registration record must therefore author personality — colliding with `mastership.forbiddenDualWrites` and with 001, where `legal-personality-flag` is `0..1` optional. Worse, 010's own publication hold requires primary statutory text for constitutive-versus-declaratory characterisation across two contrasting jurisdictions; a **required** `Formation theory` field forces a value from a source base the hold declares unverified. *Remediation:* demote all three on 010 to non-authoritative source-reported claims with provenance; promote personality to a required, evidence-bearing element on 001. Reconcile the required cardinality against the hold — a field may not be mandatory while its value space is held. *Fixture:* new — 010 authoring personality rejected; new — `Formation theory` unavailable accepted as explicit `unknown`; new — personality on 001 without evidence reference rejected.  **D19 — 011 forces fabricated standing.** `register-evidence`, `authorization-bindings` and `standing-uncertainty` are all `required: true` on every presence, while the same spec states "executable nested schema is deferred", the boundary notes state that public listing is not proof of legal standing, and the holds state no registry resolver or legal-standing verifier is delivered. An unregistered domestic site cannot be recorded without populating register evidence. *Remediation:* demote all three to `0..1` with explicit unknown/not-applicable states; keep `standing-uncertainty` as the mandatory representation *when* evidence is missing, never as a mandatory field. *Fixture:* new — unregistered domestic site accepted with no register evidence; new — presence whose only standing evidence is a public listing rejected as standing evidence and retained as recognition evidence.  **D20 — the discriminating fact is optional and unevidenced.** 001's `legal-personality-flag` is `0..1`, not required, with no bound evidence element, yet the entire `branchContract` and the non-person-branch pattern turn on it. *Remediation:* make it required on 001 with a three-valued space (`true` | `false` | `unknown`) and a mandatory evidence/source reference; `unknown` must block obligor determination rather than default to the head office. *Fixture:* new — obligor query against a subject with `legal-personality-flag = unknown` returns `undetermined`, not the head office.  ### E. Branch and obligor confusion  **D21 — the head-office relation has no carrier.** `branchContract.nonPersonBranch` requires "an explicit head-office relation" on 001. No WM-ORG-001 selected finding contains such an element; the relation appears only as prose in a boundary note naming a GLEIF relationship, and `relationship_ledger` holds only `CONTAINS` edges to WM-ORG-002/003. The partial carriers are 010's `head-office-reference` (`0..1`, optional) and 011's `organizational-links`. `ORG02-NONPERSON-BRANCH` expects a structure no pinned base provides. *Remediation:* add a required, dated, evidence-bearing bearing-legal-person relation on WM-ORG-001 for every subject with `legal-personality-flag = false`; demote 010's `head-office-reference` to a source-reported claim and 011's legal-entity link to a resolved read-only reference; add the edge to `relationship_ledger` with an explicit review state. *Fixture:* `ORG02-NONPERSON-BRANCH` must be rewritten to name the carrier element and must fail while no carrier exists; add — non-person branch with no head-office relation rejected.  **D22 — the obligor answer is undated.** `branchContract.obligorRule` has no temporal qualifier, so "who was obligor at T0" has no defined resolution path. *Remediation:* require validity intervals on the bearing-legal-person relation and define obligor resolution as an as-of query over that relation's assertion history. *Fixture:* new — obligor as-of a date before a head-office reattribution returns the prior head office.  **D23 — many-to-many is asserted but untested.** Constraint 9 states registration and presence are not one-to-one. `ORG02-REGISTRATION-PRESENCE-ONE-TO-ONE` only rejects a forced 1:1; no case accepts one branch registration spanning several presences, or one presence covered by several registrations — the exact GLEIF multi-office-branch case 011's own boundary note raises. *Remediation:* state the cardinality explicitly in `constraints` (registration 0..n ↔ presence 0..n, mapping recorded not inferred). *Fixture:* new — one branch registration bound to three presences accepted; new — one presence bound to two registrations accepted; new — mapping inferred from shared address rejected.  ### F. Historical-party rewrite  **D24 — three succession writers.** 010 holds `successor-entity-reference`/`predecessor-entity-reference`/`operation-type-code` plus function `apply-legal-entity-event`, whose description explicitly derives "identifier retirements and successor links". 011 holds `operator-attachment-continuity-rule` and `presence-continuity-succession-links`, both `required: true`. `forbiddenDualWrites` lists succession, but `migrationPlan` demotes none of these; 011's "removed" list omits them and its "retained" list is silent on them, so they survive by omission. *Remediation:* restrict lineage authorship to 001's `evaluate-succession-continuity`. Demote 010's successor/predecessor elements to register-side reported events pointing at a 001 edge, strip identifier retirement from `apply-legal-entity-event`, and demote 011's continuity and succession groups to `0..1` read-only references to 001 edges. *Fixture:* new — 010 writing a lineage edge rejected; new — 011 writing a lineage edge rejected; new — register-reported successor accepted as a claim awaiting a 001 continuity decision.  **D25 — party immutability has nothing to bind to.** `successionContract.historicalParties: "never rewritten"` requires that a contract party reference resolve to a dated subject assertion. 001's `entity-status` has no validity interval and its name assertions carry validity only inside the naming layer, which is itself under an unreframed multilingual hold. There is no element a party reference can pin to. *Remediation:* require validity intervals on subject identity, name and status assertions on 001, and define a contract party reference as a pin to (subject key, assertion validity), immutable after execution. *Fixture:* `ORG02-MERGER-HISTORY` must be strengthened to assert the pre-merger contract resolves the predecessor's *name and status as of the contract date*, not merely the predecessor key.  **D26 — merges are not required to be reversible.** 001 has `superseded-record-ref` `0..n` optional and `resolution-decision` required, but no constraint requires tombstone resolvability or merge reversal, and the candidate does not carry one. Both provider studies asserted it. *Remediation:* add a constraint: every merge writes a resolvable tombstone and is reversible; every rejected pair is retained as an explicit non-match so the comparison is not repeated. *Fixture:* new — merge without tombstone rejected; new — merge reversal restores prior resolution with history intact; new — recorded non-match suppresses re-proposal of the same pair.  ### G. Non-reproducible as-of answers  **D27 — subject status is a current-state field.** 001's `entity-status` is cardinality `1`, `required`, with `status-observed-at` `0..n` **optional** and no validity interval. 001 declares no bitemporal composition; only 010 declares the bitemporal and provenance mixins. `temporalContract` nonetheless claims append-only supersession and replay across all three bases. The dossier's acceptance scenario — correct answers on a historical date — is therefore unsupported on the subject plane, which is the plane the scenario asks about. *Remediation:* make the bitemporal and provenance mixins required compositions on WM-ORG-001 and WM-ORG-011; convert `entity-status` to an append-only assertion series with mandatory validity interval and mandatory observation timestamp. *Fixture:* new — subject status as-of three distinct dates returns three distinct values from history; new — in-place status overwrite rejected.  **D28 — no as-of function on the subject plane.** 010 has `compute-current-status`. 001 has `evaluate-record-standing`, which recomputes current standing, not an as-of answer. The historical-date question has no owner. *Remediation:* add an as-of resolution function on 001 covering subject identity, name, status, personality, head-office relation and lineage, answering from assertion history only. *Fixture:* new — the dossier acceptance scenario executed end to end as a single as-of query at a date before the merger, returning predecessor subject, the name and status valid then, and only those registration records whose validity covers that date.  **D29 — presence assertions have no transaction time.** 011's `lifecycle-events` carries effective and recorded time, but attribute assertions (site bindings, activity, availability, mastership) carry only validity or observation fields ad hoc; no bitemporal mixin is declared. *Remediation:* as D27 — require the bitemporal mixin on 011 and observation timestamps on every presence assertion. *Fixture:* new — presence site binding as-of a past date reproduced from history after two subsequent relocations.  **D30 — a mandatory evidence document with optional as-of time.** 010's `evidence-document-reference` is `1..n`, `required: true`, while `extract-as-of-date` is `0..n` optional. `ORG02-EXTRACT-CURRENT` cannot be evaluated when the as-of time is absent, and the mandatory cardinality forces a document onto records derived from bulk API extracts and onto the fallback-identity path 010 itself defines. *Remediation:* relax `evidence-document-reference` to `0..n` with an explicit `no-documentary-evidence` state; make `extract-as-of-date` mandatory whenever a document is cited, together with a declared freshness window. *Fixture:* new — cited document without as-of time rejected; new — record with no documentary evidence accepted with the explicit state; `ORG02-EXTRACT-CURRENT` re-expressed as: extract older than its freshness window is not readable as current status on any plane.  ### H. Mastership leakage  **D31 — a registrar-side write function survives in 010.** `submit-register-filing` ("File and publish changes to name, registered office, representatives, capital, objects, legal form or other disclosed particulars") is a write into an authority's register. 010's own adjudication **rejected** the registrar-side formation function precisely because "the base is an observer-and-operator model over an external authoritative register; accepting it would silently change the model's role". The two are irreconcilable inside one pinned base, and the deferred-research item "Whether Vercy models the registrar role at all" is still open. *Remediation:* remove `submit-register-filing` from 010, or resolve the open deferred-research decision first and restate the model purpose accordingly. Do not carry both. *Fixture:* new — any function asserting a change to an external register's content rejected while the registrar-role decision is open.  **D32 — required compositions on unregistered mixins.** 010 declares `required: true` compositions on "Provenance and observation mixin" and "Bitemporal versioning and history mixin" — neither has a model identifier in the dossier — while the candidate records `carrier: "none selected"`. Required dependencies on unregistered targets are unresolvable, and the temporal guarantees the candidate claims rest on them. *Remediation:* either register the mixins as identified models through the governed process, or downgrade the compositions to declared requirements-on-a-gap and mark every temporal guarantee dependent on them as unmet. Do not introduce identifiers in this audit. *Fixture:* new — required composition to an unidentified target rejected by the validator.  **D33 — per-record self-declared mastership.** 011's `presence-governance-assertion-mastership` lets each presence record declare its own field-scope masters. Mastership then varies per instance and can silently contradict the profile's mastership table. *Remediation:* mastership is a profile-level assertion; 011 may only record which master a field resolves to, validated against the profile table, never declare a new one. *Fixture:* new — presence declaring a master that conflicts with the profile mastership table rejected.  **D34 — three projection writers, no unlinked-record guard.** 001 `publish-projection`, 010 `project-to-exchange-format`, 011 `exchange-presence`. Nothing forbids projecting an `unlinked` 010 record, or an 011 presence, as subject-backed identity — which is exactly how a duplicate subject escapes into a downstream consumer. *Remediation:* add a constraint: no projection may present an unlinked registration record or a presence as a legal subject; every projection declares the plane it speaks for, its as-of time and its mapping loss. *Fixture:* new — projection of an unlinked record as a subject rejected; new — projection without as-of time and declared loss rejected.  ### I. Unsupported release claims  **D35 — per-case digests with no payload.** Every fixture carries a `sha256` while `fixturesExecuted: false`, and each case consists of `title`, `mode` and a one-line `expectation` — no inputs, no pre/post state, no oracle, no assertion of what the digest covers. Combined with `fixtureDigestRequired: true`, the digests read as execution evidence they are not. *Remediation:* either state explicitly that each digest is over the frozen declarative case text only and carries no execution meaning, or remove the digests until a runner produces result digests. Give every case inputs, initial state, expected end state and a machine-checkable oracle. *Fixture:* self-applying — the fixture file itself must fail validation while any case lacks inputs and an oracle.  **D36 — the candidate's lifecycle string is contradicted by its own reservation.** `candidateStatus: "provider-reconciled-pre-audit-publication-held"`, `candidateRevision: 2`, against a frozen `queue_reservation` of `status: "queued"`, `claude_status: "not-started"`, `grok_status: "not-started"`, `boundary_decision: "pending"`, `remaining_scope: "Entire research brief pending"`. *Remediation:* update the reservation atomically with the candidate — provider statuses, boundary decision, publication URLs (none), and remaining scope — or the audit trail asserts two incompatible positions. *Fixture:* new — candidate whose reservation fields contradict its `candidateStatus` rejected.  **D37 — element-level value-space claims outrun the holds.** 001's `elf-code` ("Four-character ISO 20275 entity legal form code") and 010's `entity-legal-form-code` ("Governed four-character code") assert governed value spaces, while both bases hold that ISO 20275 and ISO 17442 were cited from catalogue landing pages, not normative text. The candidate's blanket "no conformance claim" constraint does not reach element descriptions. *Remediation:* mark alignment-only at element level, not only in a global constraint: each element sourced from a held standard carries an explicit alignment-only flag and the governing hold reference. *Fixture:* new — element citing a held source without an alignment-only flag rejected.  **D38 — governance gates are encoded as semantic fixtures.** `ORG02-BASE-PIN-DRIFT` and `ORG02-PUBLICATION-GATE` use `mode: "reject"` alongside semantic cases, conflating "this instance violates semantics" with "this release is not permitted". *Remediation:* separate the file into semantic cases and gate checks with distinct vocabularies; a gate failure must be non-overridable by fixture results.  **D39 — conditional accepts with no paired reject arm.** `ORG02-CONVERSION-CONTINUITY` (accept, "only with explicit authority-backed continuity decision"), `ORG02-CROSS-SCHEME-EQUIVALENCE` (accept, "only with explicit dated evidence"), `ORG02-THREE-RECORDS` and `ORG02-NONPERSON-BRANCH` all state a condition without a case that exercises its violation. *Remediation:* split each into an accept case and its paired reject case — conversion claiming continuity with no decision; equivalence asserted without evidence; three records collapsed to one status; non-person branch materialised as a person.  **D40 — the fixture set does not cover the dossier's own scenarios or the inherited profile validations.** No case executes the acceptance scenario as an as-of query on a historical date (see D28). None of the profiles the inherited holds require appear as fixtures: informal collective with zero registrations, statute-formed body, sole proprietor whose legal person is a natural person, fund with umbrella and management relations, US state-level formation with no national register, a non-EU civil-law register, a national scheme outside the authority-list framing, and a jurisdiction where a legal form arises without registration. `openHolds` treats these as inherited and therefore untested, but they are exactly the cases that break the subject/record cardinality and the fallback identity path. *Remediation:* add one fixture per profile, each asserting subject creation, registration cardinality (including zero), personality value and as-of reproducibility.  ---  ## 4. Contradictions among dossier, providers, profile and fixtures  **C01** Reservation versus delivered artifacts: `status: queued`, both providers `not-started`, `boundary_decision: pending`, `remaining_scope: "Entire research brief pending"` — against two provider studies, a comparison and a revision-2 candidate. (D36)  **C02** WM-ORG-001 registry `status: "described-previous-version"` and `review_state: "migration-boundary-review"` against spec `status: published`, `version: 0.3.0-research.1`, `previousVersions: []`. A described previous version with an empty previous-versions list is self-contradictory, and the candidate pins the version as current.  **C03** Three different kinds for WM-ORG-011: contour `kind: subject`, registry `entry_kind: standalone-mm`, spec `entryKind: aggregate`, adjudicated boundary `aggregate`. Likewise WM-ORG-001: registry `standalone-mm` versus spec `entity`.  **C04** Registry `parent_ids` (010→001, 011→001) against spec relations (`CHILD required:true` for 010, `REFERENCE` for 011) against the candidate ("references", non-inheriting). Three incompatible relation semantics for the same pair. (D02, D04)  **C05** 010's `CHILD`/`required: true` narrowing against the candidate's zero-registration case and against 001's own boundary note admitting unregistered and informal organizations. A subject cannot be both required to have a registration record and permitted to have none.  **C06** 010's `register-anchored-legal-entity-identity` (authority + number *is* the legal person) against the candidate's constraints 1–2 and against both provider studies. The published text is the one pinned. (D01)  **C07** Personality mastership: 010 `Has legal personality` required versus 001 `legal-personality-flag` optional versus candidate "001 masters personality" versus `forbiddenDualWrites`. Four positions. (D18, D20)  **C08** Subject status mastership: 010 `entity-status-code` required versus 001 `entity-status` required versus candidate constraint 13. (D12)  **C09** 010's `submit-register-filing` against 010's own adjudication rejecting the registrar-side function and against its open deferred question on whether the registrar role is modelled at all. (D31)  **C10** 010's publication hold requiring primary statutory text for constitutive-versus-declaratory characterisation against `Formation theory` being a required element. A held value space cannot be mandatory. (D18)  **C11** 011's data elements are near-uniformly `required: true` while the same descriptions state "executable nested schema is deferred" and "Preserve explicit unknowns", and its holds state no schema, resolver or verifier is delivered. Required flags over a deferred schema are unverifiable. (D19)  **C12** 011's `registration-evidence-record` (required, with status) against 011's own boundary note "public listing is not service permission or proof of legal standing", against Claude's "read-only reference", against Grok's "evidenceRef → 010", and against the candidate's silent retention. (D14)  **C13** 011 authors succession (`continuity-rule`, `succession-links`, both required) and 010 authors succession, against `forbiddenDualWrites` listing succession and against `migrationPlan` demoting neither. (D24)  **C14** VAT treatment: `ORG02-THREE-RECORDS` and both provider studies treat VAT as a third **registration record** with its own status plane; 010's boundary note carries tax and VAT numbers as scheme-qualified **alternate identifiers** on a record, not as records. `statusPlanes` then lists a "tax/VAT status" plane with no carrier under the base reading. Fixture and base disagree on the object being tested.  **C15** `migrationPlan` moves "extract evidence" from 001 to 010, but 001's selected findings contain no extract or evidence-document element — only `identifier-verified-at` and `constitutive-instrument-ref`. The plan moves a field that does not exist in the source base; symmetrically it omits `register-entry-date` and `cross-register-identifier`, which do. (D10)  **C16** `temporalContract` ("append-only supersession", "replay from assertion history") against 001's single-valued required `entity-status` with optional observation time and no bitemporal mixin, and against 011's absence of one. The guarantee is claimed for three bases and declared by one. (D27, D29)  **C17** `executionRequirements.carrier: "none selected"` against 010's `required: true` compositions on the provenance and bitemporal mixins, which are the carriers the temporal and provenance guarantees depend on. (D32)  **C18** Grok's study introduces "a 012 relationship" model — an identifier absent from the dossier and from `target_model_ids`, contradicting the no-new-identifier decision the same study asserts. Correctly not adopted downstream; must be struck on the record. Grok's study also refers to "field moves from WM-ORG-001/011 into WM-ORG-010" including "extract-as-identity", which has no counterpart element in 001. (C15)  **C19** Restoration: Claude's study asserts restoration normally preserves subject identity; 010 carries `restoration-event` on the record plane only; 001 has no restoration carrier; 010's deferred research records that global instruments do not specify restoration at all. (D15)  **C20** `ORG02-NONPERSON-BRANCH` expects acceptance of "subject, head-office link, registration and presence as separate records" while no pinned base contains a subject-level head-office element. A fixture asserts a structure the frozen bases do not provide. (D21)  **C21** `relationship_ledger` declares instance-level containment semantics ("Organization instance contains organizational-unit instances") at model level with `review_state: candidate`, while the candidate treats WM-ORG-001 as a settled master; and `evidence_limits` declares registry relations non-normative, so the only recorded edges for 001 are simultaneously relied on and declared non-normative.  **C22** `candidate_properties_from_v1` (ORG-02/03/08: `legal_name`, `register_uri`, `register_number`, `registration_status`, `branch_kind`, `host_jurisdiction`, `authority_scope`, `effective_period`) are unplaced by `migrationPlan`; `authority_scope` overlaps 011's `mandate-scope` and 010's representation elements with no owner assigned. Declared non-normative yet carried in the frozen dossier as candidate properties.  **C23** `candidate_types` includes `LegalStanding` and `SuccessionRelation`; the candidate maps three bases and never states where these land, while simultaneously asserting `newRuntimeId: false`. The mapping is unstated rather than resolved.  ---  ## 5. Closed remediation checklist  Twenty-four items. Complete for this audit; each is verifiable against a base digest, a constraint text or a fixture result. No item is discharged by a hold.  1. Re-subject 010's `register-anchored-legal-entity-identity` to master the registration record, not the legal person; re-pin the source digest. (D01, C06) 2. Replace 010's `CHILD`/`required: true` with a non-inheriting upward `REFERENCE`; permit subject→records = 0..n including zero. (D02, C05) 3. Add a required, resolution-state-qualified `subjectRef` (cardinality 1) to 010; delete the reversed migration entry and forbid subject-side authored record lists. (D03, C04) 4. Clear `parent_ids` for 010 and 011 in the registry; express both relations only as typed references. (D04, C04) 5. Demote 011's `accountable-parties` legal-entity link and `identity-set` alias authorship to resolved read-only references. (D05) 6. Make identifier validity mandatory on both planes with an explicit `validity-unknown` state defined as non-matching → `unresolved`. (D06) 7. Require the subject canonical key to be immutable and scheme-qualified, with a stable internal anchor and all prior keys retained as validity-bearing resolvable aliases. (D07) 8. Add an explicit non-reassignment constraint for retired identifiers on every plane. (D08) 9. Scope identifier equality within a single plane; require explicit evidenced assertions for cross-plane and cross-scheme sameness. (D09) 10. Add `register-entry-date` and `cross-register-identifier` to the 001→010 move list; remove `register-code`, `register-entity-number` and `record-registration-status` as owned 001 elements; correct the non-existent "extract evidence" move. (D10, D13, C15) 11. Restate status and identifier planes as a generative rule — one per (scheme, authority) record, plus subject, plus observation — with the six named planes as instances only. (D11, C14) 12. Demote 010's `entity-status-code` and 011's `register-evidence.status` to non-authoritative source-reported claims; subject status is authored only on 001. (D12, D14, C08, C12) 13. Add a subject-plane restoration event and continuity decision on 001, marked alignment-only pending its declared grounding gap. (D15, C19) 14. Require source value, source vocabulary and version, and a mapping-loss note on every normalised status; permit `unmapped`. (D16) 15. Add the absent-plane rule to `constraints`: missing on one plane is `unknown`, never copied or inferred. (D17) 16. Demote 010's personality, formation-theory and member-liability elements to claims; promote a required three-valued, evidence-bearing personality element to 001; resolve the required-field-over-held-source conflict. (D18, D20, C07, C10) 17. Demote 011's `register-evidence`, `authorization-bindings` and `standing-uncertainty` to optional with explicit unknown states. (D19, C11) 18. Add a required, dated, evidence-bearing bearing-legal-person relation on 001; demote the 010 and 011 variants; record the edge in `relationship_ledger`; define obligor as an as-of query over that relation; return `undetermined` on unknown personality. (D21, D22, C20) 19. State registration↔presence cardinality as 0..n ↔ 0..n, recorded never inferred. (D23) 20. Restrict lineage authorship to 001; strip identifier retirement from 010's `apply-legal-entity-event`; demote 010's and 011's succession elements to read-only references; require validity intervals on subject identity, name and status so contract parties can pin to a dated assertion; require tombstones, merge reversibility and retained non-matches. (D24, D25, D26, C13) 21. Make the provenance and bitemporal mixins required on 001 and 011 with identified, governed targets — or downgrade them to declared gaps and mark every dependent temporal and provenance guarantee unmet; convert 001's `entity-status` to an append-only series with mandatory validity and observation time; add an as-of resolution function on 001; relax 010's evidence-document cardinality while making `extract-as-of-date` and a freshness window mandatory when a document is cited. (D27–D30, C16, C17) 22. Remove 010's `submit-register-filing` or first close the open registrar-role decision; remove per-record mastership declaration from 011 in favour of the profile mastership table; forbid projecting an unlinked record or a presence as a legal subject, and require an as-of time and declared loss on every projection. (D31, D33, D34, C09) 23. Rebuild the fixture file: inputs, initial state, expected end state and a machine-checkable oracle per case; separate semantic cases from governance gates; state or remove the per-case digests; split every conditional accept into an accept/reject pair; add the missing cases named under D01–D40, including the dossier acceptance scenario as a single historical-date as-of query and one case per inherited validation profile (zero-registration informal collective, statute-formed body, sole proprietor, fund with umbrella, US state-level formation, non-EU civil-law register, national scheme outside the authority-list framing, legal form arising without registration). (D35, D38, D39, D40) 24. Reconcile the governance record atomically with the revision: update the queue reservation's provider statuses, boundary decision and remaining scope; resolve the entry-kind disagreements for 001 and 011; resolve the WM-ORG-001 `described-previous-version` / empty-`previousVersions` conflict; assign an owner for every unplaced Enterprise v1 candidate property including `authority_scope`; state where `LegalStanding` and `SuccessionRelation` land without minting an identifier; strike Grok's "012" reference on the record; flag alignment-only at element level for every element sourced from a held standard. (D36, D37, C01, C02, C03, C18, C21, C22, C23)  **Publication position unchanged.** `publishableCanonical` stays false and `fixturesExecuted` stays false. Every inherited hold on all three bases stands and none is discharged by this audit. The holds in the frozen material are read as constraints on what may be claimed, not as permission to keep a required element whose value space, carrier or evidence is missing — items 16, 17 and 21 exist precisely because several holds were being used that way.