Pillar — Cost & FinOps

Prefix: COST- Catalog: v1.1 (new pillar). What it measures: whether an agent can see and bound spend — token, infrastructure, and operating-cost signals — before it scales a workload.

An unattended operator that cannot read its own burn rate will scale past the budget. This pillar is the cost contract: published budgets, queryable usage, and a stop condition an agent can honour. There is no v1.0 COST catalog; IDs in the COST-1xx band are the first published criteria for this dimension.

Criteria in this pillar

COST-100 — Spend budget published in a queryable form

Level: 2 · Scope: application · Check: deterministic
Each application publishes a machine-readable spend budget covering at least one of token or model usage, infrastructure, or operating cost. The budget names a period, a unit, a ceiling, and an owner. A wiki paragraph or a slide is not a budget.
Rationale: an agent that cannot read a ceiling will treat spend as unbounded. A queryable artifact is the only form a pipeline or an unattended operator can honour without a human opening a spreadsheet.
Evidence expected: a committed budget file, API, or equivalent structured record; fields include period, unit, ceiling, owner, and application identifier; a documented query path returns the current ceiling.

COST-110 — Usage attributed per application

Level: 3 · Scope: portfolio · Check: deterministic
Token, infrastructure, and operating-cost usage is attributed to an application identifier (or published package). A blended invoice that cannot be split by application does not satisfy this criterion. Path or service-account mappings that produce the identifier are committed.
Rationale: portfolio scoring is the unit. A single bill for the whole product hides the slice that is burning, and an agent cannot decide which workload to stop.
Evidence expected: usage export or cost report with an application (or package) field; a mapping from resource, account, or path to that field; a sample period showing every in-scope application or a justified not_applicable.

COST-120 — Exhausted budget stops scale

Level: 4 · Scope: application · Check: deterministic
Before an unattended process scales a workload (more replicas, more model calls, more batch jobs), it queries remaining budget for that application. When the ceiling is reached, the scale is refused or queued. Silent overspend does not satisfy this criterion.
Rationale: a dashboard without a stop condition is a spectator sport. Agents will keep calling a working API until the invoice arrives unless the runtime itself refuses the next unit of work.
Evidence expected: a gate, quota, or circuit in the scale or model-call path that reads COST-100; a failing remaining-budget check blocks the scale; a documented override is named, owned, and time-bounded.

COST-130 — Cost of a change estimated before merge

Level: 3 · Scope: application · Check: manual
A change expected to increase spend (a new model path, a new always-on resource, a new batch) records an estimated delta against the published budget before merge. The estimate names the dimension (tokens, compute, storage, or equivalent) and the period. Trivial copy edits may be marked not_applicable.
Rationale: COST-100 says what the ceiling is; it does not ask whether the next merge walks toward it. Agents that add an always-on path without an estimate learn the cost only after production.
Evidence expected: a template field, checklist, or review note on recent spend-affecting changes; dimension and period present; not_applicable used only where spend cannot change.

COST-140 — Portfolio spend visible as k/n

Level: 4 · Scope: portfolio · Check: manual
Spend versus budget is visible per application as k/n applications inside budget for the current period. A blended portfolio number that hides a burning slice does not satisfy this criterion. A newly added application is on the view within one review cadence or is marked not_applicable with a one-line justification.
Rationale: one green application next to an unbounded neighbour is not an agent-ready product. Portfolio scope (CSPC-31) is the scoring unit.
Evidence expected: dashboard or report with per-application spend, budget, and k/n; cadence stated; not_applicable entries justified.

v1.1 pillars — draft catalog, including these COST-1xx criteria.
Agent Governance — bounds on unattended actions that would otherwise ignore a budget.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 2 · Scope: application · Check: deterministic

Each application publishes a machine-readable spend budget covering at least one of token or model usage, infrastructure, or operating cost. The budget names a period, a unit, a ceiling, and an owner. A wiki paragraph or a slide is not a budget.

Rationale: an agent that cannot read a ceiling will treat spend as unbounded. A queryable artifact is the only form a pipeline or an unattended operator can honour without a human opening a spreadsheet.

Evidence expected: a committed budget file, API, or equivalent structured record; fields include period, unit, ceiling, owner, and application identifier; a documented query path returns the current ceiling.

Level: 3 · Scope: portfolio · Check: deterministic

Token, infrastructure, and operating-cost usage is attributed to an application identifier (or published package). A blended invoice that cannot be split by application does not satisfy this criterion. Path or service-account mappings that produce the identifier are committed.

Rationale: portfolio scoring is the unit. A single bill for the whole product hides the slice that is burning, and an agent cannot decide which workload to stop.

Evidence expected: usage export or cost report with an application (or package) field; a mapping from resource, account, or path to that field; a sample period showing every in-scope application or a justified not_applicable.

Level: 4 · Scope: application · Check: deterministic

Before an unattended process scales a workload (more replicas, more model calls, more batch jobs), it queries remaining budget for that application. When the ceiling is reached, the scale is refused or queued. Silent overspend does not satisfy this criterion.

Rationale: a dashboard without a stop condition is a spectator sport. Agents will keep calling a working API until the invoice arrives unless the runtime itself refuses the next unit of work.

Evidence expected: a gate, quota, or circuit in the scale or model-call path that reads COST-100; a failing remaining-budget check blocks the scale; a documented override is named, owned, and time-bounded.

Level: 3 · Scope: application · Check: manual

A change expected to increase spend (a new model path, a new always-on resource, a new batch) records an estimated delta against the published budget before merge. The estimate names the dimension (tokens, compute, storage, or equivalent) and the period. Trivial copy edits may be marked not_applicable.

Rationale: COST-100 says what the ceiling is; it does not ask whether the next merge walks toward it. Agents that add an always-on path without an estimate learn the cost only after production.

Evidence expected: a template field, checklist, or review note on recent spend-affecting changes; dimension and period present; not_applicable used only where spend cannot change.

Level: 4 · Scope: portfolio · Check: manual

Spend versus budget is visible per application as k/n applications inside budget for the current period. A blended portfolio number that hides a burning slice does not satisfy this criterion. A newly added application is on the view within one review cadence or is marked not_applicable with a one-line justification.

Rationale: one green application next to an unbounded neighbour is not an agent-ready product. Portfolio scope (CSPC-31) is the scoring unit.

Evidence expected: dashboard or report with per-application spend, budget, and k/n; cadence stated; not_applicable entries justified.