**Verdict.** Conditionally accept the proposal as a modeling stance. Do not allocate a new identifier. Do not claim publication readiness. Profile Program on WM-ACT-029 with a mandatory discriminator; retain Portfolio as the sibling profile on the same root; treat ProgramComponent, Tranche and BenefitDependency as addressable program-owned assertions; profile TransitionPlan on WM-ACT-008; keep readiness/handover bindings on WM-ACT-029; keep component mastership external.

None of the five candidates needs an independent root. The Outcome / Benefit Realization master remains unresolved. The WM-ACT-029↔WM-ACT-005 relation is membership-via-assertion, not identity containment. If adjacent WM-ACT-029 text still says a program “contains” projects, that wording is the contradiction to break, not authority. EM-WRK-03 does not rewrite WM-ACT-005.

**Strongest evidence.** Program and Portfolio share a governed-collection envelope (authorization, strategy binding, collection of work). The difference is organizing principle — joint outcome coordination versus investment balance — which a mandatory discriminator can carry without a new type family. External mastership is the only reading that preserves WM-ACT-005 Project identity when a project participates in a program. ProgramComponent, Tranche and BenefitDependency have no commissionable life outside a Program instance. The required test scenario is expressible with the named roots plus those owned assertions.

**Strongest counterexample.** If WM-ACT-029 inherits or declares identity containment of WM-ACT-005, then “profile Program on 029” and “component mastership stays external” cannot both be true. Profiling cannot cancel inherited containment. Secondary stress: a project in two programs. Dual ProgramComponent rows can record membership; BenefitDependency attribution cannot be inferred from dual membership. An arbitrary folder of unrelated projects is not a counterexample against the proposal; it is a rejection target the proposal must pass.

**Identity / mastership.** Program identity is a WM-ACT-029 instance with discriminator=Program, in the same identity space as Portfolio. The discriminator is mandatory, not nullable, and not silently flipped. Project identity is mastered only under WM-ACT-005; Initiative under WM-ACT-030; Goal/Objective under WM-KNW-011; Assessment/Evaluation under WM-ACT-034. WM-ORG-016 Work Assignment binds actors; it confers neither program nor component identity. Program masters its profile record; its ProgramComponent, Tranche and BenefitDependency assertions; and the WM-ACT-029 bindings that attach a TransitionPlan and readiness/handover conditions. Program does not master Project, Initiative, Goal/Objective, Assessment, operational service, or sustainment organization. ProgramComponent identity is not component identity: the assertion is owned by the Program and points at an external master.

**Independent root.** None. Program is a WM-ACT-029 profile. TransitionPlan is a WM-ACT-008 profile. The three assertions are owned parts of the Program profile. Promoting Tranche onto WM-ACT-008 was considered and rejected: a tranche slices capability delivery and membership; the schedule is a different object. Creating a root for BenefitDependency to stand in for the missing Outcome/Benefit Realization master would be a category error.

**Outcome / Benefit Realization master.** Unresolved, and must stay unresolved inside EM-WRK-03. BenefitDependency is not that master. If Program mastered realization, realization could not outlive program closure — contradicting program-closure ≠ benefit-realization. If Project mastered realization, a joint benefit across two projects would have no home — failing the test scenario. WM-KNW-011 holds intended aims, not realized benefit. WM-ACT-034 holds evaluation events, not durable benefit identity. Realization evidence may reference WM-ACT-034; intended aims may reference WM-KNW-011. A durable benefit identity is out of scope and absent from the adjacent set.

**WM-ACT-029↔WM-ACT-005 containment.** There is no containment. Lawful relation: a ProgramComponent assertion owned by the Program, referencing an externally mastered WM-ACT-005 (and, if asserted, WM-ACT-030). No minting, no nesting, no exclusive default. Containment would transfer mastership or lifecycle to the Program, make Program an arbitrary folder, prevent a project from closing while the program stays open, cascade program closure onto projects, and forbid a shared contributor. The test scenario requires the opposite.

**Program vs Portfolio.** Shared root, disjoint profiles. Program is a temporary outcome-delivery vehicle: intended-benefit targets, tranche sequence, transition bindings, membership assertions. It ends when the program is closed (realized, curtailed, or absorbed), not when the last project ends. Portfolio is the sibling profile: standing or cyclic investment-balance structure. It selects and prioritizes work. It does not own a single joint benefit, a tranche-of-change, or a single operational transition. Portfolio membership is not ProgramComponent. Program ≠ Project (WM-ACT-005 masters outputs). Program ≠ Initiative (WM-ACT-030 is the authorized change thrust, not the multi-component delivery vehicle). Program ≠ arbitrary container.

**Components / membership.** ProgramComponent records membership, role-in-program, and contribution window. Membership ≠ containment ≠ mastership. Dropping membership does not close the component. Closing the component does not erase the historical assertion. A project may sit in a Portfolio and a Program at once; neither assertion moves WM-ACT-005 mastership. The program cannot rewrite project scope, schedule, or closure state except by reference.

**Tranches / transition.** Tranche is a program-owned assertion: a planned increment of program capability/outcome. It may span several members. It is not a WM-ACT-005 project phase and not a WM-ACT-008 activity. TransitionPlan profiles WM-ACT-008 for sequence, dates and predecessors. Program-specific readiness and handover bindings stay on WM-ACT-029 so the plan profile is not overloaded with program authority. TransitionPlan ≠ operational acceptance (evaluative decision, WM-ACT-034). TransitionPlan ≠ sustainment (post-handover BAU ownership, outside program mastership). Existence of a plan is not handover. Bindings are references, not a second copy of the plan.

**Benefits / dependencies / attribution.** Output (component deliverable) ≠ outcome (changed operational state) ≠ benefit (measurable advantage). BenefitDependency is a program-owned assertion that an intended benefit requires specified members, outputs, other benefits, or a tranche increment. It is not the benefit, not a causal hypothesis, and not attribution. Causal claims sit at most with WM-KNW-011 as target statements. Attribution is an after-the-fact WM-ACT-034 judgment. Membership does not imply attribution.

**Governance.** Program authority ≠ project authority ≠ portfolio authority. WM-ORG-016 assigns roles to program, member, tranche or transition work and never transfers mastership. Program gates: tranche authorization, transition readiness binding, program-closure decision. These are distinct from WM-ACT-005 stage gates and from Portfolio investment gates. Readiness, acceptance and realization assessments are WM-ACT-034 instances pointing at program assertions; they are not ProgramComponents.

**Time / version / closure.** Program lifecycle is independent of each member’s lifecycle. Component closure ≠ program closure ≠ benefit-realization closure. Tranche completion ≠ program completion. Program closure does not close remaining members and does not require benefits realized. After program closure, realization tracking cannot hang on the closed Program as master. Version the Program profile, each assertion kind, and each TransitionPlan independently. Historical assertion rows survive member closure and program closure.

**Scenario — accept.** Program Omega, WM-ACT-029 discriminator=Program. Joint benefit: cycle-time reduction (not an output). Project Alpha (WM-ACT-005): intake service. Project Beta (WM-ACT-005): rules engine. ProgramComponent assertions owned by Omega point at Alpha and Beta; mastership remains WM-ACT-005. Tranche T1 = Alpha delivery plus partial operational handover. Tranche T2 = Beta delivery plus joint enablement. T1 is not an Alpha phase. TransitionPlan (WM-ACT-008 profile) schedules handover; operational acceptance and later sustainment are distinct events. BenefitDependency D: joint benefit requires Alpha output and Beta output and operational adoption. D is a dependency assertion, not a causal hypothesis and not attribution. At Alpha close: Alpha closed; Omega open; D unsatisfied; TransitionPlan incomplete; benefit unrealized. This shows program closure ≠ component closure ≠ benefit realization, and output ≠ outcome/benefit.

**Scenario — reject.** Label “Digital Stuff” grouping a website refresh and a warehouse move. No joint benefit, no BenefitDependency, no tranche spanning a shared outcome, no TransitionPlan binding. Discriminator may say Program; invariants fail. Not a Program. Not a Portfolio substitute either: no investment-balance thesis. Route the bag out of Program.

**Invariants.**
1. Every WM-ACT-029 Program instance has discriminator=Program; the Portfolio sibling has discriminator=Portfolio; the profiles are disjoint.
2. A Program is not a WM-ACT-005 Project, not a WM-ACT-030 Initiative, and not an unlabeled collection.
3. ProgramComponent never masters the member; member identity remains on its own root.
4. WM-ACT-029 does not contain WM-ACT-005 as child identity.
5. A Program must reference at least one intended outcome/benefit target; absent that target it is not a Program.
6. BenefitDependency asserts required contribution, not realized attribution and not a causal hypothesis.
7. Tranche is not a project phase and need not coincide with any member’s lifecycle.
8. TransitionPlan profiles WM-ACT-008; readiness/handover bindings remain on WM-ACT-029.
9. Existence of a TransitionPlan does not equal operational acceptance or sustainment.
10. Closure of one member does not close the Program or close benefit realization.
11. Program closure does not close remaining members and does not imply benefits realized.
12. Portfolio membership does not create Program membership, and vice versa.
13. WM-ORG-016 assignment does not move mastership.
14. Historical ProgramComponent, Tranche and BenefitDependency rows survive member closure and program closure.
15. Joint benefit may remain open after a contributing project has closed.
16. Membership does not imply attribution, including when a member appears in two programs.

**Minimum model set (no new ID).** WM-ACT-029 Program profile and sibling Portfolio profile with mandatory discriminator. Program-owned addressable assertions: ProgramComponent, Tranche, BenefitDependency. WM-ACT-008 TransitionPlan profile. WM-ACT-029 readiness/handover bindings. External member minimum: WM-ACT-005 Project. Referenced, not mastered here: WM-KNW-011 (intended targets), WM-ACT-034 (readiness, acceptance, realization evidence), WM-ORG-016, WM-ACT-030 as origin only.

**Blockers.**
1. Hard: WM-ACT-029↔WM-ACT-005 containment. Adjacent 029 text must be read, or rewritten in its own draft, as membership/participation. Until that is explicit, external mastership is fiction.
2. Hard: Outcome / Benefit Realization master remains missing. Do not assign it to WM-ACT-029, to BenefitDependency, or to any candidate in this set. Do not invent a code.
3. Soft: “Addressable program-owned assertions” must mean owned identifiable parts of the 029 Program profile, not new WM-* roots. A later reading that addressability requires new codes violates “do not allocate a new identifier.”
4. Soft: TransitionPlan structure on 008 plus bindings on 029 works only if both are addressable from the same governance gate and bindings are references, not a duplicate plan.
5. Soft: Program vs Initiative (WM-ACT-030) needs the stated rule — Initiative = change intent; Program = coordinated multi-component delivery vehicle — or the same work is double-booked.
6. Soft: discriminator-only is too weak if adjacent WM-ACT-029 still treats Program and Portfolio as the same unconstrained bag. Disjoint invariants must sit in the profiles, not only in a flag.