# Frozen Semantic Audit — EM-ORG-05 "Enterprise Collective, Team and Community"Auditor role: single independent frozen auditor. No tools used. No external facts, no new model or runtime identifiers introduced. New identifiers appearing below are **fixture case ids only** and are explicitly not model, registry or runtime identifiers.---## 1. Verdict**REVISE.**Revision 2 is directionally correct and is the best of the three artifacts on the dossier, but it is not auditable as a closed profile candidate. Three of its provisions exceed profile authority over the frozen base, four invariants present in the provider studies were dropped without adjudication, at least one fixture (`intercompany-cardinality`) asserts acceptance of a configuration the frozen base forbids, and the fixture digests are unverifiable as specified. The contour's own acceptance scenario (temporary inter-company team) is currently unbuildable on the pinned bases.---## 2. Decision on PROFILE over WM-ORG-003 with REUSE of WM-ORG-006, no new identifier**Confirmed in direction, rejected as written.** Split verdict, stated precisely:| Element of the decision | Status ||---|---|| `decision: "PROFILE"` as the contour disposition | **Confirmed.** Both studies converge; the dossier supplies no evidence of an independent identity rule, state machine or change-event class for Collective or CommunityOfPractice that WM-ORG-003 does not already carry. || `REUSE` of WM-ORG-006 for scheme-governed membership | **Confirmed in principle, held in fact.** WM-ORG-006's own adjudication records "the approved relation ledger contains no WM-ORG-006 rows, so all proposed sibling composition remains draft," and the frozen `relationship_ledger` confirms zero WM-ORG-006 rows. The reuse edge is therefore a draft proposal, and the candidate states it in unconditional `MUST` modality. See D03/D33. || `newRuntimeId: false` | **Confirmed.** No new model, registry or runtime identifier is warranted on this evidence. Membership, TeamAssignment, Collective, CommunityOfPractice, WorkingAgreement and TechnicalDomain all resolve to existing bases, base children or classifier codes. || Revision 2 constructible as a **pure profile today** | **Rejected.** A profile may narrow the base; it may not relax base cardinality, add base-absent required roles, or rename a base child record. Revision 2 does all three (D01, D02, D11). Those three must be routed as change requests against WM-ORG-003, not asserted inside this contour. || Contour acceptance scenario ("собрать временную межфирменную команду") | **Blocked**, not merely held, until D01 is adjudicated in the base. |---## 3. Audit basis and stated limits- Audited artifacts: frozen dossier (contour card, queue reservation, two registry reservations, two-row relationship ledger, two pinned specs, evidence limits), Claude study, Grok study, provider comparison, candidate revision 2, fixtures revision 2.- `selected_findings` is a reviewer projection: WM-ORG-003 declares 31 findings and exposes 19; WM-ORG-006 declares 32 and exposes 12. **Roughly half of each base's findings were not visible to this audit.** Every "absent from the base" statement below is scoped to the projection and must be re-run against the full spec before closure. This is an audit coverage limit, not a defect of the candidate.- Enterprise v1 fields (`ORG-06`, `PEO-11`) are non-normative per `evidence_limits` and are treated as candidate-only throughout.- Both bases are `publishableCanonical: false`, `adjudicationStatus: reviewable-draft`. Nothing below implies either base is installable.---## 4. DefectsEach defect: evidence → failure mode → exact remediation → fixture expectation.### A. Decision authority and base pinning**D01 — Containment relaxation exceeds profile authority (BLOCKING).***Evidence.* WM-ORG-003 carries containment at three points: `composition` → `WM-ORG-001 (Organization)`, `relation: REFERENCE`, `required: true`, "resolves to **exactly one** containing organization context"; finding `team-boundary-and-entity-distinction` → `containing_organization_ref`, `cardinality: "1"`, `required: true`; accepted finding `containing-and-managing-organization` → `containing-and-managing-organization-data01`, `cardinality: "0..1"`, `required: false`. Candidate asserts `interCompanyContract.containment: "0..1"` in normative constraint form while simultaneously listing the conflict as a publication hold.*Failure mode.* Invalid inter-company cardinality; a profile unilaterally resolving an unadjudicated base contradiction in the **weaker** direction. Profiles narrow; this widens `1/required` to `0..1/optional`. Downstream, every collaboration-profile claim rests on the relaxed reading.*Remediation.* (a) Remove `0..1` from the normative `constraints` array. (b) Restate as `interCompanyContract.containment: {"value": "unresolved", "baseConflict": ["composition:WM-ORG-001:required=true", "finding:team-boundary-and-entity-distinction:containing_organization_ref=1", "finding:containing-and-managing-organization:data01=0..1"], "profileAuthority": "none — base amendment required"}`. (c) Raise an explicit change request against WM-ORG-003 as a named blocker; the profile may not proceed on either reading until the base adjudicates. (d) Until adjudication, the collaboration profile is `not-constructible`, and the contour's acceptance scenario is marked blocked, not held.*Fixture expectation.* `containment-cardinality-unresolved` (negative): input "collaboration profile instantiated with zero containing organizations against the pinned base" → **expect refuse with reason `base-contradiction-unadjudicated`**, not accept. Existing `intercompany-cardinality` must be demoted from `positive` to `blocked` and must not be executable while D01 is open (see D32 on digest re-issue).**D02 — `sponsors`, `recordAuthority`, `obligationBearer` have no carrier in either base.***Evidence.* WM-ORG-003's exposed organization-facing elements are `containing_organization_ref`, `containing-and-managing-organization-data01/02/03`, `managing_organization_ref`, `accountable_owner_ref`, `reports_to_ref`. There is no sponsor element, no record-authority element, no obligation-bearer element. The `provenance-access-retention` finding describes "Custody" in prose but exposes only `sensitivity_class`, `retention_period`, `legal_hold` — no custodian data element. WM-ORG-006 exposes none of these either.*Failure mode.* Invalid inter-company cardinality asserted over fields that do not exist; three de facto new structures presented as a profile. `sponsors: 1..n` is additionally a **new mandatory minimum** with no base support.*Remediation.* For each of the three roles emit a `baseGap` record: `{role, proposedCardinality, nearestBaseElement, semanticDelta, disposition: "base-extension-request"}`. `sponsor` → nearest base element: none (`accountable_owner_ref` is accountability, not authorisation/funding — do not overload it). `recordAuthority` → nearest: `provenance-access-retention` custody prose, no element — request a `record_authority_org_ref` element in the base. `obligationBearer` → nearest: `mandate_obligation_ref` (an instrument citation, not a party) — do not overload. Until the base carries them, downgrade all three from `MUST` to `profile-proposal-not-enforceable`.*Fixture expectation.* `sponsor-has-no-base-carrier` (negative): input "collective record populates a sponsor role" → **expect refuse with reason `no-base-element`** while D02 is open. `record-authority-has-no-base-carrier` (negative), same shape. `dual-record-authority` (existing) must be re-scoped: it presently tests a rule whose field does not exist, so it cannot pass or fail meaningfully — mark it `pending-base-element`.**D03 — Base pin set is incomplete for required compositions.***Evidence.* `basePins` lists WM-ORG-003 and WM-ORG-006 only. WM-ORG-003 declares three **`required: true`** compositions: `WM-ORG-001 (Organization)` REFERENCE, `WM-ORG-004 (Position)` COMPOSE, and "Person / Worker context model (target model id not yet registered in the vr registry)" REFERENCE, plus a required PROV-O MIX-IN. None is pinned; WM-ORG-004 has no registry row, no spec, no sha in this dossier. `relationship_ledger` carries `WM-ORG-003 COMPOSE WM-ORG-004` at `review_state: candidate`.*Failure mode.* Identity drift and unsupported release claims: the candidate pins two of at least five required dependencies and declares `invalidationRule` only over those two. A drift in WM-ORG-004 or WM-ORG-001 silently invalidates nothing.*Remediation.* Extend `basePins` with a `requiredDependencies` array listing WM-ORG-001, WM-ORG-004, the unregistered Person/Worker model and the PROV-O mix-in, each with `pinned: false`, `reason`, and the same `invalidationRule`. Add an explicit statement that the candidate inherits WM-ORG-003's required COMPOSE onto WM-ORG-004 and that the profile does not state which organization's position catalogue serves a cross-company collective.*Fixture expectation.* `unpinned-required-dependency` (negative): input "profile validated while a `required: true` base composition target is unpinned" → **expect refuse with reason `dependency-unpinned`**. `intercompany-position-catalogue` (negative): input "cross-company TeamAssignment cites `position_ref` without declaring the owning organization's WM-ORG-004 catalogue" → **expect refuse**.**D04 — Candidate contradicts the relationship ledger.***Evidence.* Ledger row: `WM-ORG-001 --CONTAINS--> WM-ORG-003`, instance semantics "Organization instance contains team instances", rationale "Operational matryoshka", `review_state: candidate`. Candidate makes containment optional and forbids "inventing" containment.*Failure mode.* Invalid cardinality plus an untracked divergence from the only containment row that exists.*Remediation.* Add `ledgerDivergences: [{row: "WM-ORG-001 CONTAINS WM-ORG-003", divergence: "profile proposes optional containment for boundary_class = organizational collaboration", status: "unadjudicated", blocks: "D01"}]`. Do not restate the profile position as settled.*Fixture expectation.* `ledger-divergence-declared` (positive): input "profile emitted with an unadjudicated ledger divergence recorded" → **expect accept the record, refuse publication**.**D05 — Registry/spec drift is not pinned.***Evidence.* Both registry rows declare `entry_kind: "standalone-mm"`; the specs declare `entryKind: "aggregate"` (003) and `"relationship"` (006). WM-ORG-006 registry: `status: described-previous-version`, `legacy_alias: O3`, `existing_spec_ref: models/organizations/O3-employment-and-membership.md` (a card that fused Employment with Membership), while the spec declares `version: 0.3.0-research.1`, `previousVersions: []`. WM-ORG-003 registry `existing_spec_ref` is empty although `publications/wm-org-003-team/spec.yaml` exists, and carries `validation_flags: "пробел; не O2"`.*Failure mode.* Identity drift: the candidate's pins capture the publication surface only, so a registry that still describes a previous, differently-scoped record can change under the pin without invalidating anything.*Remediation.* Add to each `basePin`: `registryEntryKind`, `specEntryKind`, `entryKindDivergence: true`, `legacyAlias`, `legacySpecRef`, `previousVersionsDeclared`, and a `registrySnapshotSha256` covering the frozen registry row. State explicitly that WM-ORG-006's empty `previousVersions` contradicts its own hold ("the previous O3 card combined Employment and Membership") and that lineage is unresolved.*Fixture expectation.* `entry-kind-divergence` (negative): input "candidate published while registry `entry_kind` and spec `entryKind` disagree" → **expect refuse**. `lineage-unresolved` (negative): input "WM-ORG-006 reused while `previousVersions` is empty and a fused legacy card is still referenced" → **expect refuse publication, permit draft reuse**.### B. Identity drift and promotion control**D06 — A profile-local type carries a base registry identifier.***Evidence.* `profileTypes.Membership.registryId: "vr.wm-org-006"`; every other type has `registryId: null`.*Failure mode.* Identity drift: a profile-local label appears to own a registry entry. Consumers may treat "Membership" in this profile as the registry record rather than as a reference to it.*Remediation.* Set `profileTypes.Membership.registryId: null` and add `baseRegistryRef: "vr.wm-org-006"` plus `baseModelId: "WM-ORG-006"` on every type that resolves to a base. Add constraint: "Profile-local type labels MUST NOT populate `registryId` or `runtimeId`; base linkage is expressed only through `baseModelId` / `baseRegistryRef`."*Fixture expectation.* `profile-label-carries-registry-id` (negative): input "a profileType populates `registryId`" → **expect refuse**.**D07 — Profile labels are not bound to base code values.***Evidence.* WM-ORG-003 carries `boundary_class` (`1`, required: organizational unit / organizational collaboration / non-team cohort) and `permanence` (`1`, required: standing / time-boxed / activated-on-demand). Claude bound its profiles to those codes (`boundary_class = organizational collaboration`, `permanence = standing`). Revision 2 names "collaboration profile" and "standing collaboration profile" without binding either.*Failure mode.* Classifier promotion: profile names become a second, parallel classification axis competing with the base codes; profile selection is undecidable from instance data.*Remediation.* Add `profileSelection: {"Team": {"boundary_class": "organizational-unit"}, "Collective": {"boundary_class": "organizational-collaboration"}, "CommunityOfPractice": {"boundary_class": "organizational-collaboration", "permanence": "standing"}}` with a rule: "Profile identity MUST be derivable from base code values; profile names are labels and MUST NOT be stored as classification."*Fixture expectation.* `profile-derivable-from-base-codes` (positive): input "instance carrying `boundary_class` + `permanence`" → **expect exactly one profile resolved, no stored profile label**. `profile-label-stored-as-classifier` (negative) → **expect refuse**.**D08 — The promotion/escalation test was dropped.***Evidence.* Claude states a three-part escalation test for a future CommunityOfPractice identifier (survives dissolution of every hosting organization; admits members holding no collective-scoped assignment; carries a lifecycle event class WM-ORG-003's event set cannot express). Grok states a TechnicalDomain split trigger (own lifecycle, methods and stewards — and still must not reuse the community's WM-ORG-003 id). Neither survives into revision 2.*Failure mode.* Classifier/profile promotion with no stated bar: any future actor may mint an identifier without demonstrating independence, or may refuse one arbitrarily.*Remediation.* Restore both tests verbatim into a `promotionTests` block, one per type, each with `allConditionsRequired: true` and the rule "no identifier may be minted while any condition is unmet; satisfying the test authorises a new research contour, not an identifier."*Fixture expectation.* `cop-promotion-test-unmet` (negative): input "new identifier proposed for CommunityOfPractice with two of three conditions met" → **expect refuse**. `technical-domain-split-reuses-community-id` (negative): input "promoted domain reuses the stewarding community's WM-ORG-003 id" → **expect refuse**.**D09 — Structural-change identity retention and duplicate tombstoning are absent.***Evidence.* WM-ORG-003 asks "Does the team retain its identifier through the change, or is a new identity minted?" and "When two records are found to describe the same team, which survives and how is the loser tombstoned?", and exposes `change_event_type`, `original_team_ref`, `resulting_team_ref`. Revision 2 says only `newRuntimeId: false` and has no merge/split/transfer or duplicate rule; the `collective-dissolution` fixture is the only lifecycle case.*Failure mode.* Identity drift and history rewrite: a merge or split may silently re-key a collective or absorb its assignment and membership history.*Remediation.* Add constraints: "Merge, split, transfer and rename MUST be recorded as append-only change events; identifier retention MUST be stated explicitly per event and MUST NOT be implicit"; "A duplicate collective MUST be tombstoned with a surviving-record reference; its assignments and referenced memberships MUST NOT be re-parented without a dated correction assertion."*Fixture expectation.* `merge-retains-identity-explicitly` (positive) → **expect accept only when the event states retention or minting**. `split-rewrites-assignment-history` (negative) → **expect refuse**. `duplicate-merge-silent-reparent` (negative) → **expect refuse**.**D10 — TechnicalDomain is admitted as a profile type although it is not a contour candidate type.***Evidence.* Contour `candidate_types`: Team, Collective, CommunityOfPractice, Membership, WorkingAgreement. TechnicalDomain appears only in `specific_questions`; TeamAssignment appears nowhere in the contour.*Failure mode.* Silent scope expansion; a question-derived concept acquires the same standing as a chartered candidate type.*Remediation.* Annotate both entries: `"origin": "specific-question"` for TechnicalDomain, `"origin": "base-child-rename"` for TeamAssignment, and record that neither is a chartered candidate type of EM-ORG-05.*Fixture expectation.* `non-chartered-type-unannotated` (negative): input "profileTypes entry lacking `origin` for a type absent from `candidate_types`" → **expect refuse**.### C. Assignment / membership conflation**D11 — The TeamAssignment rename is name-only and leaves a cross-base function-id collision.***Evidence.* WM-ORG-003 retains finding id `membership-assignment-record`, data elements `membership_id`, `member_ref`, `member_during`, `inactive`, composition target "Membership assignment record (nested record type owned by WM-ORG-003)", and functions `assert-membership` and **`end-membership`**. WM-ORG-006 also declares a function **`end-membership`**. The candidate renames only the record label.*Failure mode.* Assignment/membership conflation at the operation and field level: two distinct `end-membership` operations across the two bases, and a `membership_id` that is in fact an assignment id.*Remediation.* Emit a complete rename map as profile-local aliasing (a profile MAY alias; renaming base ids is a base change request): `membership-assignment-record → team-assignment-record`, `membership_id → assignment_id`, `member_ref → participant_ref`, `member_during → assignment_period`, `assert-membership → assert-team-assignment`, `WM-ORG-003:end-membership → end-team-assignment`. Add: "Operation names MUST be base-qualified; an unqualified `end-membership` MUST be rejected as ambiguous." Route the base-side rename as a change request to WM-ORG-003.*Fixture expectation.* `unqualified-end-membership` (negative): input "`end-membership` invoked without base qualification" → **expect refuse with reason `ambiguous-operation`**. `assignment-id-named-membership-id` (negative) → **expect refuse**. `rename-map-complete` (positive): input "profile emitted with the full alias map" → **expect accept, with every base id covered**.**D12 — The conflation prohibition is one-directional.***Evidence.* Constraint forbids scheme, admission, standing, renewal, appeal and membership terms on TeamAssignment. Nothing forbids the reverse: `allocation`, `coverage_window`, `in_team_role`, `headcount` or `position_ref` migrating into a WM-ORG-006 membership. Fixture `membership-copy` tests only the forward direction.*Failure mode.* Assignment/membership conflation in the 006 direction; a membership record silently becomes a staffing record and acquires capacity semantics.*Remediation.* Add: "A WM-ORG-006 Membership MUST NOT carry team-scoped allocation, coverage window, in-team role, headcount or position reference; team-scoped participation facts are owned exclusively by the WM-ORG-003 TeamAssignment."*Fixture expectation.* `assignment-fields-in-membership` (negative): input "Membership record populated with allocation and coverage window" → **expect refuse**. Mark it the paired inverse of `membership-copy`.**D13 — "Governed participants" is circular; the Membership trigger is undefined.***Evidence.* Constraint: "A CommunityOfPractice MUST be a standing WM-ORG-003 collaboration profile whose **governed participants** reference WM-ORG-006 memberships." Fixture `cop-teamassignment-only` refuses assignment-only recording "despite governed admission". Nothing defines governed admission.*Failure mode.* Assignment/membership conflation: the discriminator that decides whether a Membership is mandatory is unstated, so identical instances may be modelled either way.*Remediation.* Define the trigger structurally: "A WM-ORG-006 Membership is REQUIRED for a participant when, and only when, the collective declares a named membership scheme with an admission basis and a standing vocabulary. Absent a declared scheme, participation is recorded solely as a TeamAssignment and no Membership may be invented." Add `schemeRef` as the observable discriminator and record it as a base gap if no carrier exists.*Fixture expectation.* Re-key `cop-teamassignment-only` on `schemeRef` presence and add `no-scheme-membership-invented` (negative): input "collective with no declared scheme creates Memberships for its staff" → **expect refuse**.**D14 — CoP assignment policy: constraint and fixture disagree.***Evidence.* Claude's Profile C prohibits assignment records in a CommunityOfPractice except within working groups. Revision 2 carries no such prohibition and permits assignments freely, while fixture `cop-teamassignment-only` refuses the assignment-only case. The constraint set and the fixture set therefore encode different rules.*Failure mode.* Conflation, plus an untestable profile: the fixture cannot pass against the constraints as written.*Remediation.* Adjudicate explicitly. Recommended: adopt the narrower rule — "Within a CommunityOfPractice, TeamAssignment records are permitted only for a nested working team; participation in the community itself MUST be a referenced Membership" — and record the adjudication of Claude's Profile C against Grok's looser reading.*Fixture expectation.* `cop-community-level-assignment` (negative): input "participation in the community itself recorded as a TeamAssignment" → **expect refuse**. `cop-working-group-assignment` (positive): input "member of the community staffed on its nested working team" → **expect accept one Membership plus one independently dated TeamAssignment**.**D15 — Organization-as-participant is unresolved; sponsor and participant may conflate.***Evidence.* WM-ORG-003's `boundaryDecision` rejects "organization-membered collaborations" as instances. The same spec's `external-and-non-human-participants` finding requires partner-organization members to be representable and sets `participant_kind` = "Person, organization, software agent or device", with `member_ref` "Reference to the person, organization or agent participating". The base contradicts itself; revision 2 is silent.*Failure mode.* Invalid inter-company cardinality and roster-derived authority: if an organization can be a participant, a sponsor may be inferred from the participant list, or a member firm may be read as a sponsor.*Remediation.* Record the base contradiction as a second blocking base-adjudication item alongside D01. For the profile, state the stricter reading pending adjudication: "Participants MUST be persons, software agents or devices; an organization MUST appear only as `on_behalf_of`, sponsor, manager, containing organization or record authority, never as a participant."*Fixture expectation.* `organization-as-participant` (negative): input "member firm recorded as a team participant" → **expect refuse with reason `base-contradiction-unadjudicated`**. `sponsor-equals-participant` (negative) → **expect refuse**.### D. Roster-derived access and authority**D16 — Entitlement inheritance across nesting and across organizations is unconstrained.***Evidence.* WM-ORG-003 exposes `nesting-and-inherited-membership` ("child teams inherit parent permissions; listed members of a parent include child members") and `team-entitlements-and-member-capabilities` ("are those entitlements inherited by child teams?", plus `nested_team_ref` 0..n). Claude's invariant 8 — inheritance follows only an explicit parent-child tree inside one record-authority domain and never crosses organizations — is **absent** from revision 2. No fixture covers it.*Failure mode.* Roster-derived access, exactly the contour's negative case, reached through the nesting path instead of the roster path: an inter-company collaboration nests a child team from another firm and inherits its entitlements.*Remediation.* Restore as a constraint: "Entitlement inheritance MUST follow only an explicit parent-child tree within a single record-authority domain. Inheritance MUST NOT cross a record-authority or organization boundary. A nested sub-team from a different sponsor MUST NOT inherit or confer entitlements."*Fixture expectation.* `cross-org-nested-inheritance` (negative): input "child team sponsored by Co-B nested under a collaboration whose record authority is Co-A; Co-A entitlements inherited" → **expect refuse**. `in-domain-nested-inheritance` (positive): input "child team inside one record-authority domain" → **expect accept inheritance, with inheritance recorded as an explicit dated grant, not a derivation**.**D17 — `resolve-effective-members` output is not fenced from authorization.***Evidence.* WM-ORG-003 function `resolve-effective-members` computes direct, inherited, guest, role-only and nested-group members at an observation time. Claude's invariant 3 ("effective-member resolution output must not be used as an authorization grant") is absent from revision 2; the candidate's prohibition names only "Membership, TeamAssignment and participant lists".*Failure mode.* Roster-derived access through a derived set rather than a stored list — the exact implementation path a conforming-looking system would take.*Remediation.* Extend the prohibition: "...participant lists, **and any derived or computed effective-member set**, MUST NOT grant employment, funding, product, repository, tenant or any other access or authority. `resolve-effective-members` output is a reporting projection and MUST be marked non-authoritative for authorization."*Fixture expectation.* `effective-member-set-as-grant` (negative): input "authorization decision built from `resolve-effective-members` output" → **expect refuse; conformance failure, not configuration**.**D18 — The IdP-sync / dynamic-rule path is unconstrained.***Evidence.* WM-ORG-003 exposes `membership-provisioning-and-sync-authority` (IdP synchronization enabled, dynamic membership rule, local write blocked). Its `researchAdjudication` accepted this **only** "on condition that any directory rule must materialise enumerated identified members, preserving the base rule that definitional rule-defined cohorts are not teams." Revision 2 drops the condition entirely.*Failure mode.* Two at once — a definitional cohort enters as a team (boundary breach), and an identity provider becomes the de facto membership authority, i.e. roster-derived access with the roster owned outside the record authority.*Remediation.* Restore verbatim as a constraint: "A directory or dynamic membership rule MUST materialise enumerated, identified members; rule-defined cohorts MUST NOT be recorded as collectives. IdP synchronization MUST NOT transfer record authority; `local write blocked` is an operational fact and MUST NOT be read as authority."*Fixture expectation.* `dynamic-rule-unmaterialised` (negative): input "collective whose membership is a directory rule with no enumerated members" → **expect refuse**. `idp-sync-as-record-authority` (negative): input "record authority inferred from the synchronizing IdP" → **expect refuse**.**D19 — Role-to-authority inference is not prohibited.***Evidence.* WM-ORG-003 exposes `decision_right` (named decision class, autonomy level, threshold, approver), `accountable_owner_ref`, and asks "Which role carries leadership of the team, and is it the same as the accountable owner?" plus "Which combinations of decision rights must not be held by the same person?" (NIST separation of duties). The contour invariant is "Права и финансирование не выводятся из списка участников". Revision 2 blocks roster→rights but is silent on role→authority.*Failure mode.* Authority derived from a membership or assignment role — a narrower but equally invalid form of roster-derived authority.*Remediation.* Add: "Decision rights MUST be separately asserted with an approver and threshold. An in-team role, a membership role, a lead label or an accountable-owner reference MUST NOT imply any decision right, and decision rights MUST NOT be derived from role vocabulary. Separation-of-duties constraints MUST be evaluated against asserted rights only."*Fixture expectation.* `lead-role-implies-decision-right` (negative) → **expect refuse**. `membership-role-implies-authority` (negative) → **expect refuse**. `decision-right-asserted` (positive): input "decision right with approver, threshold and validity" → **expect accept, independent of any role binding**.**D20 — Funding prohibition has no fixture.***Evidence.* Constraint 13 names funding; no fixture tests it. WM-ORG-003's `deferredResearch` records that team economics (budget, cost centre, chargeback) has **no authoritative source in either pack**.*Failure mode.* An untested contour invariant, over a concept the base explicitly cannot represent.*Remediation.* Add: "Budget, cost centre and chargeback are out of scope for this contour on the pinned bases; any funding attribution to a collective MUST be refused as unsourced, not merely unmodelled."*Fixture expectation.* `roster-implies-funding` (negative): input "cost centre derived from participant employers" → **expect refuse**. `team-budget-attribution` (negative): input "budget attached to a collective" → **expect refuse with reason `no-authoritative-source`**.### E. Employment inference**D21 — The employment plane is normatively required but has no pin and no identifier.***Evidence.* `timePlanes` includes `"employment"`; constraint 15 makes four-plane querying a `MUST`; constraint 16 and 17 govern employment effects. `publicationHolds` admits "Employment and access seams are not pinned in this frozen dossier." The provider comparison rules neighbouring identifiers "explanatory only and not adopted as verified dependencies," yet WM-ORG-006's own frozen adjudication names WM-ORG-005 ("while WM-ORG-005 represents a work relationship with labour-status, term and assignment semantics") — a model with no registry row, no spec, no sha, and no ledger row in this dossier.*Failure mode.* An unexecutable `MUST`, and an employment boundary whose authority rests on an unpinned model. Any implementer must either invent an employment model or collapse the plane — employment inference by omission.*Remediation.* (a) Downgrade constraints 15–17 to `conditional-MUST`, conditioned on `employmentPlane.pinned == true`. (b) Add `externalPlanes: [{name: "employment", modelId: null, dossierMention: "WM-ORG-006.researchAdjudication.decisions['Membership and employment'] cites WM-ORG-005", pinned: false, identifierAsserted: false}, {name: "accessGrant", modelId: null, pinned: false}]`. (c) Record that WM-ORG-006's Employment boundary note is unverifiable on this dossier because its counterparty model is absent, and that WM-ORG-006's registry still points at the fused O3 card — so the employment/membership separation is asserted, not demonstrated.*Fixture expectation.* `employment-plane-unpinned` (negative): input "four-plane as-of query executed with the employment plane unpinned" → **expect refuse with reason `plane-unpinned`, and specifically MUST NOT return `absent` for employment**. `employment-absent-vs-unknown` (negative): input "missing employment plane rendered as `no employment`" → **expect refuse; `unknown` is the only permitted rendering**.**D22 — Overlap cases that invite employment inference are untested.***Evidence.* Fixtures cover assignment→employment, membership→employment, onBehalfOf→employment, team-end→employment. Untested: `on_behalf_of` equal to a sponsor organization; a participant whose `on_behalf_of` is the record authority; a Membership in a sponsor body read as employment by that sponsor; employment ending while an assignment remains open.*Failure mode.* Employment inference through the sponsor/record-authority seam, which is precisely where the inter-company profile concentrates organizations.*Remediation.* Add constraints: "`on_behalf_of` coinciding with a sponsor, manager, containing organization or record authority MUST NOT create, imply or evidence employment"; "An open TeamAssignment after employment ends MUST remain open until separately closed, with review recorded as an event."*Fixture expectation.* `onbehalfof-equals-sponsor` (negative) → **expect refuse any employment inference**. `employment-ends-assignment-open` (positive) → **expect assignment remains open, a review event is recorded, no auto-close**.### F. WorkingAgreement ownership**D23 — The owned WorkingAgreement has no base carrier.***Evidence.* WM-ORG-003's charter layer exposes `purpose`, `expected_functions`, `charter_effective_period`, `mandate_obligation_ref` — no working-agreement element and no per-component version field. The only `working_agreement` field in the dossier is the Enterprise v1 `ORG-06` candidate field, explicitly `candidate-not-normative` and declared non-normative by `evidence_limits`.*Failure mode.* WorkingAgreement ownership error: ownership is asserted over a structure that does not exist in the base, and implementers will overload `mandate_obligation_ref`, whose stated semantics are "Citation of any legal or contractual instrument that **compels the team's existence or composition**" — the wrong semantics for locally authored conduct rules.*Remediation.* Record a `baseGap` for an owned, independently versioned `working_agreement` component under the charter layer. Add: "`mandate_obligation_ref` MUST NOT be used to carry an owned WorkingAgreement; it is reserved for compelling external instruments." Until the base carries the component, mark the owned-WorkingAgreement rule `profile-proposal-not-enforceable`.*Fixture expectation.* `working-agreement-in-mandate-ref` (negative): input "owned conduct rules stored in `mandate_obligation_ref`" → **expect refuse**. Re-scope existing `working-agreement-owned` to `pending-base-element` — as written it asserts a positive outcome for a component the base cannot hold.**D24 — Admission rules may be captured by the WorkingAgreement, taking WM-ORG-006-owned terms.***Evidence.* Grok's study places "this CoP's **admission bylaws**" inside the owned WM-ORG-003 charter component. WM-ORG-006 owns `admission-rejection-decision-conditions-and-effective-time`, `permission-prohibition-duty-and-compliance-reference`, and the whole `terms-duties-fees-and-benefits` bundle, and revision 2's constraint 2 makes WM-ORG-006 "the sole master of governed admission-based membership, scheme, standing, validity, terms, roles and evidence." The candidate inherited Grok's formulation without adjudicating the collision.*Failure mode.* WorkingAgreement ownership error plus mastership breach: admission and standing rules migrate into a WM-ORG-003 charter component, which is the same conflation the contour exists to prevent.*Remediation.* Add: "An owned WorkingAgreement MUST be limited to the collective's own conduct and ways of working. Admission criteria, eligibility, standing vocabulary, disciplinary and appeal rules, dues and membership terms MUST be owned or referenced by WM-ORG-006 and MUST NOT appear in a WM-ORG-003 charter component." Record the Grok formulation as explicitly rejected.*Fixture expectation.* `admission-rules-in-working-agreement` (negative): input "CoP admission bylaws stored as an owned charter component" → **expect refuse; route to WM-ORG-006 scheme terms**.**D25 — Owned-agreement versioning, uniqueness and edition-pin rules are incomplete.***Evidence.* Constraint 11 requires immutable identity plus edition pin for referenced instruments, but sets no version rule for owned agreements, no rule against a single owned agreement being shared by several collectives, and no rule on what happens when an owned agreement is later published as a reusable template. Fixture coverage is two cases (`working-agreement-owned`, `working-agreement-multipart-copy`).*Failure mode.* Ownership error and history rewrite: an owned agreement edited in place, or shared and then silently normative for collectives that never approved it.*Remediation.* Add: "An owned WorkingAgreement MUST carry its own version and approval reference and MUST be approved with, or alongside, the charter"; "An owned WorkingAgreement MUST belong to exactly one collective; sharing it across collectives requires conversion to a referenced instrument with an edition pin"; "Conversion from owned to referenced MUST be a dated event preserving the prior owned editions."*Fixture expectation.* `owned-agreement-shared` (negative) → **expect refuse; require conversion**. `owned-agreement-edited-in-place` (negative) → **expect refuse; require a new edition**. `owned-to-referenced-conversion` (positive) → **expect accept with a dated conversion event and prior editions retained**.### G. Temporal-plane integrity**D26 — No crosswalk between the two bases' time vocabularies.***Evidence.* WM-ORG-003: `event_time` (required 1), `observed_at` (required 1), `validity_interval` (0..1), `status_changed_at`, `formed_at`, `dissolved_at`, `charter_effective_period`. WM-ORG-006: valid time, **decision time**, event time, observation time, knowledge time (`valid-decision-event-observation-and-knowledge-time`, required 1). Revision 2 names four planes and one `(valid-time, knowledge-time)` pair, and reconciles nothing.*Failure mode.* Temporal-plane collapse at the join: `observed_at` silently equated with knowledge time, and WM-ORG-006's **decision time has no WM-ORG-003 counterpart at all**, so admission decision time will collapse into assignment event time.*Remediation.* Add a `timeAxisCrosswalk` table mapping, per base, each axis to the profile's canonical `validTime` / `knowledgeTime`, with explicit `noCounterpart` entries (WM-ORG-006 decision time; WM-ORG-003 `status_changed_at` vs status valid time). Add: "Axes with no counterpart MUST be preserved on their own base and MUST NOT be projected onto a counterpart axis."*Fixture expectation.* `decision-time-collapsed` (negative): input "admission decision time rendered as assignment event time" → **expect refuse**. `observed-at-as-knowledge-time` (negative): input "`observed_at` used as knowledge time without a declared crosswalk" → **expect refuse**. `crosswalk-complete` (positive) → **expect every base axis mapped or marked `noCounterpart`**.**D27 — No timestamp serialization or unknown-offset rule.***Evidence.* WM-ORG-003's `effective-dating-and-time-semantics` requires RFC 3339 with full date, full time with seconds, explicit offset or `Z`, and reserves `-00:00` for an unknown local offset; WM-ORG-006 aligns to OWL-Time + RFC 3339 and is subject to a repair hold on unregistered RFC 3339 citations in merged nodes. Revision 2 says nothing about serialization, unknown offsets, open-ended intervals or precision.*Failure mode.* Temporal-plane collapse through representation: naive local times, `-00:00` misread as UTC, open-ended intervals rendered as closed.*Remediation.* Add: "All instants MUST be RFC 3339 with seconds and an explicit offset or `Z`; `-00:00` MUST be used for and only for an unknown local offset and MUST NOT be normalised to `+00:00`; open-ended intervals MUST be represented as an explicit open end and MUST NOT be closed at query time; date-only values MUST be rejected where an instant is required."*Fixture expectation.* `unknown-offset-normalised` (negative) → **expect refuse**. `open-ended-interval-closed-at-query` (negative) → **expect refuse**. `rfc3339-serialization` (positive) → **expect accept only conforming instants**.**D28 — Cross-plane closure cases are untested.***Evidence.* Fixtures cover membership-end→grant, team-end→employment. Untested: assignment end closing a membership (Claude invariant 9, first clause); membership suspension rendered as assignment inactivity; grant expiry rendered as membership end; membership standing change propagating to assignment state.*Failure mode.* Temporal-plane collapse in exactly the directions the contour's independence requirement targets.*Remediation.* Add a symmetric non-propagation constraint: "A state or interval change on any one plane MUST NOT propagate to another plane; every cross-plane effect MUST be a separately authored, separately dated assertion."*Fixture expectation.* `assignment-end-ends-membership` (negative) → **expect refuse**. `membership-suspension-sets-assignment-inactive` (negative) → **expect refuse**. `grant-expiry-ends-membership` (negative) → **expect refuse**. `standing-change-isolated` (positive): input "community standing changes while the member's team assignment is open" → **expect assignment unchanged**.**D29 — Dissolution may backdate assignment ends.***Evidence.* Constraint 17 requires dissolution to close open TeamAssignments; `collective-dissolution` expects "close assignments only". No rule governs the closing instant. WM-ORG-003 closes memberships by "setting its end instant and inactive flag."*Failure mode.* History rewrite by backdating: assignment periods retroactively shortened to the dissolution instant, or earlier, with no correction record.*Remediation.* Add: "Closure of an assignment at dissolution MUST use the dissolution event time and MUST NOT backdate before it. Any earlier end instant MUST be recorded as a separate dated correction with its own knowledge time and a preserved prior assertion."*Fixture expectation.* `dissolution-backdates-assignment` (negative) → **expect refuse**. `dissolution-closure-at-event-time` (positive) → **expect accept, prior assertions preserved**.### H. History rewrite and erasure**D30 — `entered-in-error`, erasure and legal hold are unaddressed.***Evidence.* WM-ORG-003 stresses that `entered-in-error` "separates a team that ended from a team that never should have been recorded, which is an erasure-relevant distinction"; its retention finding prefers anonymisation over deletion and exposes `legal_hold`. WM-ORG-006 holds that "no steward may silently erase disagreement, correction or appeal evidence" and controls existence privacy. Revision 2 has one generic append-only constraint and no erasure, tombstone, `entered-in-error` or legal-hold rule.*Failure mode.* History rewrite dressed as correction: a genuinely ended collective marked `entered-in-error` to erase it; an erasure request executed as deletion of membership history; disposal executed under legal hold.*Remediation.* Add: "`entered-in-error` MUST NOT be used for a collective that genuinely existed; normal ending MUST use dissolution"; "Erasure and objection MUST be satisfied by anonymisation or tombstoning where history must be preserved; membership, assignment and change-event history MUST NOT be deleted"; "Disposal MUST be suspended while a legal hold is asserted"; "Disagreement, correction and appeal evidence on WM-ORG-006 MUST survive any WM-ORG-003 lifecycle action."*Fixture expectation.* `entered-in-error-as-erasure` (negative) → **expect refuse**. `erasure-deletes-membership-history` (negative) → **expect refuse; anonymise or tombstone**. `disposal-under-legal-hold` (negative) → **expect refuse**. `appeal-evidence-survives-dissolution` (positive) → **expect WM-ORG-006 appeal evidence intact after the collective dissolves**.**D31 — The append-only constraint has no fixture.***Evidence.* Constraint 19 ("Corrections MUST append superseding assertions and preserve event time, valid time and knowledge time") appears in no fixture case.*Failure mode.* The single strongest anti-history-rewrite rule in the candidate is untested.*Remediation.* No text change required beyond D26's crosswalk; add direct coverage.*Fixture expectation.* `correction-appends` (positive): input "backdated membership correction" → **expect a new superseding assertion, prior assertion retrievable, all three time axes preserved**. `correction-overwrites` (negative): input "in-place edit of a prior assertion" → **expect refuse**.### I. Fixture integrity and release claims**D32 — Fixture digests are unverifiable and unbound.***Evidence.* Every case carries `sha256` with `digestMeaning: "SHA-256 of canonical JSON case definition only; no execution meaning"`. No canonicalization algorithm is named (key ordering, whitespace, Unicode normalisation, which fields are covered). There is no digest over the fixture file as a whole and no binding of the fixture set to `basePins`.*Failure mode.* Unsupported release claims: digests give the appearance of integrity with no verifiable procedure, and a fixture set can be replayed against a drifted base without invalidation. The honest `digestMeaning` disclaimer is good practice and is not itself a defect.*Remediation.* Name the canonicalization (RFC 8785 JSON Canonicalization Scheme is the obvious choice) and the exact covered field set; add `fixtureSetSha256`; add `baseBinding: {WM-ORG-003: <sourceSha256>, WM-ORG-006: <sourceSha256>}` with the rule "any base sha drift invalidates the fixture set and every recorded digest."*Fixture expectation.* `digest-canonicalization-unspecified` (negative): input "fixture set published without a named canonicalization" → **expect refuse**. `fixture-base-drift` (negative): input "fixtures executed against a base whose `sourceSha256` differs from `baseBinding`" → **expect refuse with reason `base-drift`**.**D33 — Base publication holds are not carried forward.***Evidence.* WM-ORG-003 carries five holds (29 URLs to re-fetch and re-pin; four-profile multi-domain validation unrun; paywalled/landing-page-only evidence — ISO 30414:2025, ISO 30400:2022, ISO 21502, ArchiMate; seven accepted additions and four functions resting on tier-2 vendor documentation; RFC 3339 citation-provenance repair). WM-ORG-006 carries six (Claude and Grok timed out, so no independent external review; the fused O3 lineage; empty relation ledger; unreviewed membership profiles; unverified crosswalks and privacy tests; owner-waived external review). Revision 2's five holds compress all of this into "Both bases are non-canonical reviewable drafts."*Failure mode.* Unsupported release claims by omission: eleven specific base holds become one generic sentence, and a reader cannot tell which are unresolved.*Remediation.* Add `inheritedHolds` enumerating all eleven by base and verbatim text, with a rule: "Inherited holds MUST be carried forward verbatim and MUST NOT be summarised, merged or discharged by this contour."*Fixture expectation.* `inherited-holds-summarised` (negative): input "candidate published with base holds compressed" → **expect refuse**. `inherited-holds-complete` (positive) → **expect all eleven present and individually addressable**.**D34 — The inter-company mechanism's tier-2 evidence dependence is undisclosed.***Evidence.* WM-ORG-003's hold states that "all seven accepted additions and four of the five accepted functions rest wholly or partly on tier-2 vendor documentation" and must be re-checked against tier-1 sources, with vendor vocabularies published as projection detail rather than base semantics. The candidate's central machinery — `containing-and-managing-organization`, `nesting-and-inherited-membership`, `membership-provisioning-and-sync-authority`, `team-entitlements-and-member-capabilities` — is drawn from exactly those accepted additions (sources SRC-019 through SRC-026: GitHub, Microsoft Graph and similar).*Failure mode.* Unsupported release claims: the load-bearing mechanism of the profile silently inherits a tier-2 evidence hold, and vendor vocabulary risks being read as base semantics.*Remediation.* Add `evidenceTier` per structural claim in `interCompanyContract` and in the nesting/entitlement constraints, marking each `tier-2-pending-tier-1-recheck`, and state: "Vendor-derived vocabularies (visibility, nesting, archive states, sync flags) are projection detail and MUST NOT be published as base semantics of this profile."*Fixture expectation.* `tier2-claim-unmarked` (negative): input "structural claim derived from a tier-2 accepted addition published without an evidence-tier marker" → **expect refuse**.**D35 — Provenance and expectation records are incomplete.***Evidence.* `provenance.audit: "pending"` with no auditor identity, date, scope or artifact hash; no `invalidationRule` on the fixture set (only on base pins); every fixture `expect` is prose ("refuse", "accept; no Membership invented") with no machine-checkable assertion, no reason code and no stated failure mode.*Failure mode.* Unsupported release claims: `fixturesExecuted: false` is honest, but the fixtures as written cannot be executed to a determinate result even once tooling exists, so "fixtures executed" could later be claimed on prose matching.*Remediation.* Populate `provenance.audit` with `{artifact, auditorRole: "frozen-independent", date: "2026-09-29", scope: "dossier + two studies + comparison + candidate r2 + fixtures r2", coverageLimit: "selected_findings projection only"}`. Give every fixture case a `reasonCode`, an `assertions` array and an explicit `failureMode`. Add: "A fixture without a reason code and assertions MUST NOT be counted toward `fixturesExecuted`."*Fixture expectation.* `fixture-without-assertions` (negative): input "case with prose expectation only" → **expect refuse from the executable set**.---## 5. Contradiction registerContradictions among dossier, providers, candidate and fixtures. Each maps to the defect that must resolve it.| # | Contradiction | Parties | Defect ||---|---|---|---|| X1 | Containment is `1`/required in WM-ORG-003 composition and in `team-boundary-and-entity-distinction`, and `0..1`/optional in `containing-and-managing-organization` | Dossier internal (WM-ORG-003) | D01 || X2 | `boundaryDecision` rejects organization-membered collaborations as instances, while `external-and-non-human-participants` requires organization participants and `participant_kind` admits "organization" | Dossier internal (WM-ORG-003) | D15 || X3 | `boundaryDecision` rejects definitional membership, while `membership-provisioning-and-sync-authority` admits dynamic directory rules and `membership_basis` retains a `definitional` code | Dossier internal (WM-ORG-003) | D18 || X4 | WM-ORG-006 registry says `described-previous-version` with legacy alias O3 (fused Employment+Membership) while the spec declares `previousVersions: []` | Registry vs spec | D05 || X5 | Both registry rows declare `entry_kind: standalone-mm`; specs declare `aggregate` and `relationship` | Registry vs specs | D05 || X6 | WM-ORG-006's Employment boundary cites WM-ORG-005, which has no registry row, spec, sha or ledger row; the comparison declares neighbouring identifiers "explanatory only" while the candidate makes the employment plane a normative `MUST` | Dossier vs comparison vs candidate | D21 || X7 | Ledger row `WM-ORG-001 CONTAINS WM-ORG-003` vs candidate's optional containment | Ledger vs candidate | D04 || X8 | WM-ORG-003 `COMPOSE WM-ORG-004` is `required: true`, but neither study nor candidate states whose position catalogue serves a cross-company collective | Dossier vs candidate | D03 || X9 | Claude: Collective is **REUSE ONLY, not a model**. Grok: Collective is a **collaboration profile**. Candidate adopts Grok silently, with no adjudication note | Claude vs Grok vs candidate | D07 || X10 | Team: Claude = PROFILE (two profiles); Grok = "003 subject"; candidate = "profile-local label over WM-ORG-003" — three distinct dispositions | Claude vs Grok vs candidate | D07 || X11 | Claude's Profile C prohibits assignment records in a CoP except within working groups; candidate permits them; fixture `cop-teamassignment-only` refuses assignment-only recording | Claude vs candidate vs fixtures | D14 || X12 | Claude invariant 8 (inheritance never crosses organizations) and invariant 3 (effective-member output is not a grant) are dropped, yet the comparison asserts both providers "refuse roster-derived authority" as settled convergence | Claude vs candidate vs comparison | D16, D17 || X13 | Grok places CoP **admission bylaws** in the owned WM-ORG-003 charter component; candidate constraint 2 makes WM-ORG-006 sole master of admission and terms | Grok vs candidate | D24 || X14 | Fixture `intercompany-cardinality` accepts a collaboration with no containing organization, which the pinned base forbids at two of three points | Fixtures vs dossier | D01 || X15 | WM-ORG-006's adjudication holds all sibling composition as **draft** ("the approved relation ledger contains no WM-ORG-006 rows"), while the candidate states the WM-ORG-003→WM-ORG-006 reference in unconditional `MUST` modality | Dossier vs candidate | D03, D33 || X16 | Both bases declare function `end-membership`; the candidate renames the record but not the operation | Dossier internal (cross-base) vs candidate | D11 || X17 | Candidate's "no new identifier" claim vs its introduction of TeamAssignment, sponsor, record authority and obligation bearer as named structures absent from both bases | Candidate internal | D02, D11 || X18 | `publicationHolds` admits the containment contradiction and the unpinned employment seam, while `constraints` asserts the containment value and the four-plane `MUST` as settled | Candidate internal (hold vs constraint modality) | D01, D21 || X19 | Comparison characterises provider convergence as near-total; Claude in fact refuses Collective as a profile, conditions any CoP identifier on a three-part test, and flags a base contradiction Grok does not raise | Comparison vs Claude | D08, X9 || X20 | Candidate `profileTypes` includes TechnicalDomain and TeamAssignment, neither of which is a contour `candidate_type` | Contour vs candidate | D10 |---## 6. Closed remediation checklistFinite and complete. Each item has a single stated closure condition. Items R1–R3 are blocking: no further item may be marked closed while any of them is open.1. **R1 (blocking).** Adjudicate the WM-ORG-003 containment contradiction (X1) in the base. Remove `0..1` from candidate `constraints`; record `containment: unresolved` with the three conflicting base loci; raise the base change request. *Closed when:* the base states one cardinality and the candidate cites it. — D01, D042. **R2 (blocking).** Adjudicate the organization-as-participant contradiction (X2) in the base; adopt the stricter reading in the profile meanwhile. *Closed when:* the base resolves `participant_kind` against its own `boundaryDecision` and the profile cites the resolution. — D153. **R3 (blocking).** Convert `sponsors`, `recordAuthority` and `obligationBearer` from asserted constraints into `baseGap` extension requests; downgrade to `profile-proposal-not-enforceable`. *Closed when:* each has a named base element or is withdrawn. — D024. **R4.** Extend `basePins` with `requiredDependencies` (WM-ORG-001, WM-ORG-004, Person/Worker, PROV-O mix-in), each `pinned: false` under the same invalidation rule; state the cross-company position-catalogue gap. — D03, X85. **R5.** Add `registryEntryKind` / `specEntryKind` divergence, legacy alias, legacy spec ref, `previousVersionsDeclared` and `registrySnapshotSha256` to both pins. — D056. **R6.** Null out `profileTypes.Membership.registryId`; introduce `baseModelId` / `baseRegistryRef`; forbid profile labels from populating identifier fields. — D067. **R7.** Add `profileSelection` binding every profile to `boundary_class` and `permanence` code values; forbid storing profile labels as classification. — D078. **R8.** Restore the CommunityOfPractice promotion test (three conditions, all required) and the TechnicalDomain split trigger, with no-identifier-on-partial-satisfaction. — D089. **R9.** Add structural-change identity-retention and duplicate-tombstoning constraints. — D0910. **R10.** Annotate TechnicalDomain (`origin: specific-question`) and TeamAssignment (`origin: base-child-rename`) as non-chartered types. — D1011. **R11.** Publish the full rename/alias map covering `membership-assignment-record`, `membership_id`, `member_ref`, `member_during`, `assert-membership` and WM-ORG-003 `end-membership`; require base-qualified operation names; raise the base-side rename request. — D11, X1612. **R12.** Add the inverse conflation prohibition (no team-scoped allocation, coverage, in-team role, headcount or position reference on a WM-ORG-006 Membership). — D1213. **R13.** Define the Membership trigger structurally on a declared `schemeRef`; forbid inventing Memberships absent a scheme; re-key `cop-teamassignment-only`. — D1314. **R14.** Adjudicate Claude's Profile C against Grok; adopt the working-group-only rule for CoP assignments and align constraint with fixture. — D14, X1115. **R15.** Restore the cross-organization inheritance prohibition, fence `resolve-effective-members` output from authorization, restore the dynamic-rule materialisation condition and the IdP-is-not-authority rule, and add the role→authority prohibition and the funding rules. — D16, D17, D18, D19, D20, X1216. **R16.** Downgrade the four-plane constraints to conditional on a pinned employment plane; add `externalPlanes` with `identifierAsserted: false`; record that the WM-ORG-006 Employment boundary is unverifiable on this dossier; add the sponsor/record-authority overlap prohibitions. — D21, D22, X617. **R17.** Record a `baseGap` for an owned, independently versioned WorkingAgreement component; forbid overloading `mandate_obligation_ref`; reject Grok's admission-bylaws-in-charter formulation; add owned-agreement versioning, single-owner and conversion rules. — D23, D24, D25, X1318. **R18.** Publish the `timeAxisCrosswalk` with explicit `noCounterpart` entries (notably WM-ORG-006 decision time); add RFC 3339 serialization, `-00:00` and open-interval rules; add symmetric cross-plane non-propagation; add the dissolution non-backdating rule. — D26, D27, D28, D2919. **R19.** Add `entered-in-error`, erasure/anonymisation, tombstone, legal-hold and appeal-evidence-survival rules; add direct coverage of the append-only constraint. — D30, D3120. **R20.** Name the fixture canonicalization and covered fields; add `fixtureSetSha256` and `baseBinding` with a drift-invalidation rule; give every case a `reasonCode`, `assertions` and `failureMode`; bar prose-only cases from `fixturesExecuted`. — D32, D3521. **R21.** Add `inheritedHolds` carrying all eleven base holds verbatim (five from WM-ORG-003, six from WM-ORG-006), non-summarisable and non-dischargeable by this contour. — D33, X1522. **R22.** Mark every `interCompanyContract`, nesting and entitlement claim with `evidenceTier: tier-2-pending-tier-1-recheck`; bar vendor vocabularies from base semantics. — D34, X323. **R23.** Record the eight unresolved provider/comparison divergences (X9, X10, X11, X12, X13, X14, X19, X20) as explicit adjudications in the candidate rather than silent adoptions.24. **R24.** Populate `provenance.audit` with auditor role, date, scope and the stated coverage limit (selected-findings projection: 19 of 31 and 12 of 32 findings visible); re-run every "absent from the base" finding above against the full specs. — D35, §325. **R25.** Issue candidate revision 3 and fixture revision 3 together, with `candidateStatus: "frozen-audit-revise-applied"`, `publishableCanonical: false`, `fixturesExecuted: false`, and re-audit. *Closed when:* R1–R24 are each closed and a subsequent frozen audit returns ACCEPT.No item on this list is open-ended; no item requires evidence outside the frozen dossier except R1, R2, R3, R4, R16, R17 and R22, each of which is explicitly a base or dependency action rather than a profile action. Nothing in this audit asserts canonical status, approved relations, executed fixtures, conformance to W3C ORG, FHIR or SCIM, or installability.