Skip to main content

Portfolio Mechanics

Reference for how the Portfolio's figures are produced and configured. If you want to know what the dashboard shows and how to use it, start with The Portfolio App — this page is the layer underneath it.

The two money-at-risk measures​

Two measures of money-at-risk, and they are different numbers. Containment is the whole budget sitting inside programs that are overdue or not yet reviewed — a troubled program puts all of itself at stake. Expected exposure scales each budget by how much of that program has actually slipped, and is what the dashboard's bar lengths represent. Both are real; the smaller is not a correction of the larger. Neither is ever added to opportunity cost, which is a monthly flow rather than a budget stock.

Setting stewardship inputs​

The financial figures throughout the Portfolio — budgets, cost exposure, opportunity cost, and the Elios tiers derived from them — are grounded in stewardship inputs your organization supplies. Authorized owners and administrators can set these inputs directly from the dashboard; all other users see the same figures read-only. As with the Risk Matrix, editing is restricted to owners and administrators to maintain governance, and each control is checked on the server, so the interface reflects your authority rather than enforcing it alone.

Stewardship inputs are configuration, not governed decisions: they are recorded as your organization's own facts and take effect immediately, without a sign-off gate. (The signed, ledger-backed workflow is reserved for risk and lessons decisions, where a human ratifies a machine proposal.)

Program budget, type, and opportunity cost​

Open a program's stewardship & cost detail from its program-detail view (drill into a program in Portfolio Insights, then expand the detail panel). Owners and administrators can:

  • Set the program budget. The total budget flows into both money-at-risk measures (see below), so the hero metric and the program's exposure update as soon as you save.
  • Set the program type. Each program is classified as platform, strategic, compliance, infrastructure, or revenue. Program type also determines which past lessons a program draws on, so changing it re-groups the confirmed lessons that inform the program's risk narrative — a change the interface surfaces when you make it.
  • Record an opportunity cost. For revenue and strategic programs, you can record the estimated value foregone per month while the program is delayed, along with a short basis explaining it. This drives the Opportunity Cost (Forgoes) lens. Opportunity cost applies only to revenue and strategic programs; if a program is another type, the interface asks you to set the program type first. Should a program's type later change away from revenue or strategic, any recorded opportunity cost is cleared — you are told what will be removed before the change is applied, so nothing is dropped silently.

Cost centers and allocations​

Cost centers are the capital (capex) and operating (opex) pools your program budgets draw on. From the Cost Centers section, owners and administrators can create a cost center, edit its allocated budget, and allocate programs to it. A cost center's budget feeds the Cost Exposure (Consumes) lens; because portfolio-wide totals deduplicate shared cost centers, editing one center's budget updates every program that draws on it, while the portfolio total still counts it once.

Cost centers are retired rather than deleted. Retiring a center removes it from every financial lens — its budget no longer counts toward capex, opex, or the portfolio total — but the record itself is retained, along with when and why it was retired. A retired center can be reactivated at any time, which restores it to the lenses exactly as it was. Nothing is destroyed: the history is kept as organizational memory, so a center that is dormant today remains available to reason about later.

Allocating a program to a cost center also feeds the program's Elios tier, which is recomputed whenever an allocation changes or a linked cost center is retired or reactivated — so a program's tier stays consistent with its current footprint without waiting for a batch recalculation.

The tier is not purely financial. It is a weighted score — 60% financial, 40% complexity — banded into the three tiers:

  • The financial input is the sum of a program's active cost-center allocations. A retired center's allocation is excluded here exactly as it is excluded from the money lenses.
  • The complexity input is derived from your project record — how many sources a program spans, its issue volume, and its at-risk ratio. It is unaffected by stewardship edits, so changing a budget moves the financial term only.

A program with a modest budget but sprawling, at-risk delivery can therefore band higher than its budget alone would suggest. That is the intent: the tier allocates attention, and attention is not bought by budget size.

Allocations can also be proposed through a deterministic, rule-based gate. The proposal computes a suggested allocation directly from the program's own money-at-risk (budget × overdue share) so the figure matches the dashboard exactly; the gate abstains when no defensible grounding exists. Authorized owners or administrators review open proposals in the allocation inbox, which shows the current allocation, the suggested amount, and the full grounding formula. A decision (approve, amend within ratification, or reject) is signed into the ledger and, when approved, applies the allocation atomically in the same transaction. Direct configuration edits remain available and always take precedence, with any override of a previously signed allocation recorded as an audit event.

Governance Matrix Configuration​

A foldable section displays the organization's active Controls. Each Control shows its title, domain, criteria description, level (1–5), assessment scope (related programs), and the count of findings raised against it. Owners and administrators can create, edit, or delete Controls; deletion is blocked while findings or workflow gates reference the Control. All other users see the matrix read-only.

Findings appear in a review queue as Suggested Issues. Each entry shows the finding title and description alongside the breached Control's title, domain, level, and criteria. Authorized owners or administrators accept a Suggested Issue (promoting it to Open) or dismiss it (moving it to Closed); a dismiss always requires an explicit reason. Both outcomes are recorded as signed decisions. A separate decisions view lists the full history of resolved findings, including the actor, role, rationale, and resulting status. Findings are produced only when a deterministic checker returns positive evidence of a breach-candidate. Every control×program pair that cannot be evaluated produces an explicit abstention with a stated reason; the system never emits a "compliant" or "no-breach" verdict for controls it did not actually check. When facts are present and sufficient to confirm separation of duties or budget sign-off, the outcome is recorded as checked_clean with the supporting role citations so verified clean results are distinguishable from unchecked pairs.

Governance Issue Inbox​

Suggested governance findings (breaches of your organization's Controls) arrive in a dedicated review queue. Each entry shows the finding title, description, the breached Control (with its domain, level, and criteria), and the subject program or item. Authorized owners and administrators review these proposals and either accept them (promoting the finding to Open status in the register) or dismiss them (closing the finding, which requires a recorded reason). Every decision is signed into the ledger with actor, role, and timestamp. When a decision closes a workflow gate waiting on the same issue, the run resumes automatically. A separate decisions register shows the full history of resolved governance findings, including both accepted and dismissed outcomes.

Governance Issue Review​

Suggested governance findings (Issues) that breach active Controls appear in a dedicated review queue. Each entry shows the Issue title, description, domain, the breached Control (with its title, domain, level, and criteria), subject, and source. Authorized owners or administrators accept a finding (promoting it to Open) or dismiss it (to Closed); a dismiss requires an explicit reason. All decisions are signed into the ledger with actor, role, and timestamp. A separate decisions view lists the resolved history, including both accepted and dismissed outcomes with their rationales.

The adjudication step that follows detection is deliberately remove-only: the model receives only breach candidates already surfaced by a deterministic checker and may reject a candidate it finds ungrounded, but it is never asked to invent a new breach, upgrade an abstention, or assess overall compliance. Every upheld finding therefore traces to a concrete, machine-detectable signal that a human then ratifies; nothing reaches the register that the checker did not first identify.