Glossary
Every term used across the documentation, defined in one place.
Looking for cloud and finance terms instead?
This page defines the product's own vocabulary. If you want commitment, egress, rightsizing, showback, or amortised cost explained without assuming cloud knowledge, see the glossary on In Plain Words.
| Term | Definition |
|---|---|
| Active detector | A rule backed by real detection logic that produces findings. There are 309. This is the count to use when assessing detector depth. |
| Apex | The natural-language control plane over the whole platform. 135 registered capabilities, each a typed, permission-aware binding to a real platform function. See Apex. |
| APPROVE | The literal confirmation phrase required before Apex executes a write plan. The legacy phrase CONFIRM is still accepted. |
| Approval request | A gate. Any write that changes your cloud estate or spends money passes through one, carrying savings at stake, blast radius, rollback plan, and policy reason. |
| Blast radius | What a proposed change touches — presented on every approval request so a decision can be made without investigation. |
| Capability | A typed, permission-aware binding from an Apex utterance to a platform function. |
| Cloud connection | A credentialed link to one AWS account, Azure subscription, GCP project, or OCI tenancy. |
| Composite priority | The finding ranking: savings weighted by confidence and divided by effort. |
| Confidence score | A value between zero and one indicating how certain a detection is. Also used in PR Cost Review to indicate whether pricing came from live APIs or a heuristic fallback. |
| Cross-cloud detector | One of 23 detectors operating on the normalised ledger after ingestion, catching patterns only visible when providers are compared side by side. |
| Dry run | A mode that simulates an entire remediation action without calling the provider. |
| Effort score | How much work a fix represents. One of the three inputs to composite priority. |
| Execution role | The second, higher-privilege cloud role that enables remediation. Separate from the read-only role and verified independently. |
| Execution window | A configured period during which automated actions may run — what prevents automation firing during a change freeze or peak period. |
| External ID | The per-customer secret in an AWS role trust policy that prevents the confused-deputy problem. |
| Finding | One detected condition — waste, risk, misconfiguration, or policy violation — with savings, confidence, effort, risk, and a recommended action. |
| FOCUS | The FinOps Foundation's open cost specification. The normalised ledger is aligned to it. |
| Identified savings | Predicted savings. Cheap to produce; every cost tool quotes them. Contrast realised savings. |
| Normalised ledger | The common cost ledger onto which provider-native billing data is mapped, making AWS, Azure, GCP, and OCI costs directly comparable. |
| Normalization rule | A rule standardising the team, environment, feature, or tenant dimensions across providers that name them differently. |
| Opportunity | A finding that has been costed, prioritised, and classified by remediation class. |
| Organisation | The top-level customer tenant. Owns users, subscription, SSO configuration, and one or more workspaces. |
| Protected tag | finops:protected=true. Unconditionally exempts a resource from every automated action. No setting overrides it. |
| Realised savings | Savings verified against subsequent actual spend after a fix landed. The number that appears on an invoice. |
| Remediation class | The taxonomy dividing opportunities into advisory (a human decides), guided (the platform supplies the command), and automatable (the platform executes it). |
| Remediation execution | The record of an action actually carried out — what was attempted, under which credentials, in which window, what the provider returned, and whether it was verified as saving money. |
| Rollout safety | Staging execution rather than firing every action at once. |
| Runtime coverage | The proportion of the estate actually being scanned. Low coverage means the absence of a finding proves nothing. |
| Scan lineage | The provenance trail letting every inventory resource be traced to the scan that observed it and when. |
| Sensitive-action verification | A second, separately verified challenge required for high-consequence operations such as disconnecting a cloud account. |
| Spend record | One normalised unit of cost on the common ledger. |
| Transactional outbox | The pattern guaranteeing an event is written in the same transaction as its state change — the basis of at-least-once event delivery. |
| Workspace | The data boundary. Every domain query is scoped to exactly one. Cross-workspace leakage is structurally prevented rather than filtered out. |
| Attestation | A request to a resource's recorded owner asking them to confirm it is still needed. Used by Lifecycle when a time-to-live expires — expiry raises this question rather than deleting anything. |
| Cadence | How often a Workforce seat comes on shift. Set as a baseline by the seat's grade, then paced by the seat itself within a defined band. |
| Coverage | The proportion of something the platform could actually account for — spend it could attribute to a team, or estate it could scan. Reported explicitly rather than assumed, because a figure computed on a partial base is misleading. |
| Grade | A Workforce seat's level, 1 to 5. Sets its hourly rate, its reasoning capability, and its baseline cadence together. |
| Seat | One staffed role on a Workforce team, billed per rota-minute. A seat that is off shift costs nothing. |
| Standby fraction | The reduced rate — a quarter — at which a Workforce cycle bills when it found nothing to act on. |
| Time to live (TTL) | An expiry date attached to a resource that was only meant to exist for a while. See Lifecycle. |