Learn / Glossary

The FinOps & cloud cost glossary

Plain-English definitions for the terms behind cloud cost, compliance, reliability and monitoring: the same vocabulary emnode uses across the product and these lessons.

Where this glossary uses the FinOps discipline’s vocabulary, it follows the framework defined by the FinOps Foundation. The definitions here are our own, written for practitioners. Reviewed by Nathan and Michael.

FinOps fundamentals & framework

The practice and vocabulary of cloud financial management. The discipline and its framework are defined by the FinOps Foundation; the definitions below are our own, written for practitioners.

FinOps: FinOps is an operational practice that brings finance, engineering and leadership together to manage cloud spend with shared accountability, so usage decisions are made with cost in mind. It is a continuous discipline, not a one-off cost-cutting project.
Inform, Optimize, Operate: These are the three iterative phases of the FinOps framework: Inform (visibility and allocation), Optimize (better rates and usage), and Operate (continuous governance). Teams cycle through them repeatedly rather than finishing them once. From Inform to Operate
FinOps Foundation: The FinOps Foundation is the non-profit, vendor-neutral body, part of the Linux Foundation, that defines and stewards the FinOps framework, its phases, capabilities and personas through community working groups. It publishes the open framework, runs practitioner certification, and provides the common vocabulary that practitioners and tools (including emnode) align to.
FinOps personas: FinOps personas are the roles the framework expects to collaborate on cloud spend: engineering, finance, product, leadership and the FinOps practitioner who connects them. Naming personas matters because each cares about different numbers, so reporting and decisions can be tailored to what that audience actually needs and acts on.
Crawl, Walk, Run: Crawl, Walk, Run is the FinOps maturity model: start small (Crawl) with basic visibility, broaden and automate (Walk), then run a mature, continuous practice (Run). It lets a team adopt each capability incrementally rather than attempting full maturity everywhere at once, and measure progress honestly.
FinOps capability: A FinOps capability is a discrete area of practice within the framework, such as cost allocation, anomaly management, rate optimisation or forecasting. Each sits inside a phase, can be assessed against the Crawl, Walk, Run maturity model, and gives teams a concrete unit of work to adopt and improve rather than a vague ambition.
Cloud financial management: Cloud financial management is the broad discipline of planning, budgeting, allocating and optimising cloud spend so it stays accountable and predictable. FinOps is the dominant operating model for practising it, applying the framework's phases and capabilities to turn variable, consumption-based cloud bills into something a business can plan around.
Shared accountability: Shared accountability is the FinOps principle that everyone who provisions cloud resources owns the cost of those decisions, not just finance. Engineers see the price of what they run, finance sees what drives it, and leadership sets the trade-offs, so spend becomes a team responsibility rather than a central department's problem.
FinOps KPI: A FinOps KPI is a metric that says whether the practice is working, for example commitment coverage, Effective Savings Rate, savings realisation rate or forecast accuracy. Good KPIs are tied to action and trended over time, distinguishing savings merely identified from savings verified against the actual bill. Savings realisation rate

Cost allocation & accountability

Attributing each line of spend to the team, product or environment that caused it, so a shared cloud bill becomes someone's responsibility.

Cost allocation: Cost allocation is the practice of assigning each line of cloud spend to the team, product or environment that caused it, usually through tags and account structure. Without it, a shared bill is just one large number that cannot be made anyone's responsibility, so no team has a reason to act on its own consumption.
Showback: Showback is the practice of reporting each team's cloud cost back to them for visibility, without moving any money between budgets. Each team sees what it consumed, but the bill still sits centrally. It builds cost awareness and a sense of ownership, and is often the step organisations take before chargeback, where real money actually changes hands.
Chargeback: Chargeback is the practice of billing each team or business unit for the cloud cost they actually incurred, moving that spend onto their own budget rather than a central one. Unlike showback, money changes hands, so cost stops being information and becomes a real constraint that teams must fund, which sharpens accountability but depends on accurate allocation.
Tags (tagging): Tags are key-value labels you attach to cloud resources (for example team, environment or cost-centre) and tagging is the practice of applying them consistently. They are the main mechanism for allocating spend, because most resources are otherwise anonymous on the bill. Tags can be applied at creation or enforced afterwards through policy.
Tag coverage: Tag coverage is the share of cloud spend or resources carrying the tags needed to allocate it, usually expressed as a percentage of cost or resource count. High coverage means almost every charge can be attributed to an owner. Low coverage leaves "untagged" spend that cannot be assigned, so the allocation, showback and chargeback built on top of it are incomplete.
Tagging strategy: A tagging strategy is the agreed set of tag keys, allowed values and rules that make spend allocable: which tags are mandatory, who owns each value, and how they are enforced. A good strategy is small and consistent, since too many optional tags produce sparse, unreliable data that defeats allocation.
Untagged spend: Untagged spend is cloud cost on resources missing the tags needed to attribute it to a team, product or environment. It is the gap left by incomplete tag coverage: money that lands on the bill with no owner, so it cannot be shown back, charged back or held to account.
Shared costs: Shared costs are cloud charges that no single team caused alone, such as networking, shared clusters, support fees or central tooling. To allocate them you split the cost across consumers using a chosen key (usage, headcount or an even share), so allocation stays complete rather than leaving a large unattributed remainder.
Cost driver: A cost driver is the resource, service or behaviour responsible for a movement in spend, for example a new data-pipeline job, a traffic spike or a new region. Allocation tells you where cost landed; identifying the cost driver tells you what moved it, which is the step that turns a number on the bill into something you can act on.
Unit economics: Unit economics is the practice of expressing cloud cost per unit of business value (cost per customer, per order, per GB delivered) so spend can be judged against what it produces rather than in absolute pounds. It connects engineering cost to business output, which lets teams see whether growing spend is actually buying proportionate growth in value.
Cost per unit: Cost per unit is the actual metric behind unit economics: total relevant cloud cost divided by a chosen business unit, such as cost per active user or per thousand requests. Tracking it over time shows whether spend is scaling efficiently, since rising total cost can still mean a falling, healthier cost per unit.

Billing, rates & pricing models

How cloud usage is priced and represented on the bill.

On-demand pricing: On-demand pricing is the standard pay-as-you-go rate charged per second or hour with no commitment, the most flexible option and the most expensive per unit. It is the baseline rate that discounts such as Savings Plans, Reserved Instances and Spot are measured against, so steady-state usage left on it is usually overpaying.
Blended rate: A blended rate is an averaged unit price AWS shows across all linked accounts in an organisation, smoothing each account's costs as if every account paid the same rate. It is useful for an overall view but can hide which account actually consumed the cheaper committed usage, so it is poor for accurate per-team allocation.
Unblended rate: An unblended rate is the actual rate charged to the specific account that incurred each line of usage, before any averaging across the organisation. It reflects what that account really paid, including its own discounts, and is the rate to use when allocating cost back to the team that caused it.
Amortised cost: Amortised cost spreads an upfront or recurring commitment charge evenly across the period it covers, so a one-year Reserved Instance or Savings Plan shows as a steady daily rate rather than a large lump on its purchase date. It gives a truer picture of ongoing run rate and makes month-to-month spend comparable.
Effective price: Effective price is the real per-unit cost you pay for a resource after every applicable discount is applied: commitments, Spot, credits and negotiated rates. Comparing it against the on-demand rate for the same usage shows how much your rate strategy actually saves, rather than what the headline list price suggests.
Spot instances: Spot instances are spare AWS compute capacity sold at a steep discount versus on-demand, on the condition that AWS can reclaim them at short notice. They suit fault-tolerant, interruptible work such as batch processing, CI and stateless workers, but not anything that cannot survive sudden termination. Right-size your compute
FOCUS (FinOps Open Cost and Usage Specification): FOCUS is an open, vendor-neutral standard for cloud billing data, defining common column names and definitions so cost exports from AWS, Azure and others share one schema. It lets a FinOps team analyse multi-cloud spend with a single set of queries instead of learning each provider's bespoke billing format.
Cost and Usage Report (CUR): The Cost and Usage Report is AWS's most detailed billing export, listing every usage line with its rates, discounts, tags and account, delivered to an S3 bucket. It is the authoritative source for cost allocation, amortisation and rate analysis, far richer than the console summaries, and the data most FinOps tooling is built on.
Data egress: Data egress is data leaving a cloud provider's network, typically to the internet or across regions, and it is metered and charged per gigabyte. Ingress is usually free while egress is not, so it can become a large, surprising line on the bill, especially for cross-region traffic and high-volume downloads. Trim your network spend
Payer account: A payer account is the management account at the top of an AWS Organization (or the billing account in Azure) that receives the consolidated bill for every linked account. Commitments and volume discounts pool across the organisation through it, and it is where consolidated billing data and the Cost and Usage Report are produced.

Commitments & rates

Paying a lower rate for steady-state usage, and the metrics that say whether it is working.

Commitment: A commitment is an agreement to pay for a baseline of cloud usage over one or three years in exchange for a lower rate. On AWS these are Reserved Instances and Savings Plans; on Azure, Reservations and savings plans. The trade is flexibility for price: you give up some freedom to change in return for a discount. Lock in your commitments
Reserved Instance (RI): A Reserved Instance is a one- or three-year AWS commitment to a specific instance configuration (family, size and region) in return for a discount versus on-demand pricing. Because it is tied to a fixed shape, it gives up flexibility for a deeper rate, so it suits workloads whose size and location you do not expect to change.
Savings Plan (SP): A Savings Plan is a flexible AWS commitment to a steady amount of compute spend, measured in US dollars per hour, applied automatically across eligible usage for a lower rate. Unlike a Reserved Instance it is not tied to one instance shape, so the discount follows your workload as it changes rather than stranding a fixed reservation.
Compute Savings Plan: A Compute Savings Plan is the most flexible AWS Savings Plan: you commit to a fixed amount of compute spend per hour for one or three years and the discount, up to roughly 66% off on-demand, applies automatically across any EC2 instance family, size, region and operating system, plus Fargate and Lambda. You pre-purchase a rate, not a specific instance. Compute Savings Plans, step by step
Azure Reservation: An Azure Reservation is a one- or three-year commitment to a specific resource type (for example a virtual machine series, size and region) in return for a discount versus pay-as-you-go pricing. It is the Azure equivalent of an AWS Reserved Instance: tied to a fixed shape, so it trades flexibility for a deeper rate on steady-state workloads.
Azure savings plan: An Azure savings plan (for compute) is a one- or three-year commitment to a fixed amount of compute spend per hour, billed at a discounted savings plan rate instead of full pay-as-you-go. Like an AWS Savings Plan, it applies across eligible compute (virtual machines, App Service, Container Instances and more) rather than locking you to one VM size or region. Lock in Azure commitments
Coverage: Coverage is the percentage of eligible on-demand spend that your commitments actually cover. Low coverage means you are paying full on-demand rates for steady-state workloads that could be discounted. It is one of the two numbers, alongside utilisation, that show whether you are under- or over-committed.
Utilisation: Commitment utilisation is the percentage of a commitment you actually use. Low utilisation means you have over-committed and are paying for discounted capacity that sits idle, which can wipe out the saving the commitment was meant to deliver. Read it alongside coverage: one guards against under-committing, the other against over-committing.
Effective Savings Rate (ESR): Effective Savings Rate is the blended discount your commitments really deliver: total savings as a percentage of what the same usage would have cost at on-demand rates. It nets off the waste from any unused commitment, so it is the single number that says whether your rate strategy is actually working, not just how much you bought.
Commitment-based discount: A commitment-based discount is a lower rate earned by promising a baseline of usage or spend over a fixed term, such as a Reserved Instance, Savings Plan or Azure Reservation. It is the rate lever of the FinOps Optimize phase, distinct from usage optimisation like rightsizing or deleting waste, which changes what you run rather than the price you pay for it.

Cost optimisation & waste

Finding and removing waste, matching spend to what you actually run, and proving the saving landed.

Rightsizing: Rightsizing matches a resource's size to what it actually uses, for example moving an over-provisioned EC2 instance to a smaller type, so cost falls without hurting performance. It works on compute, databases and other sized resources, and is judged against real utilisation rather than the size someone picked at launch.
Idle resources (waste): Idle or wasted spend is money going to resources that are provisioned but doing nothing: unattached EBS volumes, idle load balancers, orphaned IP addresses. It is usually the fastest saving to realise, because deleting something nothing depends on carries little performance risk.
Cost anomaly detection: Cost anomaly detection learns the normal shape of your daily spend, builds an expected band around it, and flags any day that falls outside that band. Unlike a fixed budget threshold, the baseline adapts as usage grows, so a runaway resource or misconfigured job is caught within days instead of at the month-end invoice. Cloud cost anomaly detection
Forecast: A cloud forecast projects month-end or future spend from current usage and trends, so a budget can be defended before the bill lands rather than explained after it. Forecast accuracy (how close the projection sits to the actual) is itself worth tracking, because a forecast nobody trusts cannot guide a decision.
Budget: A budget is a planned spend limit for an account, team or service over a period, used to compare actual cost against intent and to trigger an alert when usage tracks toward a breach. Unlike anomaly detection it is a fixed target you set, so it captures business intent rather than a statistical baseline.
Storage lifecycle: A storage lifecycle is a policy that automatically moves or expires data as it ages, for example transitioning S3 objects to cheaper storage classes after a set number of days, then deleting them once retention ends. It cuts the storage bill without anyone manually tidying buckets, matching the storage class to how often data is actually read.
Autoscaling: Autoscaling adds and removes capacity automatically in response to demand, so you run enough resources to serve current load and no more. By scaling down in quiet periods it keeps spend tracking actual usage rather than a fixed peak, and it suits workloads whose demand varies through the day or week.
Instance scheduling: Instance scheduling stops and starts resources on a timetable, typically shutting down non-production compute outside working hours and at weekends. For workloads nobody uses overnight it removes a large block of avoidable cost with no impact, since the resource is simply switched off when it would otherwise sit idle.
Cost Optimization Score: Cost Optimization Score is emnode's single number blending two measures, weighted evenly: your waste ratio (identified savings as a share of total spend) and your realisation rate (how much of what you identify becomes verified savings). It answers how wasteful spend is today and how well you act on it, trended over time and broken down by team across AWS and Azure. The Cost Optimization Score
Savings realisation rate: Savings realisation rate is the percentage of identified savings that you actually realised over a period: realised savings divided by identified savings across the same window. It cannot be gamed by turning up recommendation sensitivity, so it is the clearest single answer to whether a cost programme is working. Mature programmes tend to push toward 70% and above. What is savings realisation rate
Identified vs verified savings: Identified savings is the total of every opportunity your tooling finds: potential cost that could come off the bill if every recommendation were actioned. Verified savings is what actually landed, confirmed against the real bill after a validation window once the change is live. Reporting them separately keeps the number you take to leadership one you can defend.

Compliance & security posture

Measuring cloud security posture continuously and fixing what matters first.

Compliance posture: Compliance posture is how well your cloud configuration meets a security framework's controls at a point in time, expressed as a score and a ranked list of findings rather than a once-a-year pass or fail. Tracked continuously, it shows whether you are getting more secure or less, account by account. Compliance in emnode
Finding: A finding is a single detected deviation from a control, for example an unencrypted volume or a publicly readable bucket. Each one carries a severity from critical to low that determines how urgently it should be fixed, and stays open until the underlying resource is brought back into line.
Severity: Severity is the rating a finding carries (critical, high, medium or low) that signals how much risk it represents and how urgently it should be fixed. Normalising severity across providers and frameworks lets a critical on AWS be compared with one on Azure, so noise sits below signal.
Remediation: Remediation is the work of fixing a finding so the resource meets its control again, for example enabling encryption or removing public access. It is the step that actually improves posture: a finding raised but never remediated leaves the underlying risk in place no matter how it is reported. Controls and their fixes
MTTR (Mean Time To Resolve): Mean Time To Resolve is the average time between a finding being raised and remediated. It measures how quickly issues actually get fixed, not just how many exist. Reported alongside SLA-met percentage, often as a median, it tells you whether your remediation queue is draining or quietly growing.
Remediation SLA: A remediation SLA is the target time to fix a finding of a given severity, for example criticals within 7 days and highs within 30. SLA-met percentage shows whether the team is hitting those targets, turning a posture score into a commitment that holds up in an audit or board pack. Findings to owned actions
Control: A control is a single security rule that a resource is checked against, for example "S3 buckets should block public access" or "RDS instances should be encrypted at rest". Frameworks are made of controls; each check passes or fails per resource, and a failure becomes a finding to remediate.
Encryption at rest and in transit: Encryption at rest protects stored data (disks, databases, object storage, backups) so it is unreadable without the key; encryption in transit protects data moving over the network using TLS. Both are among the most common controls in any security framework, which is why an unencrypted volume or database is such a frequent, high-severity finding. Encrypt everything
CSPM (Cloud Security Posture Management): Cloud Security Posture Management is the practice of continuously checking cloud configuration against security frameworks, surfacing misconfigurations as findings, and tracking them to remediation. Rather than a point-in-time audit, CSPM keeps posture under constant watch so drift and new exposure are caught within days.
AWS Security Hub: AWS Security Hub is AWS's native service that aggregates security findings and runs configuration checks against standards such as Foundational Security Best Practices and the CIS AWS Foundations Benchmark. It is the source of truth emnode reads from for AWS posture, normalising and weighting its findings into one trended score.
Microsoft cloud security benchmark (MCSB): The Microsoft cloud security benchmark is Microsoft's baseline of security controls for Azure, organised into domains such as Network Security, Identity Management and Data Protection. Microsoft Defender for Cloud assesses resources against it, and emnode cross-references each Azure recommendation to its MCSB control and a remediation step. Azure controls and MCSB
CIS Benchmark: A CIS Benchmark is a set of configuration recommendations from the Center for Internet Security that define a secure baseline for a platform. The CIS AWS Foundations Benchmark is widely used because it also underpins SOC 2, ISO 27001 and HIPAA scoping, and AWS Security Hub can score against it directly.
Least privilege: Least privilege is the principle that every identity, whether a user, role or service, should hold only the permissions it genuinely needs, and no more. It limits the blast radius of a compromised credential and is the foundation of access controls in both AWS IAM and Azure RBAC. Lock down access

Reliability & disaster recovery

Knowing your data would actually recover, measured continuously rather than at audit time.

DR posture: Disaster recovery posture is a continuously scored view of whether your data would actually recover (backup coverage, job success, retention and cross-region copies) rather than a snapshot from the last audit. DR in emnode
RPO and RTO: Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time; Recovery Time Objective (RTO) is how long recovery may take before the business is hurt. Both are set per workload, and a backup plan is only adequate when its schedule meets the RPO and its restore speed meets the RTO.
Backup coverage: Backup coverage is the share of in-scope resources that sit inside a governed backup plan. The gap is the set of resources with no recoverable copy when one is needed, and those are exactly the things you cannot restore after an accidental deletion, a ransomware event or a region loss, so coverage is tracked as a percentage with the gap named explicitly.
Region and Availability Zone: A region is a geographic location where a cloud provider runs data centres; an Availability Zone is one isolated data-centre group within a region, with its own power and networking. Spreading across zones survives a single data-centre failure; spreading across regions survives a whole-region outage, which is why both underpin cross-region replication and failover.
Cross-region replication: Cross-region replication keeps a copy of your data in a second region or account, so a single region having a bad day does not wipe out the only copy. It bounds your blast radius: without it, a region-level failure can leave nothing to recover from.
Retention policy: A retention policy is how long each backup or recovery point is kept before it is aged out and deleted. Set it too short and corruption that surfaces weeks later has already overwritten every clean copy; it is judged against your recovery-point targets per environment.
Point-in-time recovery (PITR): Point-in-time recovery is the ability to restore data to any moment within a retention window, rather than only to discrete backup snapshots. It limits data loss when a fault, bad deployment or accidental write needs unwinding to just before it happened, often to the second.
Snapshot: A snapshot is a point-in-time copy of a disk, database or volume, taken so the data can be restored to how it looked at that moment. Snapshots are the artefact most backup plans schedule and retain, but forgotten ones also accumulate as silent storage cost, which makes them a common overlap between disaster recovery and waste.
Versioning: Versioning keeps previous copies of an object each time it is overwritten or deleted, so an accidental or malicious change can be rolled back to an earlier version. On S3 it turns a destructive overwrite into a recoverable one, but only for changes made after it was switched on.
Failover: Failover is the switch from a failed primary to a standby copy (a replica, second region or alternate origin) so a service keeps running through an outage. It is only real if the endpoint actually moves and clients follow it, which is why it should be tested rather than assumed.
Resilience: Resilience is a system's ability to keep working, or recover quickly, when part of it fails: a zone, a region, a dependency or a bad deployment. It is built from redundancy, backups, failover and tested restores, and measured by behaviour on the bad day rather than by configuration on a good one. Build in resilience

Monitoring & observability

Knowing the right things are watched, and how well.

Monitoring maturity: Monitoring maturity is a weighted score of how well your estate is actually watched (alarm posture, alarm history and coverage) trended over time, not just whether monitoring is switched on. Monitoring in emnode
Alarm coverage: Alarm coverage is the share of resources that have at least one alarm attached, measured against the resources that ought to have one. It exposes assets that went live with nothing watching them, the blind spots where a failure would pass unnoticed. High coverage matters less than coverage of the right metrics, so it is read alongside whether each alarm actually fires on real problems.
Alarm: An alarm is a rule that watches a metric against a threshold and changes state (OK, ALARM or INSUFFICIENT_DATA) when the condition is met, so a problem is flagged automatically. In AWS this is a CloudWatch alarm; in Azure, a metric or log alert. An alarm that never fires, or always fires, is watching nothing useful.
Metric: A metric is a numeric measurement of a resource sampled over time, such as CPU utilisation, request count or queue depth. Metrics are what alarms evaluate and what dashboards plot. They tell you how something is behaving, but on their own they do not explain why.
Log: A log is a timestamped record of an event, such as an access request, an error or an API call, written by a service as it runs. Logs give the detail behind a metric or alarm: who did what, when and with what result. CloudTrail and flow logs are common examples. Enable CloudTrail logging
Observability: Observability is the degree to which you can understand a system's internal state from its outputs: metrics, logs and traces. Good observability lets you answer questions you did not anticipate when an incident happens, rather than only confirming the few conditions you thought to alarm on in advance.
SLO (Service Level Objective): A Service Level Objective is a target for how reliable a service should be over a period, for example 99.9 percent of requests served in under 200 milliseconds each month. It sets the agreed bar that monitoring measures against and that an error budget is derived from.
SLI (Service Level Indicator): A Service Level Indicator is the actual measurement used to judge an SLO, for example the proportion of requests that succeeded within the latency limit. The SLI is the number you observe; the SLO is the target you hold it to. A good SLI reflects what users actually experience.
Notification (alerting): A notification is the message sent to a person or system when an alarm changes state, by email, chat, SMS or an incident tool. Alerting is the wider practice of routing the right notification to the right owner. Too many notifications cause alert fatigue, so the goal is signal, not volume.

The emnode platform

The concepts emnode uses to turn findings into verified outcomes across cost, compliance, reliability and monitoring.

Action Hub: The Action Hub is emnode's single queue for every finding across cost, compliance, anomaly, monitoring and reliability. Each item carries its monthly impact or risk, gets claimed by an owner and moves through five lanes (Inbox, In Progress, To Validate, Complete, On Hold) until it is verified. emnode is read-only, so it surfaces the recommended action but nothing changes in your cloud without a person acting. See the Action Hub
Progress reporting: Progress reporting is emnode's pipeline view of every finding from identified to verified, showing pipeline value, verified savings, claim rate and stale-item alerts. Sub-views cover the savings funnel, month-on-month trend, ownership (including an Unowned bucket) and throughput per stage. It answers "where are we?" at a glance and feeds the same numbers into the monthly review. See progress reporting
Daily digest: The daily digest is a short, per-user email emnode sends each morning, built to read on a phone before standup. It uses the same three blocks every day: a KPI overview, the action queue of new versus resolved items, and commitments and budgets with a plain-English advisory when a budget crosses its threshold, plus a link into the live dashboard. It covers both AWS and Azure.
Monthly review: A monthly review is the auto-generated FinOps deck emnode builds from your live account data: spend, budgets, open and verified savings, commitments, compliance, DR and monitoring across a fixed eleven-section agenda. It shares as a link your team opens in the browser, comes in finance, engineering and leadership cuts, and feeds decisions back into the Action Hub as owned items.
Realisation lifecycle: The realisation lifecycle is the path emnode runs every finding through, from identified to claimed, completed and finally verified, so a recommendation becomes a result rather than a row in a report. Identified savings is the forecast; verified savings is what actually came off the bill. Tracking the full lifecycle is what closes the gap where most cost programmes quietly leak value. The identified vs realised gap
Finding owner: A finding owner is the single named person who has claimed an Action Hub item and is accountable for working it to done. emnode assigns ownership to a person, not a team, because a recommendation owned by "the platform team" is owned by no one. Anyone can claim, reassign with a comment or defer with a reason, and every action is captured in the audit trail.
Validation window: A validation window is the period emnode waits after a change lands before confirming the saving or fix is real, measuring the actual impact against your bill rather than the estimate attached when the item was raised. It is why an item sits in the To Validate lane: savings are reported as verified, not assumed, once the spend has settled at its new level.
Suppression: Suppression is deferring or dismissing a finding with an explicit reason, so the Action Hub queue reflects real priorities instead of noise. Deferred items move to the On Hold lane and resurface automatically rather than vanishing, so a conscious "not now" cannot quietly become "never". Every suppression is recorded in the audit trail, keeping the decision visible and reversible.

Want the lessons behind the terms?

Browse the library