[FR] Add non-negotiated discount eligibility indicator for on-demand charges

### Problem Statement
It is a non-trivial task to determine whether an on-demand usage-based charge is eligible for a commitment (and which commitment) or not.

Commitment discount efficiency and rate optimization analysis is inaccessible or unachievable for practitioners with a provider-native dataset, without joining additional data or context. This adds undue overhead to computation of commitment coverage and undermines decision-making capability, particularly around purchases and renewals.

**Real-World Impact:**

- Optimization recommendations require context-switching between FOCUS data and provider consoles
- Organizations with multi-cloud strategies must learn different eligibility models per provider
- Effective savings rate (ESR) calculations require joining FOCUS Cost and Usage to external datasets
- Practitioners cannot exclude non-eligible resources from optimization analysis

**Why Existing FOCUS Capabilities Are Insufficient:**
- `CommitmentDiscountCategory` tells you what discount was applied, not what could be applied
- `ChargeCategory` identifies on-demand charges but not their eligibility characteristics
- No standardized way to identify which SKUs support commitment discounts across providers
- SKU-level analysis impossible without eligibility metadata

Ties to [Analyze resource costs by SKU](https://focus.finops.org/use-cases/?prod_use_cases%5BrefinementList%5D%5Brelated_personas.post_title%5D%5B0%5D=FinOps%20Practitioner&prod_use_cases%5BrefinementList%5D%5Brelated_personas.post_title%5D%5B1%5D=Finance#modal-column-14595) in the use case library.

---
### Use Case

#### Primary Use Cases (FinOps Practitioner)

- **As a** FinOps Practitioner, **I want to** know whether an on-demand usage charge is eligible for a commitment discount, **so I can** accurately assess and optimize my coverage and spend.
-  **As a** FinOps Practitioner, **I want to** identify which specific commitment program(s) a usage charge is eligible for, **so I can** make informed purchase and renewal decisions.
-  **As a** FinOps Practitioner, **I want to** analyze resource costs by SKU with commitment eligibility indicators, **so I can** compute accurate commitment coverage and utilization metrics.
-  **As a** FinOps Practitioner, **I want to** determine which resources or services are **not** commitment-eligible, **so I can** exclude those resources/services and focus optimization efforts where they will have impact.
-  **As a** FinOps Practitioner, **I want to** determine my effective savings rate, **so I can** track my savings opportunities (e.g., how optimized am I at any given point in time).

#### Secondary Use Case (Tooling Vendor)

**As a** FinOps tooling vendor, **I need** standardized eligibility indicators in FOCUS data, **so that** I can build provider-agnostic optimization recommendation engines without maintaining separate eligibility logic per cloud provider.

#### Acceptance Criteria (High-Level)

These criteria will translate directly into normative requirements:
- **Eligibility Indicator Present:** FOCUS includes a standardized indicator that identifies whether an on-demand charge is eligible for commitment discounts
- **Eligibility Type Clarity:** When eligible, FOCUS indicates the type(s) of commitment programs that could apply (e.g., Compute Savings Plan, Reserved Instance, CUD)
- **SKU-Level Granularity:** Eligibility can be determined at the SKU level to enable detailed resource cost analysis
- **Non-Eligible Identification:** Practitioners can explicitly identify charges that are NOT eligible for any commitment program (enabling exclusion from optimization analysis)
- **Cross-Provider Consistency:** The indicator is consistently populated across all providers that offer commitment discount programs
- **Customer-Scenario Focus:** Eligibility reflects what the customer could act on in their current scenario, not all theoretical possibilities
- **Null Handling:** Clear semantic definition for when eligibility is null/empty (service doesn't support commitments vs. data unavailable vs. already covered)
- **Hypothetical vs. Real Separation:** Eligibility data remains informational and does not mix hypothetical costs with actual costs (addresses qquigley's concern from May 27 comment)

---

### Supported Feature Alignment

#### Current State Assessment

[ ] **Enhances existing feature: Commit Usage and Under Usage**
   - **Current Gap:** Feature tracks commitment usage and under-usage but doesn't identify which on-demand charges are eligible for commitments, forcing practitioners to use external tools or provider consoles for optimization analysis
   - **Needed Capability:** Practitioners need to identify which on-demand charges could be covered by commitments to calculate coverage rates, effective savings rates, and make informed purchase decisions

[ ] **Introduces new feature:**
   - **Decision pending working group:** Depending on solution approach (simple boolean vs. detailed eligibility metadata), this may warrant a distinct "Commitment Optimization" or "Commitment Coverage Analysis" capability or may be addressed through enhancement to existing commitment tracking

#### Approach A: Enhance Existing "Commit Usage and Under Usage" Feature

##### Enhancement to Feature
**Current Feature Description:**
> FOCUS supports the tracking of commitment discounts usage and under usage, which can come in the form of commitment discounts or capacity reservations.

**Draft Enhancement - Revised Description:**
> FOCUS supports the tracking of commitment discounts usage and under usage, which can come in the form of commitment discounts or capacity reservations. **FOCUS also enables practitioners to identify which on-demand charges are eligible for commitment discount programs, supporting optimization analysis, coverage calculations, and effective savings rate tracking without requiring external tools or provider-specific eligibility logic.**

**Draft Enhancement - Add to Directly Dependent Columns:**
* CommitmentDiscountId
* CommitmentDiscountStatus
* CommitmentDiscountType
* CapacityReservationId
* CapacityReservationStatus
* CapacityReservationType
* **CommitmentEligibility** (add - proposed new column or attribute indicating eligibility)

**Draft Enhancement - Add to Supporting Columns:**
* BilledCost
* ChargePeriodStart
* ChargePeriodEnd
* EffectiveCost
* ServiceCategory
* **SkuId** (add - for SKU-level eligibility analysis)
* **PricingCategory** (add - for distinguishing on-demand vs. committed pricing)
* **ChargeCategory** (add - for focusing on Usage charges)

#### Approach B: New Standalone Supported Feature

##### Feature Name
**Commitment Coverage and Optimization Analysis**

##### Description

Enables practitioners to identify which on-demand usage charges are eligible for commitment discount programs, supporting optimization analysis, coverage rate calculations, and effective savings rate (ESR) tracking. Practitioners can analyze eligible spend by SKU, identify non-eligible resources to exclude from optimization efforts, and make data-driven decisions about commitment purchases and renewals without requiring provider-specific tools or external datasets.

##### Directly Dependent Columns

* CommitmentEligibility (proposed - indicates eligibility status and program types)
* ChargeCategory
* PricingCategory
* SkuId

##### Supporting Columns

* BilledCost
* EffectiveCost
* CommitmentDiscountId (for analyzing currently covered charges)
* CommitmentDiscountStatus (for correlating with eligibility)
* ServiceName
* ServiceCategory
* ResourceId
* ResourceType
* ChargePeriodStart
* ChargePeriodEnd

##### Enabled Capabilities

**Coverage Analysis:**
- Calculate commitment coverage rates (% of eligible spend covered)
- Identify coverage gaps by service, SKU, or resource
- Track coverage trends over time

**Optimization & Savings:**
- Calculate effective savings rate (ESR) from existing commitments
- Identify optimization opportunities (eligible but uncovered spend)
- Prioritize commitment purchases based on eligible spend patterns
- Exclude non-eligible resources from optimization recommendations

**Purchase & Renewal Decisions:**
- Analyze eligible spend by commitment program type
- Understand which SKUs support which commitment types
- Make informed decisions about commitment types and coverage levels
- Right-size commitment purchases based on actual eligible usage

**SKU-Level Analysis:**
- Perform detailed resource cost analysis with eligibility context
- Identify high-spend eligible SKUs for optimization focus
- Understand eligibility restrictions and exclusions by SKU

##### Introduced (Version)
1.4 (proposed)

#### Comparison of Approaches

| Aspect | Approach A: Enhance Existing | Approach B: New Feature |
|--------|------------------------------|-------------------------|
| **Discovery** | Practitioners find eligibility within commitment tracking | Dedicated feature makes optimization capabilities highly visible |
| **Feature Count** | Lower (1 enhanced feature) | Higher (1 new + existing commitment features) |
| **Conceptual Clarity** | Eligibility is part of overall commitment lifecycle | Clear separation: tracking (applied) vs. optimization (eligible) |
| **Column Dependencies** | Mixes applied and eligible commitment columns | Separates eligibility columns from application columns |
| **Use Case Focus** | Combined view of actual and potential commitments | Focused on optimization and coverage analysis |

---

### 🎯 Desired Outcome / Practitioner Impact
#### Primary Outcomes
- **Practitioners can discern commitment eligibility of a charge** directly from FOCUS data without external tools
-  **Practitioners can identify type of commitment eligibility** to make informed purchase decisions
-  **Practitioners can calculate effective savings rate (ESR)** using only FOCUS data
-  **Practitioners can perform SKU-level optimization analysis** with eligibility context
-  **Practitioners can exclude non-eligible resources** to focus efforts on actionable opportunities

#### Practitioner Impact by Persona

**FinOps Practitioners:**
- Direct visibility into optimization potential during cost allocation analysis
- Ability to prioritize commitment purchases based on actual eligible spend
- Track optimization coverage metrics (% of eligible spend covered by commitments)
- Exclude non-eligible resources from coverage calculations
- Make data-driven decisions on commitment types and coverage levels

**Data Engineers:**
- Eliminate custom eligibility logic and provider-specific API calls
- Reduce ETL complexity for commitment optimization workflows
- Build provider-agnostic workflows to support ESR tracking
- SKU-level analysis without additional data sources

**Finance Teams:**
- Improved forecast accuracy by understanding commitment potential
- Better variance analysis when actual vs. potential commitment savings tracked
- Clearer business cases for commitment purchases

**Tooling Vendors:**
- Build optimization features without needing to maintain provider-specific eligibility mappings
- Offer consistent recommendation experiences across customer providers (e.g., Public Cloud & SaaS)
- Reduce development overhead for multi-cloud support

---

### 📨 Type of Request

- [ ] Refinement of an existing FOCUS attribute
- [x] Addition of a provider-supported field not yet in FOCUS (Providers have eligibility logic but not in cost/usage exports)
- [x] Net-new concept (not currently supported by providers or FOCUS)

**Rationale:** While providers have eligibility logic in recommendation engines and expose coverage metrics in native tools, they don't currently include eligibility indicators in cost and usage data exports. FOCUS would be establishing a new practice of including this metadata in the standard data set.

**Provider Context:**
- SKU eligibility for discounts is a known property by providers
- Some SKUs are eligible for multiple types of commitments
- CSP providers do not expose coverage eligibility dimension in cost/usage datasets
- CSP providers do expose coverage metrics within native cost management tools

---

### 🏛️ Organizations Requesting or Supporting This Feature

- Datadog | @cnharris10 
- Atlassian
- Acuity, Inc. | @jesseadams
- StoneCo
- USU GmbH
- Workday 
- Twilio | @ljadvey
- ExxonMobil
- Broadcom 

---

### 🌐 FinOps Scope Alignment (Optional)

- [x] Public Cloud – AWS, Azure, GCP, etc.
- [x] SaaS – Salesforce, Snowflake
- [ ] Data Center
- [ ] Licensing *(under development)*
- [ ] AI *(under development)*
- [ ] Custom *(under development)*

---

### 📊 Impacted Parties

- [x] FinOps Practitioner
- [x] FOCUS Data Generator
- [x] Vendor Supporting FOCUS
- [ ] Other (please explain in comments)

---

### 🌫️ Level of Ambiguity

How clearly defined is the request? Rate from 1 to 5:
- 1 = very well-defined, low complexity
- 3 = moderately scoped, some ambiguity
- 5 = vague, high complexity or conceptual

3 (reflects progress from 1.3 while acknowledging additional remaining decisions to be made)

**Reasoning:**
**Factors Reducing Ambiguity (vs. initial assessment):**
- Extensive ideation work completed in July 2025 TF-1
- Scope clarified August 26, 2025: non-negotiated commitments in general
- Community discussion established boundaries (hypothetical vs. real costs)
- Provider examples documented showing restriction patterns
- Multiple organizations with validated use cases

**Remaining Complexity:**
1. **Semantic Challenges:**
   - Distinguishing "commitments" from "discounts" requires glossary alignment
   - Capacity reservations are commitments without discounts (edge case)
   - "Eligibility" has multiple interpretations (theoretical vs. customer-actionable)

2. **Implementation Questions:**
   - Binary flag vs. detailed eligibility information (JSON approach suggested)
   - How to represent usage already covered by one commitment but eligible for another
   - Handling overlapping eligibility (multiple commitment types)
   - Representing partial eligibility or restrictions

3. **Cross-Provider Variations:**
   - Different commitment products with different eligibility rules
   - Varying granularity (service-level vs. SKU-level vs. instance-family-level)
   - Provider-specific restrictions and exclusions

4. **Data Location:**
   - Cost/usage dataset vs. future pricing dataset
   - Integration with SKU-level analysis requirements

---

### 📂 Supporting Documentation

<summary>
Example restrictions across AWS, Azure, GCP
</summary>

1. AWS
    a. Spot instances
    b. [P5 instance family](https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/)
    c. [Mac instance families](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html#:~:text=Mac%20instances%20are%20available%20only%20as%20On%2DDemand%20Instances.%20They%20are%20not%20available%20as%20Spot%20Instances%20or%20Reserved%20Instances.%20You%20can%20save%20money%20on%20Mac%20instances%20by%20purchasing%20a%20Savings%20Plan.)
    d. [Ubuntu OS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-concepts-buying.html#:~:text=Ubuntu%20Pro%20is%20not%20available%20as%20a%20Reserved%20Instance)

2. Azure
    a. Spot VM's
    b. [VM series - A-series, Av2-series, or G-series](https://learn.microsoft.com/en-us/azure/virtual-machines/prepay-reserved-vm-instances?toc=%2Fazure%2Fcost-management-billing%2Freservations%2Ftoc.json#:~:text=VM%20series%20%2D%20A%2Dseries%2C%20Av2%2Dseries%2C%20or%20G%2Dseries.)

3. GCP
    a. Preemptible VM's
    b. [n1 shared-cost, or extended memory VM's](https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts#:~:text=Committed%20use%20discounts%20don%27t%20apply%20to%20preemptible%20VM%20instances%2C%20N1%20shared%2Dcore%20machine%20types%2C%20or%20extended%20memory.)

#### Related Issues
- [#406 - Add support for coverage eligibility](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/issues/406) (parent)
- [#1228 - Discuss and detail next steps](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/issues/1228) (sub-issue)

#### Reference Material
- [TF-1 Ideation Document](https://docs.google.com/document/d/1Q9DcEqZHmlPm94nkcGajNeHJj9W5CL7T/edit?usp=drive_link&ouid=105511592610552198421&rtpof=true&sd=true): July 15, 2025
- [TF-3 Meeting Minutes](https://github.com/FinOps-Open-Cost-and-Usage-Spec/meetings/blob/main/meetings/v1_4/FOCUS_TF-3_20251107_Minutes.md): November 7, 2025 (lines 116-302)

#### Community Discussion Highlights
**qquigley (May 27, 2025):**
> "If we're talking about a boolean that says 'this service does or does not have a commitment based discount program', then I support it. But if we're talking about multiple columns that say 'this service is eligible for a commitment based discount and here's what the cost of that usage would have been had you participated', then I think that gets muddy and could lead to tainted reporting unless we're very careful and deliberate on its implementation to separate the hypothetical numbers from the real numbers."

**shawnalpay (May 27, 2025):**
> "I envision a third path: a JSON column (or similar) giving you multiple booleans for all of the commitment discount programs for which the resource could have been eligible... The potential savings would still be up to the practitioner to calculate."

**Key Takeaway:** Solution must clearly separate informational eligibility data from hypothetical cost calculations.

---

### 🛠️ Proposed Solution / Approach

See v1.4 [Ideation doc for 958](https://docs.google.com/document/d/1glwXHxusZmtzRY22iOCBQl4eK-O4csPUedzaGckqH9Y/edit?tab=t.0#heading=h.lx8ccuw88pa)

---

### 💬 Community Support (Add Your Voice)

If your organization supports this request or has a similar use case:

- Add a **comment** below including:
  - Your **organization**
  - A **brief explanation** of why this is important to you (e.g., use case, urgency)
- FOCUS Staff & Maintainers will aggregate supporting orgs over time.

Aspect	Approach A: Enhance Existing	Approach B: New Feature
Discovery	Practitioners find eligibility within commitment tracking	Dedicated feature makes optimization capabilities highly visible
Feature Count	Lower (1 enhanced feature)	Higher (1 new + existing commitment features)
Conceptual Clarity	Eligibility is part of overall commitment lifecycle	Clear separation: tracking (applied) vs. optimization (eligible)
Column Dependencies	Mixes applied and eligible commitment columns	Separates eligibility columns from application columns
Use Case Focus	Combined view of actual and potential commitments	Focused on optimization and coverage analysis

[FR] Add non-negotiated discount eligibility indicator for on-demand charges #958

Description

Problem Statement

Use Case

Primary Use Cases (FinOps Practitioner)

Secondary Use Case (Tooling Vendor)

Acceptance Criteria (High-Level)

Supported Feature Alignment

Current State Assessment

Approach A: Enhance Existing "Commit Usage and Under Usage" Feature

Enhancement to Feature

Approach B: New Standalone Supported Feature

Feature Name

Description

Directly Dependent Columns

Supporting Columns

Enabled Capabilities

Introduced (Version)

Comparison of Approaches

🎯 Desired Outcome / Practitioner Impact

Primary Outcomes

Practitioner Impact by Persona

📨 Type of Request

🏛️ Organizations Requesting or Supporting This Feature

🌐 FinOps Scope Alignment (Optional)

📊 Impacted Parties

🌫️ Level of Ambiguity

📂 Supporting Documentation

Related Issues

Reference Material

Community Discussion Highlights

🛠️ Proposed Solution / Approach

💬 Community Support (Add Your Voice)

Sub-issues

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions