# EM-WRK-03 — Independent Adjudication

## Verdict
Reuse WM-ACT-029 under a required **Program** profile; add no new model root. Disposition of candidates: **Program** → reuse WM-ACT-029 (profile-discriminated). **ProgramComponent** → membership assertion owned by WM-ACT-029; addressable, not a master. **Tranche** → program-scoped sequencing band inside WM-ACT-029's roadmap layer; addressable, not a master. **BenefitDependency** → typed link inside WM-ACT-029's results-chain; addressable, not a master. **TransitionPlan** → profile of WM-ACT-008 (plan identity and versioning) plus program-scoped readiness/handover assertions in WM-ACT-029. No identifiers allocated. Boundary decision: **reuse + profile**, with two blocking gaps (§Holds).

## Evidence
WM-ACT-029 already owns, as first-class findings, component membership and dependency, results chain with disbenefit and attribution limits, roadmap/tranche/horizon, transition and sustainment, and lifecycle/closure — the exact surface of the five candidates. Its `out_of_scope` and `policies` already state that component, benefit, operation and observation masters stay external, that profile is mandatory, and that completion or spending does not prove realization. Its declared `adversarial_checks` already reject the negative case. The contour's three proposed invariants are therefore restatements of existing WM-ACT-029 rules, not grounds for new types.

## Identity/mastership
Independent identity is required for: the Program root (source-qualified aggregate identifier), each membership/priority/lifecycle **event** (immutable, provenance-bearing), each results-chain node and link assertion, and the transition **plan** (WM-ACT-008 masters plan identity and is independently versioned per the frozen relation set). Independent identity is **not** required for ProgramComponent, Tranche or BenefitDependency as model roots: each is an assertion whose identity is `{program-id}--{artifact-kind}--{assertion-id}`, valid only inside one aggregate. Component masters (WM-ACT-005 projects, operations, products) keep their own identity, owner, lifecycle, plan and evidence; PPM/tracker masters them, not the program.

## Program vs Portfolio
One root, one mandatory profile, profile-specific rules. Program = related components coordinated for a joint outcome with an explicit benefit hypothesis and inter-component dependency; sequencing is dependency-led. Portfolio = strategy-aligned selection, prioritization and balancing; components need not be related. Profile change is supersession with new identity, never an in-place update. **Negative case rejected:** a folder of unrelated projects has no joint benefit hypothesis and no dependency graph, so it fails the program guard; absent mandate, accountable owner, selection criteria and reserved decisions it also fails the portfolio guard — it is a tracker container, not either. Against WM-ACT-005: a project has one authorization instrument and one baseline set; a program has no baseline over component internals. Against WM-ACT-030: an Initiative is pre- or cross-formal change intent whose formalization **mints new identity**; a program is a formalization target, never a renamed initiative.

## Components/membership
Membership is an appended, source-qualified event with basis, authority, effective interval and expected revision. It never absorbs or rewrites the component master. Components are not restricted to projects: operations, products, campaigns and non-project work packages are admissible, and non-project components carry no WM-ACT-005 baseline. Removal ends membership without cascading to the component's lifecycle; program termination or closure never closes, cancels or deletes a member. The program owner may not assert component baselines, task states, actuals or risk facts — those remain WM-ACT-005/WM-ACT-008 assertions referenced by identity.

## Tranches/transition
A **tranche** groups work across several components into a program-level sequencing band terminated by a program gate whose reserved decision is continue / rebalance / stop. A **project phase** is an intra-project lifecycle stage with its own entry/exit criteria and gate authority owned by WM-ACT-005. A tranche gate does not authorize a project phase transition and a completed phase does not close a tranche. A **TransitionPlan** is a versioned intention (WM-ACT-008) to hand a capability to a named operating owner: readiness, affected groups and adoption are program-scoped; **operational acceptance** is a separate decision by the receiving operation owner, evidenced via acceptance/assessment records (WM-ACT-034 profile); **sustainment** obligations survive program closure and belong to the operation master.

## Benefits/dependencies/attribution
Four separable assertion classes. **Output/capability** — delivered by a component. **Outcome** — asserted change in a subject's state. **Benefit/disbenefit** — governed claim over outcomes with owner, baseline, target, indicator, period and realization plan. **Causal claim** — hypothesis (falsifiable, in the results chain), dependency (typed, directed, validity-bounded link between chain nodes or components), and attribution (contribution share with method, uncertainty and declared causal limit). Adjudicated shares for one benefit and period must not exceed 1.0 and must not be double-counted between the program and its constituent projects. Benefit masters are external and currently **unallocated** (see Holds).

## Governance/decision rights
The program owns mandate, governance model, reserved decisions, thresholds, assurance, gates, membership changes, sequencing and allocation within its envelope. It does not own component authorization instruments, component baselines or component gate outcomes. Escalation from a component to the program is a referenced decision, not a transfer of mastership. Agent operations affecting membership, allocation, lifecycle, protected disclosure or disposition require delegated authority.

## Time/version/closure
Planned, decision, event, effective, observation, ingestion and knowledge times stay distinct. Released mandates, memberships, allocations, plans, decisions and observations are immutable; corrections are successors. Program closure is an authorized lifecycle event recording outcome, handover, benefit owner and residual obligations — it is neither project closure nor benefit realization, and a program may close with benefits still forecast.

## Acceptance scenario
PGM-1 (Program profile), components P-A and P-B (WM-ACT-005) plus transition to OPS-1. Joint benefit B-J depends on outputs from both plus sustained adoption. P-A closes at T1 with outcome classified and membership ended; B-J remains `forecast` with an explicit `measurement-pending` absent-reason — closure emits no realization assertion. P-B continues; its tranche gate is decided at program level while its phase gates stay with its own governing body. At T2 the transition plan release reaches operational acceptance by OPS-1; realization observations begin only after adoption, with phenomenon time distinguished from result time. Attribution across P-A and P-B remains unadjudicated until shares reconcile. A rise in support contacts is recorded as a disbenefit, not netted.

## Invariants
1. Exactly one profile per root; ambiguity fails validation. 2. Components are not restricted to projects. 3. Membership ≠ mastership; the program owner does not own component facts. 4. Program lifecycle changes never cascade to component masters. 5. Project closure proves neither outcome nor benefit. 6. Output, outcome, benefit, disbenefit and causal attribution are separate assertions. 7. A joint benefit requires an explicit, falsifiable hypothesis. 8. Adjudicated attribution shares ≤ 1.0 per benefit and period; no program/project double counting. 9. A tranche gate is not a project phase gate. 10. Transition plan ≠ operational acceptance ≠ sustainment. 11. Released assertions are immutable; history is never rewritten. 12. An arbitrary container is not a program.

## Minimal model set
WM-ACT-029 (Program profile) · WM-ACT-005 · WM-ACT-008 (transition/roadmap plans) · WM-ACT-034 (acceptance/benefit review) · WM-KNW-011 (objectives/targets) · WM-ACT-030 (upstream initiative, derivation only) · WM-ORG-016 (program-scoped assignments) · the unallocated Outcome/Benefit Realization and Metric Definition referents named in prior EM-STR-02/EM-DAT-05 work.

## Holds
Blocking: (a) the benefit master WM-ACT-029 externalizes is **unallocated**, so benefit logic terminates in a dangling reference; (b) the frozen registry lists `vr.wm-act-029` with `parent_ids = WM-ACT-005` **and** `contains_ids = WM-ACT-005` — a circular containment contradicting WM-ACT-005's rule that the edge is asserted parent-side only. Further: all relation rows unapproved; WM-ACT-029 and WM-ACT-030 are single-provider-waiver drafts with no independent review; `publishableCanonical` false throughout; ISO support is abstract-level only; retention/access rules are unsourced house policy; the programme/program token is unnormalized; the Program/Portfolio split remains deferred. No canonical completeness, installability or publication-readiness is claimed.