We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).

However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.

We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).

However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.

@mike-finopsorg

100%. The goal is to expose what is eligible for coverage by commitments, because it's hard enough figuring out what is/is not eligible. We should definitely clarify that we're not giving an opinion on a coverage strategy based on aspects like target rates, on-demand fluctuation percentages, or similar.

I envision people doing roughly the following:

1. Determining their coverage percentage.

(SELECT SUM(ChargePeriodEnd - ChargePeriodStart) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory = 'Used') 
/
(SELECT SUM(ChargePeriodEnd - ChargePeriodEnd) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory IN ('Used', 'On-Demand'))
* 100

2. If above coverage rate target, query rows (or rollups), drill down further into coverage rates above where coverage is higher than expected.

3. If below coverage rate target, query rows (or rollups) with on-demand spend with a CommitmentDiscountCategory value to determine what to do next.

SELECT * FROM <table> WHERE ChargeCategory = 'Usage' AND ChargeSubCategory = 'On-Demand' AND CommitmentDiscountCategory IS NOT NULL

Summary TF-2 call on Oct 16:

#406 Add Commitment-Based Coverage Column
Key Discussion Items: Adding a column to identify rows that are, or could be, covered by a commitment-based discount.
Problem Identification: It is difficult to determine which specific SKUs are eligible for commitment-based discounts.
Divergent Views: Some participants mentioned this issue was of lower priority, while others believed it was important for commitment utilization.
Final Agreement: Chris will create a work item for this, with further refinement needed for different providers.
Action Items:

• TF-2-[#406] Chris, @cnharris10 was assigned the task of creating the work item.

@aqu-erp to produce the work item for this issue

@aqu-erp @cnharris10 As the first authors to have completed a Work Item, you have become our guinea pigs for the process! So please bear with me as we work through a few items that come to mind, now that we see the issue fully fleshed out. I'd love to use this issue as our main example for other Work Item authors to reference as we move forward. So, to that end:

• Could you please rename the issue in a way that is more conceptual than solution-oriented?
  • For example, instead of saying we're going to add a column (which we may very well do), I believe it would be helpful to make clear that we will address a particular idea. Perhaps Add support for commitment eligibility or Add support for coverable spend or something along those lines. Maybe that seems like a small change, but I think it will be very helpful when it comes time to explain to our stakeholders.
• Section 1: could you please add at least one use case?
  • Several come to mind, but perhaps the easiest and most elucidating for the average practitioner might be Report coverage % across all resources and services. Ideally following the format as listed in the use case library here.
• Section 1: In the problem statement, perhaps we keep it more grounded in the world of FOCUS?
  • For example, perhaps we go farther than "non-trivial" and say something like coverage % is not possible to calculate in FOCUS because spend that is eligible for coverage is not tracked. If the practitioner is using FOCUS exclusively, it's straight-up impossible to calculate coverage % without external enrichment. I think making this statement helps clarify why this is important to do, rather than just let the practitioner deal with it downstream.
• Section 4: is this at all a datapoint that you've seen any data generator provide? Some verbiage that touches on whether this is a known field will be helpful for future discussions. My understanding is that this is not an exposed field in any of the CSP exports; is this also your understanding?

I super appreciate you assembling this!

@aqu-erp @cnharris10 As the first authors to have completed a Work Item, you have become our guinea pigs for the process! So please bear with me as we work through a few items that come to mind, now that we see the issue fully fleshed out. I'd love to use this issue as our main example for other Work Item authors to reference as we move forward. So, to that end:

• Could you please rename the issue in a way that is more conceptual than solution-oriented?

  • For example, instead of saying we're going to add a column (which we may very well do), I believe it would be helpful to make clear that we will address a particular idea. Perhaps Add support for commitment eligibility or Add support for coverable spend or something along those lines. Maybe that seems like a small change, but I think it will be very helpful when it comes time to explain to our stakeholders.

• Section 1: could you please add at least one use case?

  • Several come to mind, but perhaps the easiest and most elucidating for the average practitioner might be Report coverage % across all resources and services. Ideally following the format as listed in the use case library here.

• Section 1: In the problem statement, perhaps we keep it more grounded in the world of FOCUS?

  • For example, perhaps we go farther than "non-trivial" and say something like coverage % is not possible to calculate in FOCUS because spend that is eligible for coverage is not tracked. If the practitioner is using FOCUS exclusively, it's straight-up impossible to calculate coverage % without external enrichment. I think making this statement helps clarify why this is important to do, rather than just let the practitioner deal with it downstream.

• Section 4: is this at all a datapoint that you've seen any data generator provide? Some verbiage that touches on whether this is a known field will be helpful for future discussions. My understanding is that this is not an exposed field in any of the CSP exports; is this also your understanding?

I super appreciate you assembling this!

Added additional information based on most points above including a title change, use-case, and section 4

Big support for this one as we have folks at Capital One whose primary duties are optimizing CUD and planning future purchases by analyzing coverage and utilization. I believe this feature will help out in that regard.

Notes from the Maintainers' call on November 4:

Context: This item seeks to track costs eligible for commitments (like Reserved Instances) to help practitioners accurately calculate coverage KPIs. Coverage metrics are essential in understanding and managing commitment utilization in cloud environments.
Level of Effort Required: Medium — Supporting commitment-eligible cost tracking is moderately complex, requiring integration across providers with different commitment models.
Level of Impact: High – Commitment-eligible cost tracking is critical for calculating coverage KPIs, which are core metrics in FinOps. This feature helps practitioners monitor commitment utilization, improving budget planning and resource allocation.

nit: Should we rename this to "commitment discount eligibility"?