# Frozen semantic audit — EM-STR-03 (single pass, closed) ## 1. Verdict **REVISE.** The fixed identity decision is sound and is not reopened here. The *artifacts* do not yet carry it: the outcome-class identity rule has no enforceable expression, the non-system-realizer invariant is vacuous as drafted, coverage/missingness invariants reference records that do not exist, both candidates lack any version or knowledge-time apparatus, the profile artifact re-imports the retired meaning through its own `bases` list, and the WM-ACT-001 narrowing is asserted with no migration mechanism. These are defects in the submitted artifacts, not consequences of the registry holds. --- ## 2. Material defects ### D1 — Outcome-class identity is declared but unenforceable `allocation-candidate.json` (BusinessCapability): `"identityTest":{"stableIdentity":"An enterprise ability defined by an outcome class and acted-upon object remains identifiable…"}` and invariant `"Capability identity is outcome-defined…"`. But `"objects":{"BusinessCapability":{"identity":["businessCapabilityId"]}}` — identity is a bare surrogate. There is no uniqueness, equivalence or deduplication rule over `(outcomeClass, actedUponObject)`, and `outcomeClass` is an unstructured required field with no scheme, vocabulary or term reference. Two records with identical outcome class and object are both well-formed with different surrogates. grok-study names this exactly: `"Outcome-class naming, equivalence, and deduplication rules are undefined."` claude-study specifies an identity priority (`"capability-register master key → governed IRI → minted UUID/ULID marked surrogate"`) that the artifact does not carry — there is no master-key field and no surrogate marking. ### D2 — Two incompatible change mechanisms for the same trigger `identityTest.versionIdentity`: `"Changes to outcome semantics, applicability or governed scope create immutable capability versions"`. Fixture `new-outcome-class`: input `"A governed ability changes to a materially different outcome class."` → expect `"A successor or distinct capability is created with lineage."` One says *version under stable identity*, the other says *new identity*. Neither names the boundary between them. The expectation is itself disjunctive (`"successor **or** distinct"`) and therefore unexecutable as a test. Compounding this: `objects.BusinessCapability` has no version field at all — no `versionId`, no effective interval, no `predecessorRef` — so the versioning limb cannot be represented even if chosen. ### D3 — Decomposition is owned but not modelled `boundary.owns` includes `"capability decomposition edges"` and `"tier and specialization metadata"`; invariants require `"Tier labels are versioned edge attributes and never identity"` and `"Re-decomposition supersedes edges while capability identities remain stable."` `objects` contains one object, `BusinessCapability`, with no `parentRef`, no edge object, no edge validity interval, no edge supersession field. Three invariants have no bearer. Edge mastership is also undefined — an edge spans two capabilities and `owns` assigns it to the capability record without saying which end. claude-study's `"siblings are mutually exclusive at that tier"` is dropped from the reconciled invariants and from both fixture sets. ### D4 — BusinessCapability boundary leaks into realization `boundary.excludes` contains `"capability realization binding"`, yet `boundary.owns` contains `"required realization and assessment references"` and `boundary.references` lists `{"target":"WM-ORG-002","purpose":"Organizational-unit **realizer**"}`, `{"target":"WM-ACT-003","purpose":"Process or workflow realization method"}`, `{"target":"WM-MAT-008","purpose":"Performance observation"}`. These are the realization-side referents, duplicated verbatim in the CapabilityRealization candidate. Two directed representations of the same binding exist with no declared authoritative direction, so they can diverge. `"accountability and stewardship bindings"` (BC `owns`) and `"accountable party"` (CR `owns`) duplicate accountability across both objects with no precedence rule. ### D5 — WM-ACT-001 is referenced by the wrong candidate; non-agent capacity has no referent BusinessCapability references `{"target":"WM-ACT-001","purpose":"Agent-scoped function, competence, proficiency and capacity"}` while its own invariant states `"Agent Function or Competence and Business Capability never share identity or mastership."` The reference has no stated use on the capability and re-establishes the coupling the fixed decision severs. Conversely, CapabilityRealization — which carries `capacityRef` and whose invariant is `"Capacity is period-scoped and attaches to realization"` — does **not** list WM-ACT-001 in its references at all, although claude-study locates capacity in `WM-ACT-001 capacityStatement`. Additionally, `capacityStatement` is agent-scoped; realizers of kind system, resource or supplier have no capacity referent anywhere. ### D6 — The non-system-realizer invariant is vacuous; realizer granularity contradicts the acceptance scenario CapabilityRealization `required` includes `accountablePartyRef`, so **every** well-formed binding has an accountable party. Invariant `"Full realization requires an accountable non-system realizer"` is therefore satisfied by construction on any record whose accountable party is a unit or position — including a system-only binding. The negative fixture `system-alone-full` (`"A system-only binding is labelled full realization"` → `"The conclusion is rejected."`) cannot be constructed as a failing case. The root equivocation: invariant 1 is `"Every realization binds one capability to one explicit realizer"`, but claude-study's acceptance tuple is `R1(C, P, primary, accountable U1)` — process realizer plus unit accountable, i.e. two participants — and the fullness invariant counts the accountable party *as* a realizer. grok-study records the open question: `"Realization granularity is undecided: one realization per binding tuple, or one realization with many participants."` Separately, fullness is a property of the binding **set** as-of a date; no object or field bears a fullness claim. ### D7 — Self-cancelling system-realizer rules; evidence sufficiency absent Adjacent invariants in the same file: `"Full realization requires an accountable non-system realizer."` and `"A system-only binding is supporting realization **unless stronger governed evidence exists**."` The second voids the first, and contradicts local-evidence (`"A system is at most a supporting realizer"`) and claude-study (`"A system is at most a supporting realizer"`). The exception is unbounded because grok-study records `"Evidence-sufficiency rules are missing, including how supplier or system support counts."` `evidenceRefs` is optional and carries no digest and no criterion linkage, though local-evidence requires `"Evidence carries digest and criterion linkage."` ### D8 — Coverage share: required denominator has no field, overlap has no rule Invariant: `"Coverage share declares basis, denominator and effective period."` The object offers `coverageShare` and `coverageBasis`, both optional, and **no denominator field**; the effective period is only the binding's own `validFrom`/`validTo`, which is not necessarily the share's measurement period. Fixture `partial-realization` (`"Two teams realize different shares of one capability"`) exercises concurrent shares with no summation, overlap or common-denominator constraint. Nothing declares coverage to be derived-only, so a stored coverage value on BusinessCapability is not prohibited — and BC `owns` `"required realization and assessment references"` gives it a landing place. ### D9 — The completeness assertion is relied on and does not exist BC invariant `"Missing realization or measurement is unknown or absent, never zero"`; CR invariant `"Missing bindings mean unknown unless scoped completeness proves coverage"`; local-evidence `"unless a scoped completeness assertion proves coverage of the relevant population"`; claude-study `"Map completeness is an explicit scoped assertion, never implied."` No completeness-assertion object, field or referent appears in any artifact — no population, scope, as-of, asserter or method. The exception clause of a core invariant points at nothing, so the invariant has no decision procedure. ### D10 — Coverage-state vocabulary conflicts with the unknown rule and conflates dimensions `profile-candidate.json`: `"Coverage projections distinguish unrealized, partially realized, realized-but-low-maturity and unassessed."` Four states, all determinate; **no `unknown`** — directly contradicting D9's invariants that missing bindings are unknown. Separately, `realized-but-low-maturity` fuses the realization dimension with the maturity dimension inside one state value, against the invariant `"Maturity, performance and capacity remain separate dimensions with separate evidence"` in the same file. ### D11 — Scenario separation has no discriminator BC `excludes` `"scenario or target-state projection"`; both candidates assert `"Scenario values never become authoritative actuals."` CapabilityRealization has no `assertionMode`, no `scenarioRef` and no target-state flag. The only candidate discriminator is lifecycle state `proposed`, which is ambiguous between "draft record" and "planned future realization". A scenario binding and an actual binding are indistinguishable at the field level, so the invariant is unenforceable. ### D12 — No version or knowledge time; "never rewrites history" cannot hold `objects.BusinessCapability` has **no temporal field of any kind** — no register effective interval, no assertion time, no source or asserter. CapabilityRealization has `validFrom`/`validTo` only: valid time, no transaction/knowledge time, no asserter, no provenance. claude-study requires keeping separate `"capability register effective interval; realization validity interval; assessment validity window; observation phenomenon/result/ingestion times; assertion knowledge time."` With valid time only, an in-place correction of an error is indistinguishable from a real-world change, and the invariant `"Transfer creates a successor binding and never rewrites prior accountability"` has no storage model to enforce it. ### D13 — Succession chain is breakable `successorRef` is **optional**; there is no `predecessorRef`; no rule binds `R1.validTo` to `R2.validFrom`; no rule forces `R1.status` to a terminal state on transfer; `validTo` is optional even for terminal states. The acceptance result asserts `"R1 closes at transfer time and successor R2 opens with U2 accountable"` and fixture `unit-transfer` expects `"R1 closes and successor R2 opens"` — neither is derivable from the declared fields. A record with `status":"ended"` and no `validTo` is well-formed. ### D14 — Lifecycle states are undefined or overlapping Both objects carry `constrained` with no definition, no entry/exit condition and no declared effect on coverage projections. BusinessCapability carries `deprecated`, `superseded` and `retired` with no distinction and no transition rules; `superseded` is permitted with `successorRef` absent. CapabilityRealization carries both `transferred` and `superseded` with overlapping meaning — the transfer fixture does not say which applies. ### D15 — Required level, actual level and scale have no bearer local-evidence: `"Required level is a demand statement with driver, horizon and pinned scale."` claude-study's minimal set includes `"CapabilityRequirement / level statement (contained)"` — contained in nothing that exists. No requirement object, no `scaleRef`, no scale version pin appears in any artifact, while `profile-candidate.json` requires assessments to pin `"criteria, scale, aggregation, decision rule"`. The invariant `"Required level, actual level, maturity, performance and capacity remain distinct"` has no records to be distinct across. *Hold/defect split:* publication of a scale registry is a hold; the absence of a `scaleRef` slot and a designated scale-owner field in these artifacts is an artifact defect. ### D16 — Resolvability and non-cascade are asserted without mechanism `"Retired capabilities remain resolvable for historical realizations and assessments"` and `"Ended realizations remain resolvable for historical coverage and assessment"` — no tombstone field, no prohibition on hard delete, no referential-integrity rule, although claude-study notes WM-ORG-002 does carry `"lineage and tombstones"`. grok's invariant 16 (`"Ending a realization does not retire the capability"`) is absent from the reconciled set, and nothing prevents a retirement cascade when the last binding ends. ### D17 — The profile artifact re-imports the retired meaning and has no governance shape `profile-candidate.json` `"bases":["WM-ACT-001","WM-ACT-034","WM-KNW-011","WM-MAT-008","WM-ORG-002","WM-ORG-003","WM-ORG-004"]` while its first constraint reads `"WM-ACT-001 is narrowed … and never acts as the Business Capability master."` Under the fixed decision only WM-ACT-034 is profiled; listing WM-ACT-001 as a *base* of the capability-assessment profile conflates "profiled base" with "referenced model" and re-admits the retired enterprise-capability meaning into the profile's own derivation. The profile also carries no `allocationState`, no `canonicalPublishable`, no `holds`, no version, no fixtures and no validation policy — unlike both candidates. ### D18 — Validation policies are unbound and purely numeric `candidate-allocation-offline-business-capability/validation-policy.json` and `candidate-allocation-offline-capability-realization/validation-policy.json` are byte-identical and contain **no** `candidateName`, `contourId` or target. Neither policy is bound to the artifact it governs; either can be applied to either, or to the profile, silently. Both candidates pass on counts (12 invariants ≥ 8; 6 references ≥ 3; 6 fixtures ≥ 3) while every defect above survives validation. The policy requires no `expectedCode` and no mapping from declared invariants to fixtures. ### D19 — Fixture defects - `reorganization-survival` input: `"A capability moves from unit U1 to U2"` — under the fixed decision a capability does not move; a realization does. The input encodes the rejected ownership semantics, and contradicts the acceptance scenario where *process P* transfers. - `system-is-full-capability` and `process-redesign` are realization-side rules filed under the **BusinessCapability** fixture set, so the rules they exercise are attributed to the wrong artifact. - `system-support` expects `"coverage is evidence-based"` — no observable field outcome; untestable. - No fixture in either set carries an `expectedCode`, so no negative case can be shown to fail for the declared reason. - Uncovered declared invariants include: unknown-vs-zero on BusinessCapability; scenario leakage; edge supersession under re-decomposition; capacity misattachment; finalized-assessment immutability and non-recomputation against a later scale; required vs actual level authority; assessment not renaming a capability; retired capability resolvability; concurrent realizations. ### D20 — The WM-ACT-001 narrowing is unsafe as specified local-evidence: `"Narrow legacy WM-ACT-001 to agent-scoped Function, Competence, Proficiency and Capacity."` grok-study: `"Double-count risk remains until enterprise-capability usage is explicitly retired from WM-ACT-001."` The artifacts assert the retirement and supply no mechanism: no crosswalk, no detection rule for existing `capability` / `capabilityAttribution` instances that carried enterprise meaning, no write-freeze at an effective date, no default-to-unknown for unmapped rows, and no prohibition on auto-promoting an agent competence record into a BusinessCapability — which is precisely grok's second named failure mode (`"treating agent competence … as the enterprise capability, so identity moves with skilled people"`). The narrowing is also a breaking change to a published legacy model recorded with no version bump, deprecation note or migration-boundary record in these artifacts. ### D21 — Adjudicated invariants dropped without disposition The reconciled twelve-item list silently loses: grok 13 `"Assessment does not create or rename the capability"`; grok 15 `"Multiple realizations of one capability may coexist"`; grok 16 `"Ending a realization does not retire the capability"`; claude-study `"siblings are mutually exclusive at that tier"`; claude-study `"separate determiner from decision authority"`. Dropping adjudicated content with no accept/reject/defer record is a reconciliation defect independent of whether each rule is right. ### Treated as holds, not defects Registry non-allocation for both candidates; WM-ACT-001 and WM-ACT-003 being legacy `described-previous-version` under migration-boundary-review; WM-ACT-034 / WM-KNW-011 / WM-MAT-008 single-provider-waiver reviewable drafts; WM-ORG-002/003/004 unresolved boundary items; empty relation contracts and absent capability edges in the frozen relations list; absence of a published scale registry, semantic crosswalk and source-master confirmation; no canonical completeness, installability or publication-readiness claim. --- ## 3. Required bounded fixes 1. **D1** — Add to `BusinessCapability`: `outcomeClass` as `{schemeRef, code|governedTerm}`; a declared natural key `(outcomeClassRef, actedUponObjectRef)` with a uniqueness rule and a stated equivalence/deduplication procedure; `identityBasis` enum `masterKey|governedIri|surrogate` with surrogates explicitly marked. 2. **D2** — Choose one mechanism and state the boundary test: refinement of definition/applicability → new immutable version under unchanged `businessCapabilityId`; replacement of the outcome class → successor capability with new identifier. Add `versionId`, `effectiveFrom`, `effectiveTo`, `predecessorRef`. Rewrite the `new-outcome-class` expectation as a single deterministic outcome. 3. **D3** — Add a `CapabilityDecompositionEdge` object: `parentRef`, `childRef`, `tier`, `validFrom`, `validTo`, `supersedesRef`, `edgeVersionId`; declare the parent as edge master; restore sibling exclusivity (or record an explicit deferral with reason). 4. **D4** — Remove `"required realization and assessment references"` from BC `owns`; declare `CapabilityRealization.capabilityRef` the single authoritative direction; retarget the BC WM-ORG-002 reference purpose to register stewardship only; remove WM-ACT-003, WM-MAT-008 and WM-ACT-034 realization-side purposes from BC; state that BC `owns` register stewardship while CR `owns` operational accountability. 5. **D5** — Remove WM-ACT-001 from BC references; add it to CR references with purpose "agent competence and period capacity of an agent realizer"; declare a non-agent capacity referent or mark `capacityRef` admissible only for agent-kind realizers. 6. **D6** — State in the artifact that `accountablePartyRef` is **not** a realizer; retain one-realizer granularity explicitly; introduce a `CapabilityCoverageClaim` bearer (`capabilityRef`, `scopeRef`, `asOf`, `claimGrade`, `basis`) and move the fullness test onto it, evaluated over the binding set. 7. **D7** — Delete `"unless stronger governed evidence exists."` Make `evidenceRefs` structured: `{evidenceRef, digest, digestAlg, criterionRef}`. Add an evidence-sufficiency rule, or record its absence as a hold that blocks any fullness claim. 8. **D8** — Make `coverageShare` a structure `{value, basis, denominatorRef, periodFrom, periodTo}`, required whenever a share is asserted; add a same-denominator reconciliation rule for concurrent bindings; state that coverage is derived-only and may not be stored on BusinessCapability. 9. **D9** — Add a `CompletenessAssertion` object: `scopeRef`, `populationDefinition`, `asOf`, `asserterRef`, `method`, `validTo`; make it the only licence for reading absence as unrealized. 10. **D10** — Replace the four-state list with an orthogonal pair: `realizationState ∈ {unrealized, partial, realized, unknown}` × `maturityState ∈ {assessed(level), unassessed}`. 11. **D11** — Add required `assertionMode ∈ {actual, scenario}` on CapabilityRealization and `scenarioRef` when `scenario`; restrict `proposed` to a record-draft meaning; exclude `scenario` from authoritative projections by rule. 12. **D12** — Add to BC: `effectiveFrom`, `effectiveTo`, `assertedAt`, `asserterRef`, `sourceRef`. Add to CR: `assertedAt`, `supersedesRecordRef`, `asserterRef`; forbid in-place field mutation; corrections become new knowledge-time records. 13. **D13** — Make `successorRef` required on transfer; add `predecessorRef`; require `R1.validTo == R2.validFrom` or a declared `gapReason`; require `validTo` whenever status is terminal. 14. **D14** — Define `constrained` (entry, exit, projection effect) or remove it; make `deprecated`/`superseded`/`retired` disjoint with declared triggers; forbid `superseded` without `successorRef`; assign `transferred` to realizer change and `superseded` to record replacement, disjointly. 15. **D15** — Add a `CapabilityRequirement` object (`capabilityRef`, `requiredLevel`, `scaleRef`, `scaleVersion`, `driverRef` → WM-KNW-011, `horizon`, `authorityRef`); add `scaleRef` + `scaleVersion` to the assessment profile; keep the scale registry's publication as a hold. 16. **D16** — Add `tombstone` semantics and a no-hard-delete rule to both objects; add the explicit invariant that ending the last realization does not change capability status. 17. **D17** — Reduce `bases` to `["WM-ACT-034"]`; move the rest to a separate `referents` list with WM-ACT-001 appearing only as a CR referent; add `allocationState`, `canonicalPublishable`, `holds`, `profileVersion`, a fixtures file and a bound validation policy. 18. **D18** — Add `target`/`candidateName` + `contourId` to each validation policy; add `requiresExpectedCodeOnNegativeFixtures: true` and `requiresEveryInvariantMappedToFixture: true`; add a third policy for the profile. 19. **D19** — Rewrite `reorganization-survival` so the *realization* transfers; move `system-is-full-capability` and `process-redesign` to the CapabilityRealization set; restate `system-support` as a field-level expectation; add `expectedCode` throughout; add fixtures for every currently uncovered invariant. 20. **D20** — Add a migration section: narrowing effective date; write-freeze on enterprise-capability use of WM-ACT-001 from that date; a detection rule for dual-meaning legacy instances; an explicit prohibition on auto-promotion, with unmapped instances resolving to `unknown`; a deprecation/version note on the WM-ACT-001 boundary record. 21. **D21** — Add a disposition table for every adjudicated invariant from both studies with accept/reject/defer and a reason; reinstate the five dropped rules or record the rejections. --- ## 4. Additional fixtures ```json [ {"target":"BusinessCapability","id":"bc-duplicate-outcome-class","kind":"negative","input":"Two capability records carry identical outcomeClass and actedUponObject with different businessCapabilityId values.","expect":"Rejected as a duplicate identity; distinct surrogates do not create distinct capabilities.","expectedCode":"ERR_OUTCOME_CLASS_DUPLICATE"}, {"target":"BusinessCapability","id":"bc-outcome-class-ungoverned","kind":"negative","input":"outcomeClass is supplied as free text with no schemeRef and no governed term.","expect":"Rejected; outcomeClass requires schemeRef plus code or a governed term.","expectedCode":"ERR_OUTCOME_CLASS_UNGOVERNED"}, {"target":"BusinessCapability","id":"bc-surrogate-unmarked","kind":"negative","input":"A minted UUID is used as businessCapabilityId with no identityBasis value and no master-key resolution.","expect":"Rejected; surrogate identifiers must be marked and resolvable to the register master key.","expectedCode":"ERR_SURROGATE_UNMARKED"}, {"target":"BusinessCapability","id":"bc-outcome-refinement-creates-version","kind":"positive","input":"Definition and applicability are refined while the outcome class and acted-upon object are unchanged.","expect":"A new immutable versionId is created under the unchanged businessCapabilityId; no successor capability is minted.","expectedCode":"OK_VERSION_NOT_SUCCESSION"}, {"target":"BusinessCapability","id":"bc-outcome-class-replacement-mints-successor","kind":"positive","input":"The outcome class itself is replaced by a materially different outcome class.","expect":"A successor capability with a new businessCapabilityId is created; predecessorRef and successorRef are both set and the predecessor status becomes superseded.","expectedCode":"OK_SUCCESSION_NOT_VERSION"}, {"target":"BusinessCapability","id":"bc-change-disposition-disjunctive","kind":"negative","input":"A change is recorded with the disposition 'a successor or distinct capability is created with lineage'.","expect":"Rejected; the change mechanism must resolve to exactly one of version or succession.","expectedCode":"ERR_CHANGE_DISPOSITION_AMBIGUOUS"}, {"target":"BusinessCapability","id":"bc-tier-without-edge-object","kind":"negative","input":"A parent-child relation with tier label L2 is asserted with no decomposition-edge record carrying validity and supersession.","expect":"Rejected; parentage and tier are expressible only as versioned edge records.","expectedCode":"ERR_EDGE_OBJECT_MISSING"}, {"target":"BusinessCapability","id":"bc-sibling-outcome-overlap","kind":"negative","input":"Two sibling children under one parent at the same tier cover overlapping outcome classes with no declared justification.","expect":"Rejected; siblings are mutually exclusive at a tier unless the overlap is declared and justified.","expectedCode":"ERR_SIBLING_NOT_EXCLUSIVE"}, {"target":"BusinessCapability","id":"bc-redecomposition-supersedes-edges","kind":"positive","input":"Re-decomposition moves capability C from L2 under P1 to L3 under P2.","expect":"The prior edge is superseded with validTo set and a new edge opens; businessCapabilityId and versionId are unchanged.","expectedCode":"OK_EDGE_SUPERSESSION"}, {"target":"BusinessCapability","id":"bc-realization-reference-stored-on-capability","kind":"negative","input":"A realization binding reference is written onto the BusinessCapability record.","expect":"Rejected; CapabilityRealization.capabilityRef is the single authoritative direction.","expectedCode":"ERR_REALIZATION_DIRECTION"}, {"target":"BusinessCapability","id":"bc-org-reference-purpose-realizer","kind":"negative","input":"WM-ORG-002 is referenced from BusinessCapability with purpose 'organizational-unit realizer'.","expect":"Rejected; BusinessCapability may reference WM-ORG-002 only for register stewardship.","expectedCode":"ERR_REFERENCE_PURPOSE_OUT_OF_BOUNDARY"}, {"target":"BusinessCapability","id":"bc-stored-coverage-value","kind":"negative","input":"A computed coverage percentage is persisted on the BusinessCapability record.","expect":"Rejected; coverage is a derived as-of projection and is never stored on the capability.","expectedCode":"ERR_DERIVED_VALUE_STORED"}, {"target":"BusinessCapability","id":"bc-references-agent-competence","kind":"negative","input":"BusinessCapability declares a reference to WM-ACT-001.","expect":"Rejected; agent competence and capacity attach to CapabilityRealization, not to the capability.","expectedCode":"ERR_AGENT_COMPETENCE_COUPLING"}, {"target":"CapabilityRealization","id":"cr-agent-competence-referent","kind":"positive","input":"A realization names a WM-ORG-004 position realizer whose required competence and period capacity are held in WM-ACT-001.","expect":"Accepted; WM-ACT-001 is a declared CapabilityRealization referent for agent competence and capacity.","expectedCode":"OK_COMPETENCE_ON_REALIZATION"}, {"target":"CapabilityRealization","id":"cr-nonagent-capacity-referent-mismatch","kind":"negative","input":"capacityRef on a system-kind realizer points at a WM-ACT-001 capacityStatement.","expect":"Rejected; agent capacity cannot carry non-agent realizer capacity and no non-agent capacity referent is declared.","expectedCode":"ERR_CAPACITY_REFERENT_MISMATCH"}, {"target":"CapabilityRealization","id":"cr-accountability-does-not-satisfy-fullness","kind":"negative","input":"A system-kind realizer binding supplies the required accountablePartyRef naming unit U1 and the binding is labelled full realization.","expect":"Rejected; accountablePartyRef is not a realizer and cannot satisfy the non-system realizer test.","expectedCode":"ERR_FULLNESS_VACUOUS_ACCOUNTABILITY"}, {"target":"CapabilityRealization","id":"cr-realizer-and-accountable-disjoint","kind":"positive","input":"R1 binds process P as the single realizer with unit U1 as accountable party.","expect":"Accepted; the one-realizer rule holds because accountablePartyRef is declared not to be a realizer.","expectedCode":"OK_PARTICIPANT_ROLE_DISJOINT"}, {"target":"CapabilityRealization","id":"cr-multi-participant-binding","kind":"negative","input":"One realization record enumerates a process, a team and a system as co-realizers.","expect":"Rejected under the declared one-realizer granularity; separate bindings are required.","expectedCode":"ERR_GRANULARITY_VIOLATION"}, {"target":"CapabilityRealization","id":"cr-fullness-claim-without-bearer","kind":"negative","input":"Full realization is asserted with no coverage-claim record naming capability, scope and as-of date.","expect":"Rejected; fullness is a claim over the binding set and requires its own bearer record.","expectedCode":"ERR_FULLNESS_NO_BEARER"}, {"target":"CapabilityRealization","id":"cr-system-only-stronger-evidence-escape","kind":"negative","input":"A system-only binding claims full realization by invoking 'stronger governed evidence'.","expect":"Rejected; the escape clause is removed and no evidence grade promotes a system-only binding.","expectedCode":"ERR_NONSYSTEM_REALIZER_REQUIRED"}, {"target":"CapabilityRealization","id":"cr-evidence-without-digest","kind":"negative","input":"evidenceRefs are supplied as bare references with no digest and no criterion linkage.","expect":"Rejected; evidence requires digest, digest algorithm and criterion linkage.","expectedCode":"ERR_EVIDENCE_UNPINNED"}, {"target":"CapabilityRealization","id":"cr-coverage-share-without-denominator","kind":"negative","input":"coverageShare 0.4 is recorded with a basis string but no denominatorRef and no measurement period.","expect":"Rejected; a share requires value, basis, denominator and effective period.","expectedCode":"ERR_COVERAGE_DENOMINATOR_MISSING"}, {"target":"CapabilityRealization","id":"cr-concurrent-shares-unreconciled","kind":"negative","input":"Three concurrent bindings for one capability declare shares of 0.7, 0.6 and 0.3 against the same denominator.","expect":"Rejected; concurrent shares on one denominator must reconcile or carry a declared overlap justification.","expectedCode":"ERR_COVERAGE_SUM_UNRECONCILED"}, {"target":"CapabilityRealization","id":"cr-missing-binding-read-as-zero","kind":"negative","input":"A capability with no realization rows is reported as zero coverage.","expect":"Rejected; the state is unknown absent a scoped completeness assertion.","expectedCode":"ERR_UNKNOWN_READ_AS_ZERO"}, {"target":"CapabilityRealization","id":"cr-completeness-assertion-licenses-unrealized","kind":"positive","input":"A completeness assertion naming population, scope, as-of date, asserter and method covers the capability's realizer population.","expect":"Accepted; within that scope and as-of date absence of bindings reads as unrealized rather than unknown.","expectedCode":"OK_COMPLETENESS_SCOPED"}, {"target":"EM-STR-03-profile","id":"profile-coverage-states-omit-unknown","kind":"negative","input":"A coverage projection emits only unrealized, partially realized, realized-but-low-maturity and unassessed.","expect":"Rejected; an explicit unknown state is required by the missingness invariant.","expectedCode":"ERR_COVERAGE_STATE_NO_UNKNOWN"}, {"target":"EM-STR-03-profile","id":"profile-realization-maturity-conflated","kind":"negative","input":"'realized-but-low-maturity' is emitted as a single coverage state value.","expect":"Rejected; realization state and maturity state are reported as an orthogonal pair.","expectedCode":"ERR_DIMENSION_CONFLATION"}, {"target":"CapabilityRealization","id":"cr-scenario-binding-unmarked","kind":"negative","input":"A target-state binding is recorded with status proposed and no assertionMode.","expect":"Rejected; assertionMode actual or scenario is required and proposed is a record-draft state only.","expectedCode":"ERR_SCENARIO_MODE_MISSING"}, {"target":"CapabilityRealization","id":"cr-scenario-feeds-authoritative-coverage","kind":"negative","input":"A binding with assertionMode scenario is included in an authoritative as-of coverage projection.","expect":"Rejected; scenario bindings never feed authoritative actuals.","expectedCode":"ERR_SCENARIO_IN_ACTUALS"}, {"target":"BusinessCapability","id":"bc-no-temporal-or-provenance-fields","kind":"negative","input":"A capability record is created with no effective interval, no assertedAt and no asserterRef.","expect":"Rejected; register effective interval, knowledge time and asserter are required.","expectedCode":"ERR_TEMPORAL_FIELDS_MISSING"}, {"target":"CapabilityRealization","id":"cr-in-place-correction","kind":"negative","input":"An accountability recording error is fixed by editing accountablePartyRef on the existing R1 record.","expect":"Rejected; corrections are new knowledge-time records so that correction stays distinguishable from real-world change.","expectedCode":"ERR_IN_PLACE_MUTATION"}, {"target":"CapabilityRealization","id":"cr-succession-chain-broken","kind":"negative","input":"R1.validTo is t1, R2.validFrom is t2 later than t1, successorRef is unset and R1.status remains active.","expect":"Rejected; transfer requires successorRef, a terminal R1 status and either contiguity or a declared gap reason.","expectedCode":"ERR_SUCCESSION_CHAIN_BROKEN"}, {"target":"CapabilityRealization","id":"cr-ended-without-valid-to","kind":"negative","input":"status is ended while validTo is absent.","expect":"Rejected; terminal states require validTo.","expectedCode":"ERR_END_WITHOUT_VALIDTO"}, {"target":"CapabilityRealization","id":"cr-transferred-superseded-overlap","kind":"negative","input":"A realizer transfer is recorded with status superseded while a record correction is recorded with status transferred.","expect":"Rejected; transferred and superseded are disjoint states with declared triggers.","expectedCode":"ERR_LIFECYCLE_STATE_OVERLAP"}, {"target":"BusinessCapability","id":"bc-superseded-without-successor","kind":"negative","input":"status is set to superseded while successorRef is absent.","expect":"Rejected; supersession requires a resolvable successor.","expectedCode":"ERR_SUPERSEDED_WITHOUT_SUCCESSOR"}, {"target":"BusinessCapability","id":"bc-constrained-state-undefined","kind":"negative","input":"status is set to constrained with no entry condition, exit condition or declared effect on coverage projection.","expect":"Rejected; lifecycle states without defined semantics are not assignable.","expectedCode":"ERR_LIFECYCLE_STATE_UNDEFINED"}, {"target":"EM-STR-03-profile","id":"profile-required-level-on-capability","kind":"negative","input":"A required level is written directly onto the BusinessCapability record.","expect":"Rejected; required level belongs to a capability-requirement record with driverRef, horizon and pinned scaleRef.","expectedCode":"ERR_REQUIRED_LEVEL_NO_BEARER"}, {"target":"EM-STR-03-profile","id":"profile-assessment-without-scale-pin","kind":"negative","input":"A finalized assessment states an actual level with no scaleRef and no scale version.","expect":"Rejected; scale and scale version are pinned before results.","expectedCode":"ERR_SCALE_PIN_MISSING"}, {"target":"EM-STR-03-profile","id":"profile-finalized-recomputed","kind":"negative","input":"A finalized assessment is recomputed against a later scale version.","expect":"Rejected; finalized assessments change only by amendment or supersession.","expectedCode":"ERR_FINALIZED_RECOMPUTE"}, {"target":"EM-STR-03-profile","id":"profile-assessment-renames-capability","kind":"negative","input":"A finalized assessment changes the capability's outcomeClass or name.","expect":"Rejected; assessment does not create, rename or redefine a capability.","expectedCode":"ERR_ASSESSMENT_MUTATES_IDENTITY"}, {"target":"BusinessCapability","id":"bc-retired-hard-deleted","kind":"negative","input":"A retired capability is hard-deleted while historical realizations and assessments reference it.","expect":"Rejected; a tombstone is retained and historical references remain resolvable.","expectedCode":"ERR_TOMBSTONE_REQUIRED"}, {"target":"BusinessCapability","id":"bc-retirement-cascade-from-realization","kind":"negative","input":"The last active realization ends and the capability is automatically set to retired.","expect":"Rejected; ending a realization does not change capability status.","expectedCode":"ERR_RETIREMENT_CASCADE"}, {"target":"CapabilityRealization","id":"cr-concurrent-realizations-coexist","kind":"positive","input":"Two realizations of one capability are concurrently active with distinct realizers and declared shares on a common denominator.","expect":"Accepted; multiple concurrent realizations of one capability are valid.","expectedCode":"OK_CONCURRENT_REALIZATIONS"}, {"target":"EM-STR-03-profile","id":"profile-act-001-declared-as-base","kind":"negative","input":"WM-ACT-001 is listed in the profile bases array.","expect":"Rejected; only WM-ACT-034 is profiled and WM-ACT-001 appears solely as a CapabilityRealization referent.","expectedCode":"ERR_PROFILE_BASE_REIMPORT"}, {"target":"EM-STR-03-profile","id":"profile-missing-governance-shape","kind":"negative","input":"The profile artifact declares no allocationState, canonicalPublishable, holds, profileVersion or fixtures.","expect":"Rejected; profile artifacts carry the same governance shape as allocation candidates.","expectedCode":"ERR_PROFILE_GOVERNANCE_SHAPE"}, {"target":"EM-STR-03-profile","id":"profile-validation-policy-unbound","kind":"negative","input":"A validation policy containing no candidateName, contourId or target is applied to an artifact.","expect":"Rejected; each validation policy binds to exactly one named target artifact.","expectedCode":"ERR_POLICY_UNBOUND"}, {"target":"EM-STR-03-profile","id":"profile-policy-numeric-only","kind":"negative","input":"A candidate passes validation on counts alone while declared invariants are unmapped to fixtures and negative fixtures carry no expectedCode.","expect":"Rejected; every declared invariant maps to at least one fixture and every negative fixture carries expectedCode.","expectedCode":"ERR_INVARIANT_FIXTURE_COVERAGE"}, {"target":"BusinessCapability","id":"bc-fixture-says-capability-moves","kind":"negative","input":"A fixture input states that a capability moves from unit U1 to unit U2.","expect":"Rejected; capabilities do not move between units and the case must be restated as a realization transfer.","expectedCode":"ERR_FIXTURE_ENCODES_REJECTED_SEMANTICS"}, {"target":"CapabilityRealization","id":"cr-fixture-filed-against-wrong-target","kind":"negative","input":"A system-alone-full-realization case is filed in the BusinessCapability fixture set.","expect":"Rejected; realization-side rules are exercised against CapabilityRealization.","expectedCode":"ERR_FIXTURE_TARGET_MISMATCH"}, {"target":"CapabilityRealization","id":"cr-fixture-expectation-unobservable","kind":"negative","input":"A fixture expectation reads only 'coverage is evidence-based'.","expect":"Rejected; expectations must name observable field-level outcomes.","expectedCode":"ERR_EXPECTATION_UNOBSERVABLE"}, {"target":"EM-STR-03-profile","id":"profile-legacy-row-auto-promoted","kind":"negative","input":"A legacy WM-ACT-001 instance whose capability and capabilityAttribution carried enterprise meaning is auto-promoted into a BusinessCapability record.","expect":"Rejected; promotion requires an approved crosswalk and unmapped legacy instances resolve to unknown.","expectedCode":"ERR_UNSAFE_AUTO_MIGRATION"}, {"target":"EM-STR-03-profile","id":"profile-enterprise-use-not-frozen","kind":"negative","input":"A new enterprise-capability instance is written against narrowed WM-ACT-001 after the narrowing effective date.","expect":"Rejected; enterprise-capability use of WM-ACT-001 is write-frozen from the narrowing effective date.","expectedCode":"ERR_RETIRED_MEANING_STILL_WRITABLE"}, {"target":"EM-STR-03-profile","id":"profile-narrowing-unversioned","kind":"negative","input":"WM-ACT-001 is narrowed with no version bump, deprecation note or migration-boundary record.","expect":"Rejected; a breaking narrowing of a published legacy model carries an explicit versioned boundary record.","expectedCode":"ERR_BREAKING_CHANGE_UNVERSIONED"}, {"target":"EM-STR-03-profile","id":"profile-adjudicated-invariants-dropped","kind":"negative","input":"The reconciled invariant set omits adjudicated rules on assessment not renaming a capability, concurrent realizations, ending a realization not retiring a capability, sibling exclusivity, and determiner separate from decision authority, with no disposition recorded.","expect":"Rejected; every adjudicated invariant carries an accept, reject or defer disposition with a stated reason.","expectedCode":"ERR_ADJUDICATION_DROPPED"}, {"target":"EM-STR-03-profile","id":"profile-assessor-determiner-not-separated","kind":"negative","input":"One party records both the determination and the decision authority on a finalized assessment with no impartiality record.","expect":"Rejected; determiner and decision authority are separated and assessor competence and impartiality are recorded.","expectedCode":"ERR_DETERMINER_AUTHORITY_FUSED"} ] ``` --- ## 5. Identifier decision No identifier is allocated, minted, guessed or reserved by this audit. - **Business Capability** — remains `modelId: null`, `registryId: null`, `allocationState: "unassigned"`, `canonicalPublishable: false`. Independent identity is confirmed; allocation stays with the registry authority. - **Capability Realization** — remains `modelId: null`, `registryId: null`, `allocationState: "unassigned"`, `canonicalPublishable: false`. Independent identity is confirmed on temporal-evidenced-binding grounds; no identifier allocated. - **WM-ACT-001** — retains its existing identifier with scope narrowed to agent Function, Competence, Proficiency and Capacity. No re-identification, no reuse as Business Capability master. Enterprise-capability meaning is retired, subject to the migration mechanism required under D20. - **WM-ACT-034** — profiled for Capability Assessment. No new root, no new runtime identifier. - **Capability Level** — no identifier. It remains a versioned scale definition or a level assertion inside a requirement or assessment. - **Capability Decomposition Edge, Capability Requirement, Completeness Assertion, Capability Coverage Claim** — introduced by the required fixes as contained or candidate structures only; no identifiers allocated and none implied. - No catalogue, runtime or crosswalk identifier is allocated. No claim of canonical completeness, installability or publication readiness is made. --- ## 6. Freeze decision **Closed. No rerun.** This audit executed once, offline, with no tools, browsing, standards claims, identifier invention or registry mutation. The verdict is REVISE; defects D1–D21, the bounded fixes and the fixture array above constitute the complete and final output of the frozen audit for EM-STR-03. Any further review is a new, separately governed activity, not a repetition of this one.