# EM-WRK-04 — Portfolio and Investment Selection (independent adjudication) ## Verdict - **Portfolio** — *reuse + profile*. Profile `Portfolio` on WM-ACT-029, sibling to the `Program` profile taken in EM-WRK-03, under the required discriminator. No new root. - **SelectionCriterion** — *new, independent identity required*, as a versioned **criteria set** external to any one portfolio. Identifier unassigned. - **PortfolioComponent**, **Prioritization**, **InvestmentAllocation**, **PortfolioScenario** — *profile as addressable, effective-dated, immutable releases contained in the Portfolio root*. None has independent identity. - Reuse WM-ACT-005 (project), WM-ACT-030 (initiative), WM-ACT-029/`Program` (program-as-component), WM-ECO-012 (budget), WM-KNW-011 (objectives), WM-KNW-010 / WM-ACT-024 / WM-REC-010 (rationale, occurrence, issued record). No catalogue or runtime identifier allocated. ## Evidence WM-ACT-029 (complete spec, sha256 3ce9e40…, `aggregate`, reviewable-draft) already owns membership, dependency, prioritization, allocation, lifecycle and evaluation as root-owned assertions with all masters external, and explicitly rejects portfolio-as-registry. Its `prioritize-balance-sequence-and-reallocate` function names criteria, weights, constraints and scenarios as inputs and ranking/sequence/allocation as outputs; `admit-or-remove-component` requires criteria, authority, effective interval. Its own policy states portfolio components *need not be related*. That is a complete fit for this contour; the residual work is profile rules, not a new aggregate. ## Identity/mastership Portfolio identity persists across component turnover, criteria revisions, rebalances and strategy restatement. Component masters keep their own identifiers, owners, lifecycles, plans, baselines and evidence; the Portfolio owns only assertions *about* them. A criteria set survives the portfolios and cycles that cite it, is reused across both, and must remain resolvable after a portfolio closes — hence independent identity. Rankings, memberships, allocations and scenarios cannot exist outside the portfolio and its cycle, so they are contained. A `Program`↔`Portfolio` profile change is supersession with new identity, never an in-place update. ## Portfolio boundaries A **Program** coordinates related components toward a joint outcome and benefit hypothesis; a **Portfolio** selects, prioritizes and balances investments against strategy and constraints, and its members may be mutually unrelated. A **catalogue** is an index: no mandate, no reserved decision rights, no benefit logic, no lifecycle. A **project** owns its own authorization and baseline; a portfolio never becomes a super-project. An **initiative** is upstream change intent; portfolio membership neither formalizes it nor mints delivery identity. Membership in one portfolio implies no program semantics, no dependency, no shared outcome and no joint governance. ## Components/membership `PortfolioComponent` is a typed, source-qualified, effective-dated membership assertion carrying component reference and type, admission basis, criteria-set version, portfolio role, share basis and component owner. Components may be projects, initiatives, programs, products or operations; non-project components acquire no project semantics. Removal ends membership only — it does not close, cancel or delete the master. Portfolio lifecycle transitions never cascade to component lifecycle, baselines, actuals or risk facts. One component may be a member of several portfolios simultaneously. ## Criteria/scoring/prioritization Three separable layers. (1) **Criterion definition**: measure reference (external Metric Definition — unallocated), unit, scale, preference direction, mandatory-versus-compensatory class; released immutably in a versioned set. (2) **Observed score**: a source-qualified observation with period, method, denominator, quality and uncertainty, mastered by the observation/dataset model and referenced, never rewritten into the criterion or the component. (3) **Prioritization**: an immutable release pinning portfolio, criteria-set version, weighting scheme version, candidate set, period and authority, yielding a rank. Rank is a property of that release, not of the work: it is never written onto the component master and never compared across releases with different pins. Ordinal bands and incommensurable value/harm dimensions are not netted arithmetically without a declared method. ## Allocation/funding `InvestmentAllocation` is a portfolio-scoped intent inside an approved envelope: it is not budget authority (WM-ECO-012 authorization), not release/availability, not a commitment or obligation, not an accounting actual, and not the component's own funding. Each allocation declares funding-source reference, destination component, amount or share with currency, price base and valuation basis, effective period, restrictions, authority and residual rule. Double funding is prevented source-side: allocations drawn on one released funding source and period cannot exceed its released amount, residuals must reconcile, and aggregate reporting counts a component's cost and expected benefit once, with each portfolio reporting only its declared share. ## Scenarios/decisions `PortfolioScenario` is an immutable hypothesis release: a candidate composition plus allocation under stated capacity constraints, varied assumptions and method, optionally citing an external strategic scenario. It is never an authoritative actual, baseline or target. A scenario becomes the **approved baseline** only through a separate authorized decision — rationale (WM-KNW-010), occurrence (WM-ACT-024), issued record (WM-REC-010) — producing a distinct composition-and-allocation release. Alternative comparison pins one criteria set, horizon, currency, price base and metric revisions, and includes a do-nothing comparator or an explicit justified exception. Capacity is checked at scenario level, not at ranking level; the top-ranked set need not be the selected set, and divergence requires a recorded explanation. Strategic alignment is a versioned contribution claim; it is not a causal benefit claim, and spending, completion or inclusion proves neither outcome nor realization. ## Governance Portfolio governance owns mandate, reserved decision rights, admission and removal, criteria adoption, weighting, scenario selection, allocation within its envelope, thresholds, assurance and portfolio gates. Component authorization, baselines and internal gates remain component-owned. Escalation references a decision; it never transfers mastership. Product-versus-project comparison uses a common period with per-period incremental cost and expected value, a continue-at-current-level comparator for products, and no completion-based measures; product investments carry no implied end date. ## Time/version/rebalance Planned, decision, event, effective, observation, ingestion and knowledge times remain distinct. Membership, criteria pins, rankings, allocations and scenarios are effective-dated with non-overlapping intervals per assertion class. **Review cadence** is a declared interval plus event triggers (defeated assumption, constraint breach, funding change, strategy restatement, authority change, horizon expiry); a **rebalance** is a distinct authorized lifecycle event producing successor composition and allocation releases. Released items are immutable; correction is supersession with preserved provenance and no history rewrite. ## Acceptance scenario Portfolios PF-1 and PF-2 both admit initiative INI-1 with shares 0.6 and 0.4 from distinct released funding sources. Each admission is its own membership assertion; neither implies the other, and neither converts INI-1 into a project. PF-1 selects scenario SC-3, which pins criteria set CS-v2, weighting W-v1, the scored candidate set and capacity limits; decision D-7 approves it and issues REC-7. A later score revision or CS-v3 creates successor releases and may trigger review; SC-3, D-7 and REC-7 remain readable and reproducible as-of. Aggregate reporting shows INI-1 once, with shares attributed, and no source exceeds its released amount. Because PF-1's components share no dependency or outcome, no program is formed. ## Invariants 1. Exactly one WM-ACT-029 profile discriminator; portfolio components need not be related. 2. Membership never transfers component mastership. 3. Portfolio lifecycle never cascades to component masters. 4. One component may hold membership in several portfolios. 5. Criterion definition, weighting scheme and observed score remain distinct. 6. Rank is release-scoped, never an intrinsic work property. 7. Every comparison pins criteria, horizon, price base, metric revisions and a do-nothing comparator or exception. 8. Portfolio allocation is not authority, availability, commitment, actual or component funding. 9. Source-side released amounts are never exceeded; residuals reconcile; shares are counted once. 10. Scenario outputs are never actuals or baselines. 11. Baseline approval requires an authorized decision. 12. Alignment claims are not causal benefit claims. 13. Released assertions are immutable and superseded explicitly. 14. Profile change is supersession with new identity. 15. Unallocated and blocked referents are never silently promoted. ## Minimal model set WM-ACT-029 (`Portfolio` profile); contained PortfolioComponent, Prioritization, InvestmentAllocation, PortfolioScenario and approved-baseline releases; one new criteria-set candidate (identifier unassigned); referenced WM-ACT-005, WM-ACT-030, WM-ACT-029/`Program`, WM-ECO-012, WM-KNW-011, WM-KNW-010, WM-ACT-024, WM-REC-010. ## Holds Unallocated referents: criteria set, Metric Definition, Outcome/Benefit Realization, Product, Operation, Resource/Capacity, Funding Source, Commitment/Contract. Contradictions: WM-ACT-029 lists WM-ACT-005 as both parent and contained; WM-ACT-030's parent WM-ACT-005 conflicts with initiative-is-not-project; WM-ACT-029's programme/portfolio token is inconsistent across name, naming rule and identity strategies; its declared access scopes cannot express the field-level rules its default and audit clauses assume; its all-covered checklist is contradicted by its own omissions. WM-ACT-029, WM-ACT-030 and WM-ECO-012 are single-provider reviewable drafts with waived independent review; ISO support is abstract-only; relation rows are unapproved and frozen contracts empty; retention and access rules are unsourced house policy. Source pins, crosswalks, mastership confirmation and fixtures are unverified. No claim of canonical completeness, installability or publication readiness is made.