Portfolio Construction Model

Assumptions

Everything the model believes, stated before the math. If you do not buy one of these, do not buy the output.

1. The objective (maximize expected delivered MW against minimize capacity concentration) and every constraint come from the versioned, user-approved mandate contract; nothing is optimized that the user did not approve.
2. Unknown capacity, unknown class prior, or an out-of-allowlist state excludes a candidate with the reason printed - unknown inputs never receive favorable defaults.
3. Expected delivered MW uses the resolved-outcome class prior per project type; it is a descriptive screen, not a per-project model run.
4. Results are decision aids, not autonomous allocations.
5. The solver is exhaustive over subsets within the size bounds: OPTIMAL with gap 0, INFEASIBLE with the binding conflict, or REFUSED above the candidate cap - never an approximation.
6. The Pareto frontier is deterministic and reproducible from the same candidates and mandate.

Derivation

Each screened candidate carries capacity and a delivery probability from its project type's resolved-outcome class prior (minimum 5 resolved outcomes, else the candidate is excluded, not defaulted). Expected delivered MW is the product:

The solver enumerates every subset within the mandate's size bounds and keeps those satisfying the hard constraints - capacity target, sponsor share cap, node share cap, state allowlist. Concentration is the Herfindahl-Hirschman index over member capacities:

The Pareto frontier trades expected delivered MW against concentration: a portfolio is on the frontier only if no feasible portfolio delivers at least as much with lower concentration. Exhaustive enumeration means the gap is exactly zero - the answer is the answer, not a heuristic's best effort.

Identification strategy

Why the estimate supports the claimed meaning - and where the model refuses to claim more than the data carries.

• The mandate contract is the identification boundary: the model optimizes exactly what the user approved and nothing else, so a returned portfolio can never smuggle in an objective nobody signed.
• Exclusion over defaulting is the honesty mechanism for inputs: a candidate with unknown capacity or an uncalibrated class prior cannot quietly improve the objective - it leaves the candidate set with the reason printed.
• INFEASIBLE is a first-class answer with a certificate naming the binding conflict; the model never returns an approximation labeled feasible.
• Above the exhaustive cap the solver refuses rather than approximates - an over-cap candidate set is sent back for upstream screening, so the zero-gap guarantee is never diluted.

Inputs and outputs

Calibration and gate evidence

Validation design

• Contract-exact gates: solver status and zero gap are asserted, the frontier is checked non-dominated and reproducible, and exclusion, infeasibility, and refusal paths each carry their own gate.

Evidence on record

• Smoke gates at seal (7 m29-specific): solver prints status and zero gap; the frontier is reproducible and non-dominated; unknown-capacity candidates are excluded with reason, never defaulted; an infeasible mandate returns the binding conflict, not an approximation; an over-cap candidate set is refused, never approximated; determinism (identical input hash on re-run); audit row written for every run.

Gates at seal

• smoke: 7 m29 gates incl. zero-gap OPTIMAL, infeasibility certificate, refusal over approximation, determinism + audit row (suite counts at seal per the build agent's seal report)
• sealed at 7d17d8a7 on atlas-nl-shock-redesign

Failure modes

The ways this model declines, degrades or goes UNKNOWN - and what it prints when it does.

• Candidate with unknown capacity or uncalibrated class prior: excluded with the reason printed, never given a favorable default.
• Mandate no combination can satisfy: INFEASIBLE with the binding conflict named (capacity target unreachable, share caps binding).
• Candidate set above the exhaustive cap: REFUSED - screen further upstream.

Sensitivity

• The class prior is a type-level screen: two projects of the same type carry the same delivery probability regardless of their individual records, so the frontier ranks combinations, not projects.
• Tight share caps can collapse the feasible set quickly; the binding-constraints list shows exactly which mandate term did it.