# EM-OPS-03 — Final Frozen Semantic Audit

Single audit. No tools used, nothing browsed, no identifier invented, no rerun requested. Admitted evidence: the initial Claude study, the local synthesis, the exact visible Grok response (text only; its hidden reasoning, team coordination and sources control are excluded and carry no evidentiary weight), and the ten appended candidate artifacts.

---

## 1. Verdict

**Decision (the settled boundary): ACCEPT, as stated, in full.** Every clause listed in the audit brief survives the three admitted inputs:

- Asset Instance profiling WM-OBJ-001 with no parallel physical identity is the only reading consistent with WM-OBJ-001's stated mastership of instance identifiers, marks, condition, whereabouts, custody and lifecycle. Both Claude and Grok converge here.
- Custody as an **effective-dated, independently identified relationship record inside the WM-OBJ-001 boundary, allocating no model or runtime identifier**, is the correct resolution of the one genuine disagreement in the record. Grok's objection ("Custody profiles nothing in WM-OBJ-001… requires an independent temporal relationship identity") is sound on *record identity* — a holder/interval/basis triple cannot be a property of the item — and wrong on *allocation*: nothing in the admitted evidence shows WM-OBJ-001 refusing to govern custody periods, and it expressly lists custody period, transfer, basis of holding and acknowledgement among its owned concerns. Independent record identity inside an existing boundary is not a new master. The settled clause states exactly this and is upheld.
- WM-ECO-011 as aligned holding view only is forced: the dossier holds no current spec and no crosswalk, and its legacy content is person-side. WM-OBJ-022 as projection only is stated by WM-OBJ-022 itself ("no second master identity").
- WM-ACT-007 authorizing without proving execution is self-declared in that spec and independently affirmed by Grok's counterexample.
- Maintenance Plan / Maintenance Event / Calibration Event as independent identifier-unassigned roots passes the identity test on all three: each has stable identity, version identity and a lifecycle that no frozen base supplies.
- Reuse of the EM-LND-17 responsibility candidate rather than a second candidate is correct and prevents a duplicate relation root.
- WM-OBJ-023 as reserved boundary and completion dependency — not an EM-OPS-03 allocation — is correct; Grok's contrary demand that it "requires an independent configuration identity, as a specialization" would allocate inside a reserved boundary on an unverified parent (WM-OBJ-008 is named but never supplied) and is rejected.
- The pinned identity-continuity rule, the prohibition on calibration transfer, the calibration content set, purpose-scoped derived fitness, and the refusal of class/model propagation are all upheld. The negative case stays rejected.
- No runtime or model identifier is allocated by this audit.

**Verdict (the artifacts): CONDITIONAL ACCEPT — NOT PUBLICATION-READY.** The ten artifacts are structurally sound candidate material and correctly carry `modelId: null`, `registryId: null`, `allocationState: "unassigned"`, `canonicalPublishable: false` on the three roots. They do **not** yet encode the settled boundary: Custody has no artifact at all, three reference identifiers appear in the Calibration Event candidate that exist nowhere in admitted evidence, the WM-OBJ-023 completion dependency is undeclared everywhere, several owned concepts have no fields, the calibration lifecycle contradicts its own separability invariant, and the fixture set is both schema-nonconformant and silent on seven settled clauses. Twenty material defects follow with exact remediation. No publication readiness, no canonical completeness and no installability is claimed or implied.

---

## 2. Material defects and exact deterministic remediation

**D01 — Custody has no artifact.** The settled boundary's central clause is unrepresented in all ten files; `profile-candidate.json` says only "Asset identity and custody remain WM-OBJ-001-owned", which asserts the boundary and omits the record.
*Remediation:* add to `profile-candidate.json` the key `"profiledRelations"` with member `"Custody"` exactly as:
`{"identityScope":"record-within-WM-OBJ-001","identity":["custodyRecordId"],"allocatesModelId":false,"allocatesRuntimeId":false,"required":["assetRef","holderRef","basisOfHolding","validFrom"],"optional":["validTo","acknowledgementRef","conditionAtHandoverRef","supersedesRef"],"invariants":["Custody is an effective-dated relationship record independently identified within the WM-OBJ-001 boundary and allocates no model or runtime identifier.","At most one custody record per asset instance has no validTo.","Custody implies neither title, operational responsibility, location nor access.","A location or access change does not imply a custody change.","Custody transfer closes the prior record and opens a successor; neither record is overwritten."]}`

**D02 — The Custody disagreement is unrecorded.** The record contains an unresolved Claude/Grok conflict on Custody mastership; no artifact states which reading governs, so an implementer may re-open it and allocate a fourth root.
*Remediation:* add to `profile-candidate.json` the key `"resolvedDisagreements"` containing exactly:
`[{"topic":"Custody mastership","claudePosition":"Custody is a profile of WM-OBJ-001.","grokPosition":"Custody requires an independent temporal relationship identity and must not be profiled onto WM-OBJ-001.","resolution":"Custody is an independently identified, effective-dated relationship record within the WM-OBJ-001 boundary. Record identity is granted; model and runtime identifier allocation is refused.","authority":"EM-OPS-03 frozen semantic audit, 2026-10-01"}]`

**D03 — Unverified reference identifiers in the Calibration Event candidate.** `WM-KNW-013`, `WM-REC-010` and `WM-REC-001` appear in no admitted input. They are unverifiable under this audit's evidence limit and must not stand as targets.
*Remediation:* in `candidate-allocation-offline-calibration-event/allocation-candidate.json`, delete those three reference entries and replace them with role-bearing unresolved slots, exactly:
`{"target":null,"role":"pinned-method-source","state":"unresolved"}`, `{"target":null,"role":"conformity-decision-record","state":"unresolved"}`, `{"target":null,"role":"certificate-artifact-record","state":"unresolved"}`; then add `{"target":"WM-OBJ-023","purpose":"Measuring-instrument/configuration boundary (reserved; completion dependency)"}` and `{"target":"WM-ACT-034","purpose":"Condition judgement"}`. Verified references then number four, satisfying `minimumReferences: 3` without unverified targets.

**D04 — WM-OBJ-023 completion dependency undeclared.** `CalibrationEvent.required` includes `configurationRef` while no artifact names the boundary that resolves it. An implementer closing the gap would allocate a configuration master inside a reserved boundary.
*Remediation:* add `"completionDependencies":["WM-OBJ-023"]` to all three `allocation-candidate.json` files and to `profile-candidate.json`, and append to each `holds` array the exact string: `"WM-OBJ-023 is the reserved measuring-instrument/configuration boundary, is a completion dependency of EM-OPS-03, and receives no allocation here."`

**D05 — Calibration Event owns concepts it has no fields for.** `boundary.owns` lists range and calibration points, traceability, decision rule and validity/invalidation conditions; `objects.CalibrationEvent` carries none of them, and `decisionRef`/`validUntil` are optional. The invariants "Range and calibration points are explicit", "Uncertainty accompanies interpreted results" and "Broken traceability invalidates dependent fitness" are therefore unenforceable.
*Remediation:* replace `objects.CalibrationEvent.required` with exactly `["instrumentRef","configurationRef","methodRef","methodVersion","referenceStandardRefs","traceabilityChain","calibratedRange","calibrationPoints","performedAt","results","resultUnitSystem","uncertainty","validityConditions"]` and `optional` with exactly `["decisionRule","conformityStatement","certificateRef","validFrom","validUntil","supersedesRef","impartialityDeclarationRef","competenceRef"]`; add the conditional rule `"conditionalRequirements":[{"when":"conformityStatement present","require":["decisionRule","uncertainty.coverageFactor","uncertainty.coverageProbability"]}]`.

**D06 — The calibration lifecycle contradicts its own separability invariant.** `independentLifecycle` is one linear axis mixing determination (`recorded`,`evaluated`), decision (`conforming`,`nonconforming`), attestation (`attested`) and validity (`expired`,`invalidated`), while invariant 5 requires determination, decision and attestation to remain separable.
*Remediation:* delete `independentLifecycle` from the Calibration Event candidate and replace with exactly:
`"independentLifecycleAxes":{"determinationState":["recorded","evaluated","corrected","superseded"],"decisionState":["not-evaluated","conforming","nonconforming","indeterminate"],"attestationState":["not-attested","attested","reissued","withdrawn"],"validityState":["not-asserted","valid","expired","invalidated"]}`; add the invariant `"The four lifecycle axes advance independently and no single state may encode determination, decision, attestation and validity together."`

**D07 — The pinned continuity rule has no field.** `Maintenance Event` invariants require asset continuity to follow a pinned local rule and forbid silent calibration transfer, but `objects.MaintenanceEvent` has no rule reference, so the existing negative fixtures `silent-continuity` and `copied-calibration` are not deterministically decidable.
*Remediation:* add `continuityRuleRef` and `continuityRuleVersion` to `optional`, plus `"conditionalRequirements":[{"when":"componentChanges present","require":["continuityRuleRef","continuityRuleVersion"]},{"when":"componentChanges affects a measuring subsystem","require":["calibrationInvalidationRef"]}]`; add the invariant `"A component change that affects a measuring subsystem invalidates dependent fitness and never carries a calibration event, certificate or validity to the successor configuration."`

**D08 — Order/event cardinality unstated.** Grok's invariants 8 and the separation of authorization from execution require at most one authorizing order per event and permit an order with zero events; `workOrderRef` is an unconstrained optional field.
*Remediation:* add `"cardinality":{"workOrderRef":{"min":0,"max":1}}` to `objects.MaintenanceEvent` and the invariants `"A maintenance event cites at most one authorizing work order."` and `"An authorizing work order may cite zero maintenance events, including after closure."`

**D09 — No non-substitution rule for evidence or certificate.** The artifacts state that measurements remain WM-MAT-008 facts and judgements remain WM-ACT-034 assessments, but never forbid them from *being* the event; the Calibration Event candidate omits the rule entirely and does not forbid the certificate standing in for the event. This is Grok's open blocker and it is confirmed.
*Remediation:* append to the invariants of both the Maintenance Event and Calibration Event candidates the exact string `"WM-MAT-008 observations and WM-ACT-034 assessments may be cited as evidence and never constitute event identity."`, and to the Calibration Event candidate only `"A certificate is the immutable artifact of exactly one calibration event and never substitutes for the event."`

**D10 — Membership invariant depends on an undeclared master.** "Component replacement closes and opens membership explicitly" requires the as-built structure master named in the admitted study (WM-OBJ-012), which appears in no reference list.
*Remediation:* add `{"target":"WM-OBJ-012","purpose":"As-built component membership episodes"}` to `candidate-allocation-offline-maintenance-event/allocation-candidate.json` references.

**D11 — Profile misclassifies its own inputs.** `bases` flattens WM-ECO-011 (aligned view only) and WM-OBJ-022 (projection only) into constraint-bearing bases, omits WM-OBJ-023, WM-BLT-002, WM-OBJ-002, WM-OBJ-012 and WM-OBJ-017, and the constraint list never states projection-only, no-allocation or non-propagation.
*Remediation:* in `profile-candidate.json` set `"bases":["WM-OBJ-001","WM-ACT-007","WM-MAT-008","WM-ACT-034"]`, and add `"alignedViews":["WM-ECO-011"]`, `"projections":["WM-OBJ-022"]`, `"referencedMasters":["WM-BLT-002","WM-OBJ-002","WM-OBJ-012","WM-OBJ-017"]`; append the constraints exactly: `"WM-ECO-011 is an aligned holding view and never masters custody, operational responsibility, location, access or fitness."`, `"WM-OBJ-022 is a projection and never masters identity, calibration validity or fitness."`, `"Title holder, custodian, operationally responsible party, location assignment and access assignment may differ simultaneously and a change to one does not rewrite the others."`, `"EM-OPS-03 allocates no model identifier and no runtime identifier."`, `"Calibration and fitness never propagate by instrument class or model."`

**D12 — Profile carries no publication hold.** The three roots declare `canonicalPublishable: false` and a `holds` array; the profile declares neither, so it reads as releasable.
*Remediation:* add `"canonicalPublishable": false` and `"holds":["Registry allocation is pending and no identifier may be guessed.","One frozen semantic audit is complete; base specifications and approved relations remain incomplete.","WM-ECO-011 lacks a current specification and semantic crosswalk; enterprise title mastership is unresolved.","The WM-ACT-007 / WM-ACT-013 K11 specification duplication is unresolved.","WM-OBJ-023 is a completion dependency and receives no allocation here.","Package conversion and live verification are pending."]` to `profile-candidate.json`.

**D13 — EM-LND-17 reuse is declared without state or exclusivity.** A one-line constraint does not prevent EM-OPS-03 from raising a second responsibility root, and records no allocation state for the reused candidate.
*Remediation:* add to `profile-candidate.json`:
`"reusedCandidates":[{"name":"Operational Responsibility Assignment","sourceContourId":"EM-LND-17","modelId":null,"registryId":null,"allocationState":"unassigned","required":["partyRef","assetScopeRef","governingBasis","validFrom"],"optional":["validTo"],"rule":"EM-OPS-03 raises no second operational-responsibility candidate and allocates no identifier for the reused one."}]`

**D14 — The 18 prior fixtures are schema-nonconformant.** Every prior case carries only `id`, `kind`, `input`, `expect`; all 18 lack `target`, `violates` and `closesDefect`, and all 9 negatives lack `expectedCode`. Expectations such as "The inference is rejected." are not deterministically checkable.
*Remediation:* re-emit all three fixture files under `"format":"vercy-enterprise-allocation-fixtures/v2"` with no case added or removed, applying this exact mapping: `target` := that file's `candidateName`; `violates` := the verbatim invariant string from the corresponding `allocation-candidate.json` that the case exercises; `closesDefect` := `"D17"` for every prior case; `expectedCode` on negatives := `order-proof` → `EM_OPS_03_PLAN_PROVES_AUTHORIZATION`, `execution-proof` → `EM_OPS_03_PLAN_PROVES_EXECUTION`, `mutable-version` → `EM_OPS_03_PLAN_VERSION_MUTATED`, `closed-order` → `EM_OPS_03_ORDER_PROVES_EXECUTION`, `silent-continuity` → `EM_OPS_03_CONTINUITY_RULE_UNPINNED`, `copied-calibration` → `EM_OPS_03_CALIBRATION_TRANSFERRED_ON_REPLACEMENT`, `model-inheritance` → `EM_OPS_03_CALIBRATION_CLASS_PROPAGATION`, `timeless-fitness` → `EM_OPS_03_FITNESS_STORED_AS_PROPERTY`, `missing-uncertainty` → `EM_OPS_03_CALIBRATION_UNCERTAINTY_MISSING`. Prior counts do not change.

**D15 — No error-code registry exists.** `expectedCode` values cannot be validated against anything.
*Remediation:* add `candidate-allocation-offline-shared/codes.json` as `{"format":"vercy-allocation-error-codes/v1","contourId":"EM-OPS-03","codes":[…]}` whose `codes` array is exactly the set of distinct `expectedCode` values used in section 3 plus the nine mapped in D14 — 40 codes in total, each with the field `"severity":"reject"`. No code outside that file may be used.

**D16 — Validation policies under-constrain.** The three identical `validation-policy.json` files enforce null identifiers and fixture minima but do not enforce the fixture field set, do not forbid unverified reference targets, do not require `completionDependencies` or `holds`, and no policy file exists for the profile candidate.
*Remediation:* add to each existing policy the exact keys `"requiresFixtureFields":["id","target","kind","input","expect","violates","closesDefect"]`, `"requiresExpectedCodeOnNegative":true`, `"forbidsUnverifiedReferenceTargets":true`, `"requiresCompletionDependencies":true`, `"requiresHolds":true`, `"requiresCanonicalPublishableFalse":true`, `"errorCodeRegistry":"candidate-allocation-offline-shared/codes.json"`; and add `candidate-allocation-offline-profile/validation-policy.json` as `{"format":"vercy-allocation-validation/v1","requirements":{"newRuntimeIdMustBeFalse":true,"requiresCanonicalPublishableFalse":true,"requiresProfiledRelations":true,"requiresResolvedDisagreements":true,"requiresReusedCandidates":true,"requiresAlignedViewsSeparateFromBases":true,"requiresProjectionsSeparateFromBases":true,"requiresCompletionDependencies":true,"requiresHolds":true,"minimumConstraints":10,"minimumFixtures":3,"requiresPositiveAndNegativeFixtures":true}}`.

**D17 — Seven settled clauses have zero fixture coverage.** No fixture anywhere exercises: custody record semantics and the single-open-period rule; the five-way distinctness of title/custody/responsibility/location/access; WM-ECO-011 view-only; WM-OBJ-022 projection-only; WM-OBJ-023 as completion dependency rather than allocation; the no-identifier-allocation requirement; or purpose-scoped derived fitness.
*Remediation:* adopt the 46 additional fixtures in section 3 verbatim, unmodified and in the given order.

**D18 — Derived fitness has no owner.** Both the local synthesis and Grok's minimum model set name a derived fitness assertion, and the Calibration Event invariants depend on it ("Fitness is derived for a stated use"), yet no artifact declares its shape — leaving a stored boolean the path of least resistance.
*Remediation:* add to `profile-candidate.json` the key `"derivedAssertions"` containing exactly:
`{"FitnessAssertion":{"derived":true,"stored":false,"allocatesModelId":false,"allocatesRuntimeId":false,"required":["instrumentRef","configurationRef","statedPurpose","evaluatedAt","inputs","result"],"optional":["decisionRule","supersededAssertionRef"],"invariants":["A fitness assertion is derived at evaluation time for a stated purpose and is never stored as a property of the instrument, model or economic view.","A fitness assertion is scoped to one instrument configuration and never extends to another serial of the same model.","Validity expiry, configuration change or purpose change drops the current assertion and leaves all prior assertions and certificates intact."]}}`

**D19 — Plan applicability can leak into coverage.** `PlanVersion.applicability` is an untyped field, and the plan invariant "Calibration requirements never imply calibration success" does not stop model-scoped applicability from being read as instance-level calibration coverage.
*Remediation:* in the Maintenance Plan candidate, replace `applicability` with `"applicability":{"required":["scopeKind","scopeExpression"],"scopeKind":["instance","type","variant","configuration","location"],"resolution":"explicit-instance-resolution-required"}`, and append the invariant `"Plan applicability at type, variant or configuration scope never establishes instance-level calibration, fitness or coverage."`

**D20 — Append-only is contradicted by the event lifecycle.** `MaintenanceEvent.independentLifecycle` contains `voided` and `superseded` alongside the invariant "Corrections append and never erase original evidence", with no rule that voiding preserves the original.
*Remediation:* append to the Maintenance Event invariants the exact string `"Voiding, supersession and correction are appended states that preserve the original record, its evidence bindings and its performed interval."`

---

## 3. Additional fixtures

```json
[
  {"id":"A-CUST-01","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"A custody record is opened for one asset instance with holderRef, basisOfHolding and validFrom while title remains with the lessor.","expect":"The record is valid, is independently identified within the WM-OBJ-001 boundary, and allocates no model or runtime identifier.","violates":"Custody is an effective-dated relationship record independently identified within the WM-OBJ-001 boundary and allocates no model or runtime identifier.","closesDefect":"D01"},
  {"id":"A-CUST-02","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A second custody record is opened for the same asset instance while the prior record still has no validTo.","expect":"The second open record is rejected.","violates":"At most one custody record per asset instance has no validTo.","closesDefect":"D01","expectedCode":"EM_OPS_03_CUSTODY_MULTIPLE_OPEN_PERIODS"},
  {"id":"A-CUST-03","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"The current custodian is reported as the title holder because no other holding is recorded.","expect":"The inference is rejected.","violates":"Custody implies neither title, operational responsibility, location nor access.","closesDefect":"D01","expectedCode":"EM_OPS_03_CUSTODY_IMPLIES_TITLE"},
  {"id":"A-CUST-04","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"The current custodian is treated as the operationally responsible party without a responsibility assignment.","expect":"The inference is rejected.","violates":"Custody implies neither title, operational responsibility, location nor access.","closesDefect":"D01","expectedCode":"EM_OPS_03_CUSTODY_IMPLIES_RESPONSIBILITY"},
  {"id":"A-CUST-05","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A recorded location change is used to close one custody record and open another.","expect":"The derived custody change is rejected.","violates":"A location or access change does not imply a custody change.","closesDefect":"D01","expectedCode":"EM_OPS_03_CUSTODY_IMPLIES_LOCATION_OR_ACCESS"},
  {"id":"A-CUST-06","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A new model identifier is requested for the custody relationship because it carries its own record identity.","expect":"The allocation request is rejected.","violates":"Custody is an effective-dated relationship record independently identified within the WM-OBJ-001 boundary and allocates no model or runtime identifier.","closesDefect":"D02","expectedCode":"EM_OPS_03_CUSTODY_IDENTIFIER_ALLOCATED"},
  {"id":"A-CUST-07","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"Custody transfers between two parties with acknowledgement and condition at handover recorded.","expect":"The prior record is closed with validTo, a successor record is opened, and both intervals remain reconstructable.","violates":"Custody transfer closes the prior record and opens a successor; neither record is overwritten.","closesDefect":"D01"},
  {"id":"A-BND-01","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"A leased instrument has title with the lessor, custody with the enterprise, operational responsibility with a named party, a location assignment at a third site and an access assignment to a fourth group, all on independent effective dates.","expect":"All five assignments coexist and remain separately queryable without any one rewriting another.","violates":"Title holder, custodian, operationally responsible party, location assignment and access assignment may differ simultaneously and a change to one does not rewrite the others.","closesDefect":"D11"},
  {"id":"A-BND-02","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"The WM-ECO-011 holding view is used to assert the current custodian, the responsible party and instrument fitness.","expect":"The assertions are rejected.","violates":"WM-ECO-011 is an aligned holding view and never masters custody, operational responsibility, location, access or fitness.","closesDefect":"D11","expectedCode":"EM_OPS_03_ECO011_MASTERS_OPERATIONAL_FACT"},
  {"id":"A-BND-03","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"The WM-OBJ-022 accounted-asset projection is used as the instance identity key and as the source of calibration validity.","expect":"Both uses are rejected.","violates":"WM-OBJ-022 is a projection and never masters identity, calibration validity or fitness.","closesDefect":"D11","expectedCode":"EM_OPS_03_OBJ022_MASTERS_IDENTITY_OR_VALIDITY"},
  {"id":"A-BND-04","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"Value, depreciation and criticality are read for an asset instance through WM-OBJ-022.","expect":"The read succeeds as a projection over WM-OBJ-001 with no second master identity created.","violates":"WM-OBJ-022 is a projection and never masters identity, calibration validity or fitness.","closesDefect":"D11"},
  {"id":"A-ALLOC-01","target":"EM-OPS-03 validation policy","kind":"positive","input":"The Maintenance Plan, Maintenance Event and Calibration Event candidates are validated with modelId null, registryId null and allocationState unassigned.","expect":"All three pass validation and remain non-publishable candidates.","violates":"EM-OPS-03 allocates no model identifier and no runtime identifier.","closesDefect":"D16"},
  {"id":"A-ALLOC-02","target":"EM-OPS-03 validation policy","kind":"negative","input":"A WM-prefixed identifier is written into modelId on one of the three candidates.","expect":"The candidate is rejected.","violates":"EM-OPS-03 allocates no model identifier and no runtime identifier.","closesDefect":"D16","expectedCode":"EM_OPS_03_IDENTIFIER_ALLOCATED"},
  {"id":"A-ALLOC-03","target":"EM-OPS-03 validation policy","kind":"negative","input":"allocationState is set to assigned while registryId remains null and no registry reservation record exists.","expect":"The candidate is rejected.","violates":"Registry allocation is pending and no identifier may be guessed.","closesDefect":"D16","expectedCode":"EM_OPS_03_ALLOCATION_STATE_INVALID"},
  {"id":"A-REF-01","target":"Calibration Event","kind":"negative","input":"The candidate references WM-KNW-013, WM-REC-010 and WM-REC-001 as method, decision and certificate targets although no admitted evidence supplies them.","expect":"The reference targets are rejected and replaced by unresolved role slots.","violates":"Registry allocation is pending and no identifier may be guessed.","closesDefect":"D03","expectedCode":"EM_OPS_03_UNVERIFIED_REFERENCE_TARGET"},
  {"id":"A-DEP-01","target":"Calibration Event","kind":"negative","input":"configurationRef is resolved by allocating a new configuration model instead of citing the reserved WM-OBJ-023 boundary.","expect":"The allocation is rejected and the dependency remains open.","violates":"WM-OBJ-023 is the reserved measuring-instrument/configuration boundary, is a completion dependency of EM-OPS-03, and receives no allocation here.","closesDefect":"D04","expectedCode":"EM_OPS_03_OBJ023_TREATED_AS_ALLOCATION"},
  {"id":"A-DEP-02","target":"Calibration Event","kind":"positive","input":"The candidate declares completionDependencies WM-OBJ-023 and leaves configurationRef resolution open.","expect":"The candidate remains valid, incomplete and explicitly non-publishable.","violates":"WM-OBJ-023 is the reserved measuring-instrument/configuration boundary, is a completion dependency of EM-OPS-03, and receives no allocation here.","closesDefect":"D04"},
  {"id":"A-EVT-01","target":"Maintenance Event","kind":"negative","input":"One maintenance event cites two authorizing work orders.","expect":"The event is rejected.","violates":"A maintenance event cites at most one authorizing work order.","closesDefect":"D08","expectedCode":"EM_OPS_03_ORDER_CARDINALITY_EXCEEDED"},
  {"id":"A-EVT-02","target":"Maintenance Event","kind":"positive","input":"A WM-ACT-007 order is closed with zero maintenance events recorded against it.","expect":"The order remains valid and no maintenance event is inferred.","violates":"An authorizing work order may cite zero maintenance events, including after closure.","closesDefect":"D08"},
  {"id":"A-EVT-03","target":"Maintenance Event","kind":"negative","input":"A WM-MAT-008 observation record is registered as the maintenance event itself.","expect":"The substitution is rejected.","violates":"WM-MAT-008 observations and WM-ACT-034 assessments may be cited as evidence and never constitute event identity.","closesDefect":"D09","expectedCode":"EM_OPS_03_EVIDENCE_SUBSTITUTES_EVENT"},
  {"id":"A-EVT-04","target":"Calibration Event","kind":"negative","input":"A WM-ACT-034 assessment of instrument condition is registered as the calibration event itself.","expect":"The substitution is rejected.","violates":"WM-MAT-008 observations and WM-ACT-034 assessments may be cited as evidence and never constitute event identity.","closesDefect":"D09","expectedCode":"EM_OPS_03_EVIDENCE_SUBSTITUTES_EVENT"},
  {"id":"A-EVT-05","target":"Maintenance Event","kind":"negative","input":"componentChanges are recorded while continuityRuleRef and continuityRuleVersion are absent.","expect":"The event is rejected.","violates":"Asset continuity follows a pinned local rule.","closesDefect":"D07","expectedCode":"EM_OPS_03_CONTINUITY_RULE_UNPINNED"},
  {"id":"A-EVT-06","target":"Maintenance Event","kind":"positive","input":"An accepted event is later voided by the verifier.","expect":"The voided state is appended and the original record, evidence bindings and performed interval remain intact.","violates":"Voiding, supersession and correction are appended states that preserve the original record, its evidence bindings and its performed interval.","closesDefect":"D20"},
  {"id":"A-EVT-07","target":"Maintenance Event","kind":"negative","input":"A correction overwrites the original resourceActuals value in place.","expect":"The mutation is rejected.","violates":"Corrections append and never erase original evidence.","closesDefect":"D20","expectedCode":"EM_OPS_03_RECORD_OVERWRITTEN"},
  {"id":"A-CAL-01","target":"Calibration Event","kind":"negative","input":"A conformity statement is issued with no decisionRule recorded.","expect":"The conformity statement is rejected.","violates":"Determination, decision and attestation remain separable.","closesDefect":"D05","expectedCode":"EM_OPS_03_CALIBRATION_DECISION_RULE_MISSING"},
  {"id":"A-CAL-02","target":"Calibration Event","kind":"negative","input":"Results are released without calibratedRange or calibrationPoints.","expect":"The release is rejected.","violates":"Range and calibration points are explicit.","closesDefect":"D05","expectedCode":"EM_OPS_03_CALIBRATION_RANGE_MISSING"},
  {"id":"A-CAL-03","target":"Calibration Event","kind":"negative","input":"validityState is set to valid while validityConditions are absent.","expect":"The validity assertion is rejected.","violates":"Expiry ends fitness support without deleting history.","closesDefect":"D05","expectedCode":"EM_OPS_03_CALIBRATION_VALIDITY_CONDITIONS_MISSING"},
  {"id":"A-CAL-04","target":"Calibration Event","kind":"negative","input":"A declared break in the traceability chain is recorded and dependent fitness is left asserted.","expect":"The retained fitness is rejected.","violates":"Broken traceability invalidates dependent fitness.","closesDefect":"D05","expectedCode":"EM_OPS_03_CALIBRATION_TRACEABILITY_BROKEN"},
  {"id":"A-CAL-05","target":"Calibration Event","kind":"negative","input":"A single lifecycle state encodes determination, conformity decision, attestation and validity together.","expect":"The state model is rejected.","violates":"The four lifecycle axes advance independently and no single state may encode determination, decision, attestation and validity together.","closesDefect":"D06","expectedCode":"EM_OPS_03_CALIBRATION_AXES_CONFLATED"},
  {"id":"A-CAL-06","target":"Calibration Event","kind":"positive","input":"An event records determinationState evaluated, decisionState nonconforming, attestationState attested and validityState valid.","expect":"All four axes are stored separately and the nonconforming decision does not withdraw the attestation.","violates":"Determination, decision and attestation remain separable.","closesDefect":"D06"},
  {"id":"A-CAL-07","target":"Calibration Event","kind":"negative","input":"A certificate artifact is treated as the calibration event, with no event record created.","expect":"The substitution is rejected.","violates":"A certificate is the immutable artifact of exactly one calibration event and never substitutes for the event.","closesDefect":"D09","expectedCode":"EM_OPS_03_CERTIFICATE_SUBSTITUTES_EVENT"},
  {"id":"A-CAL-08","target":"Maintenance Event","kind":"negative","input":"A measuring subsystem is replaced and the prior calibration event, certificate and validity window are bound to the successor configuration.","expect":"The transfer is rejected.","violates":"A component change that affects a measuring subsystem invalidates dependent fitness and never carries a calibration event, certificate or validity to the successor configuration.","closesDefect":"D07","expectedCode":"EM_OPS_03_CALIBRATION_TRANSFERRED_ON_REPLACEMENT"},
  {"id":"A-FIT-01","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"Fitness is evaluated at query time for a stated purpose from the current configuration, the in-force calibration event and its validity conditions.","expect":"A derived fitness assertion is returned with its inputs and evaluation time, stored nowhere as an instrument property and allocating no identifier.","violates":"A fitness assertion is derived at evaluation time for a stated purpose and is never stored as a property of the instrument, model or economic view.","closesDefect":"D18"},
  {"id":"A-FIT-02","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A fit-for-use flag is written onto the asset instance record after a successful calibration.","expect":"The stored property is rejected.","violates":"A fitness assertion is derived at evaluation time for a stated purpose and is never stored as a property of the instrument, model or economic view.","closesDefect":"D18","expectedCode":"EM_OPS_03_FITNESS_STORED_AS_PROPERTY"},
  {"id":"A-FIT-03","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"Fitness is asserted with no statedPurpose.","expect":"The assertion is rejected.","violates":"Fitness is derived for a stated use.","closesDefect":"D18","expectedCode":"EM_OPS_03_FITNESS_PURPOSE_MISSING"},
  {"id":"A-FIT-04","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A fitness assertion for one instrument configuration is extended to every instrument of the same model and to the instrument class.","expect":"The propagation is rejected.","violates":"A fitness assertion is scoped to one instrument configuration and never extends to another serial of the same model.","closesDefect":"D18","expectedCode":"EM_OPS_03_FITNESS_PROPAGATED_BY_MODEL"},
  {"id":"A-FIT-05","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"The calibration validity window lapses while an authorized maintenance order remains open.","expect":"Fitness evaluates negative for purposes requiring calibration, the prior certificate and all prior assertions remain queryable, and the open order still proves no execution.","violates":"Validity expiry, configuration change or purpose change drops the current assertion and leaves all prior assertions and certificates intact.","closesDefect":"D18"},
  {"id":"A-PLN-01","target":"Maintenance Plan","kind":"negative","input":"A plan version applicable at model scope is read as establishing calibration coverage for every instance in that scope.","expect":"The inference is rejected.","violates":"Plan applicability at type, variant or configuration scope never establishes instance-level calibration, fitness or coverage.","closesDefect":"D19","expectedCode":"EM_OPS_03_PLAN_APPLICABILITY_IMPLIES_CALIBRATION"},
  {"id":"A-PLN-02","target":"Maintenance Plan","kind":"positive","input":"A plan version declares scopeKind type with explicit instance resolution before any due item is raised.","expect":"The applicability is accepted and each due item resolves to a named asset instance.","violates":"Applicability is explicit and versioned.","closesDefect":"D19"},
  {"id":"A-RSP-01","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"EM-OPS-03 raises a second Operational Responsibility Assignment candidate alongside the EM-LND-17 one.","expect":"The second candidate is rejected.","violates":"EM-OPS-03 raises no second operational-responsibility candidate and allocates no identifier for the reused one.","closesDefect":"D13","expectedCode":"EM_OPS_03_RESPONSIBILITY_SECOND_CANDIDATE"},
  {"id":"A-RSP-02","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"A responsibility assignment is recorded without governingBasis or without validFrom.","expect":"The assignment is rejected.","violates":"Responsibility assignment requires basis and interval.","closesDefect":"D13","expectedCode":"EM_OPS_03_RESPONSIBILITY_BASIS_OR_INTERVAL_MISSING"},
  {"id":"A-RSP-03","target":"Enterprise Asset Custody and Maintenance","kind":"positive","input":"The reused EM-LND-17 candidate is cited with sourceContourId EM-LND-17, modelId null, registryId null and allocationState unassigned.","expect":"The reuse is accepted and no identifier is allocated.","violates":"EM-OPS-03 raises no second operational-responsibility candidate and allocates no identifier for the reused one.","closesDefect":"D13"},
  {"id":"A-POL-01","target":"EM-OPS-03 validation policy","kind":"negative","input":"A fixture is submitted without target, violates or closesDefect.","expect":"The fixture file is rejected.","violates":"Fixtures must carry id, target, kind, input, expect and closesDefect.","closesDefect":"D14","expectedCode":"EM_OPS_03_FIXTURE_FIELD_MISSING"},
  {"id":"A-POL-02","target":"EM-OPS-03 validation policy","kind":"negative","input":"A negative fixture is submitted with no expectedCode, or with a code absent from the error-code registry.","expect":"The fixture file is rejected.","violates":"Every negative fixture carries an expectedCode drawn from the EM-OPS-03 error-code registry.","closesDefect":"D15","expectedCode":"EM_OPS_03_EXPECTED_CODE_MISSING"},
  {"id":"A-POL-03","target":"Enterprise Asset Custody and Maintenance","kind":"negative","input":"The profile candidate is submitted without canonicalPublishable false and without a holds array.","expect":"The profile candidate is rejected.","violates":"One frozen semantic audit is complete; base specifications and approved relations remain incomplete.","closesDefect":"D12","expectedCode":"EM_OPS_03_PROFILE_PUBLICATION_HOLD_MISSING"},
  {"id":"A-EVD-01","target":"Maintenance Event","kind":"negative","input":"Absent completion evidence is stored as zero or null rather than as a coded unknown.","expect":"The coercion is rejected.","violates":"Missing completion evidence remains unknown.","closesDefect":"D17","expectedCode":"EM_OPS_03_MISSING_EVIDENCE_COERCED"}
]
```

---

## 4. Exact final fixture counts

| Set | Positive | Negative | Total |
|---|---|---|---|
| Prior (3 artifact fixture files, 6 each) | 9 | 9 | 18 |
| Additional (section 3) | 13 | 33 | 46 |
| **Total** | **22** | **42** | **64** |

Prior breakdown: Maintenance Plan 3 positive / 3 negative; Maintenance Event 3 positive / 3 negative; Calibration Event 3 positive / 3 negative. Prior counts are unchanged by D14, which re-fields the same 18 cases without adding or removing any. Additional positives: A-CUST-01, A-CUST-07, A-BND-01, A-BND-04, A-ALLOC-01, A-DEP-02, A-EVT-02, A-EVT-06, A-CAL-06, A-FIT-01, A-FIT-05, A-PLN-02, A-RSP-03 (13). All remaining 33 additional fixtures are negative and each carries an `expectedCode`.

---

## 5. Freeze decision

**FROZEN.** The boundary stated in the audit brief is frozen exactly as written, including the Custody resolution in D02 and the refusal of allocation inside WM-OBJ-023. This audit is the single frozen semantic audit for EM-OPS-03; it is now closed. No rerun, no further study and no additional review round is requested, required or admissible.

Frozen artifact state: three identifier-unassigned roots (Maintenance Plan, Maintenance Event, Calibration Event) with `modelId: null`, `registryId: null`, `allocationState: "unassigned"`, `canonicalPublishable: false`; one non-allocating enterprise profile; one reused EM-LND-17 responsibility candidate; zero model identifiers and zero runtime identifiers allocated. Defects D01–D20 and the 46 fixtures above are the exact and complete closure set for this audit — remediation is mechanical and requires no further semantic judgement.

Remaining non-audit holds, carried forward unchanged and explicitly **not** closed here: registry reservation for the three roots; WM-OBJ-023 completion; the WM-ECO-011 specification and semantic crosswalk and enterprise title mastership; the WM-ACT-007 / WM-ACT-013 K11 duplication; WM-OBJ-023's unsupplied declared parent WM-OBJ-008; empty relation contracts and single-provider waivers on the bases; package conversion and live verification. No canonical completeness, no installability and no publication readiness is claimed.