**Verdict.** COMPLETE BOTH reserved models. No new catalogue or runtime ID. WM-ACT-009 owns method, procedure, immutable edition, competence requirements and adoption records. WM-ACT-003 owns process family, variant, immutable released definition, and — as components — instance, work item, step execution, deviation and compensation. A process references the exact adopted method edition. ProcessInstance and ActivityExecution remain 003 components; separate mastership is not proven. This is standards alignment, not a BPMN or CMMN conformance claim.

**Identity / lifecycle boundary.** Source facts: the card treats a methodology as rules of work, not a new instance. Legacy 009 (K6) already separates published knowledge from operational flow and records `editionReleased` versus `methodAdopted`. Legacy 003 (K3) already splits definition from execution and states that the gap between them is information. Neighbors that must not be remastered: WM-ACT-006 Task, WM-ORG-016 Work Assignment, WM-ACT-007 Work Order (already pins a procedure version), K2 Act.

- **009.** Identity: method-id + procedure-id + immutable edition `{id, digest, released-at, status, supersedes}`. Lifecycle of knowledge: draft → released → superseded / deprecated. Author owns editions; adopter owns AdoptionRecord `{adopter, edition, effective-from/to, attestation}`. Owns competence and scope-of-use. Fail if 009 stores running cases or observed steps.

- **003.** Identity: process-family-id + variant-id + immutable released definition `{id, digest, variant, adopted-edition-ref, released-at}`. Lifecycle of operations: family persists; variants coexist; definition versions form a supersession lineage. Fail if 003 authors procedure text or competence rules.

ProcessInstance and ActivityExecution fail the separate-aggregate test: they are `instanceOf` a 003 definition; they have no independent registrar; Task, Act and Assignment already exist as neighbors; no separate identity scheme is published. The unverified `stepExecution`↔K2-act cardinality is a 003 relation hold: if 1:N, record multiple act refs on the step component. Missing work-item structure is a 003 field gap, not a new model, and must reference 006 rather than become 006.

**Version / variant / adoption.** Version is a supersession lineage on both models. Released definitions and editions are immutable. Errata that change normative text mint a new edition, not an in-place edit. Variant is 003-only: concurrent alternative definitions of one family (standard versus express), each with its own version lineage. Variants are siblings, not predecessor/successor. Selecting a variant at start is an instance fact; changing it mid-flight is a deviation or an explicit migration event.

Adoption is effectivity. Publishing an edition does not make it applicable. A process family or variant pins the adopted edition, not “latest published.” A new adoption applies to instances that start after `effective-from`, or to in-flight instances only via an explicit cutover record. It never rewrites completed traces. BPMN engine practice is alignment only: running and completed instances stay on the version they bound.

**Assignment versus execution.** Work assignment (016 and/or 006) is who may or shall perform, including competence against 009 requirements. Observed execution (003 `stepExecution`) is who did perform, when, against which pins, with which evidence. Assignment can exist with zero execution. Execution without a surviving assignment is allowed only as a recorded deviation. Planned BPMN lane or CMMN role is definition content, not a trace. Work-item (offer/claim token) is distinct from both and stays a 003 component referencing 006.

Each instance and each step execution pins, at write time: family, variant (or explicit none), released definition id + digest, adopted method edition id + digest, adoption-record id, recorded-at. Pins are immutable on that record.

**Trace and deviation semantics.** A trace is the append-only observed record of an instance: pins + step executions + deviations + compensations. Correction is a successor event with reason, not an edit of the historical step. Deviation is an explicit departure from the pinned definition; a manual exception is a deviation kind. Compensation is an append-only response that keeps the same pins unless a remount record says otherwise.

Planned BPMN/CMMN paths do not prove actual traces. Conformance is a reproducible projection over `(pinned definition digest, pinned edition digest, observed trace)`, emitting alignment or fitness, rule-set version and execution instant. Re-running after a new edition is a new labelled projection; the historical projection stays. Do not store a floating “conformant” flag on the instance. IEEE XES / alignment practice is the public analogue, not a claimed implementation.

**Scenario results.**

*Negative — instruction update changes a completed process.* Instance I1 pins D1 / V1 / E1. Author releases E2 and D2. I1 keeps D1+V1+E1. E2 has no effect until an AdoptionRecord. Conformance of I1 remains the projection over (D1, T1). A system that mutates I1 fails the card.

*Acceptance — one family, two variants, exception, compensation, new edition.* V1 and V2 are concurrent released definitions pinning adopted E1. I1 on V1 records a manual exception and compensation; T1 stays on V1+E1. I2 on V2 yields T2 on V2+E1. After adoption of E2 and release of D3 (V1 pinning E2), I3 yields T3 on E2. T1 does not move. Recomputing “what E2 would have required of I1” is a new projection, not T1. Four reproducible artefacts; no new IDs.

**Missing fields / relations.** 009: edition digest and supersession; AdoptionRecord; competenceRequirement. 003: processFamily; variantId (absent in legacy); definition digest + adoptedEditionRef; instance pins; workItemRef → 006; stepExecution.actRefs[] → K2; append-only deviation and compensation. ConformanceResult is a 003 measurement projection, not a third model. Relation ledger must replace “latest method” with a pinned 009 edition.

**Migration steps.** Preserve both `0.2.0-legacy` assemblies as non-installable references. Open new draft versions on the same runtimes `vr.wm-act-003` and `vr.wm-act-009`. Populate the fields above. Replace wildcard imports and the circular 003↔009 require with typed REFERENCE (003 definition → 009 edition; step → K2 act; work-item → 006; assignment → 016). Add executable fixtures for the two card scenarios and for conformance replay across two editions before either runtime is installable.

**Publication blockers.** Both reserved runtimes are legacy, non-installable, and lack CRUD, roles and artifacts. Relation ledger is candidate-only. 003 has no variant object today. `stepExecution`↔act cardinality is unverified. Work-item structure is missing. Wildcard imports and unsupported BPMN/CMMN conformance claims remain. No executable fixtures. Do not invent a third process, method, instance or execution identifier.