FOCUS Working Group / Release 1.5
Where the FOCUS 1.5 release stands across the whole specification: what the working group has confirmed, and what it is still stretching to include. Confirmed work is Core Scope. Stretch goals are Champion Scope. Within each, cards are sorted by how close the work is to shipping.
Core Scope — confirmed
On the 1.5 milestone. This work is confirmed for the release, and it is what the working group prioritizes between now and December.
#1057#2018, #1941#975#2358Champion Scope — stretch goals
Stretch goals for the 1.5 development cycle. Prioritized, but not confirmed for the release. The window to open new 1.5 work has closed, so this list no longer grows; an item moves into Core only if it clears review in time.
SkuPriceDetails.These four are what is still possible for 1.5. The full champion list lives on the champion board; the rest of it now carries into the next development cycle.
Core is confirmed; Champion is a stretch. Both are measured against the December 2026 release. Everything on this page assumes the work clears Task Force and member review before then.
FOCUS 1.4 is the current published version. The 1.5 working draft is being finalized now: it ratifies on 3 December 2026 and is announced publicly at the December Virtual Summit on 10 December. Everything below is sorted by how close it is to landing in that release. The working group runs its own interim review deadlines between now and then; those live in the repository rather than on this page.
No items match that filter.
Merged into the working draft. These ship in 1.5 unless something is pulled during the consistency review, which is rare. All are Core.
Cost data can now say which model was billed and who built it.
Four FOCUS-defined properties on SkuPriceDetails: ModelDeveloper, ModelFamily, ModelId, and ModelVersion. No new columns, and no change to the existing SkuPriceDetails requirements, so it is additive for every data generator. A worked appendix example ships alongside it, including the case practitioners get wrong today: a model resold by a cloud provider, where the service provider and the model developer are different companies.
This is the piece that makes multi-vendor AI spend comparable. Without it, an organization can say what it spent on models last quarter but cannot break that down by model without vendor-specific parsing.
A documented path from FOCUS 1.3 to 1.4 for anyone upgrading.
A migration guide covering the breaking changes between 1.3 and 1.4, the order in which to apply them, and phasing guidance for data generators who cannot move everything at once.
Version migration is where adoption stalls. A generator that cannot see, in one place, what changed and in what order tends to defer the upgrade. This removes that reason to wait.
The rules for when a column must appear now live in the spec itself.
Column-presence applicability criteria written directly into the specification, rather than only in the downstream Requirements Model. This started as a champion item and was promoted into Core.
When the rule for whether a column is required lives only in tooling, the spec and the validator can drift. Putting the criteria in the spec makes them authoritative and discoverable in the one place implementers already read.
User-defined tag keys are preserved as written in the Tags column.
Restores the requirement that a user-defined tag key is carried into the Tags column exactly as the customer set it, without provider-side normalization that would silently rename it.
Tag keys are how organizations attribute spend to teams and cost centers. If a provider rewrites the key, the customer’s allocation queries stop matching their own taxonomy.
A wider set of recommended unit formats, so quantities read consistently.
Expands the list of recommended UnitFormat values, giving data generators a common vocabulary for how quantities and units are expressed.
When two providers describe the same unit differently, practitioners normalize by hand. A shared recommended set narrows that variance without forcing a hard requirement.
Core work with a named owner and an open pull request moving through review. These are expected to be finalized ahead of the December 2026 release.
A published price catalog, carried independently of what was consumed.
Today a rate can only be reconstructed after an invoice arrives. There is no standard way to publish what a SKU costs before anyone buys it, or to compare that rate across providers.
A new SKU Price dataset that carries prices on their own. It is what lets an organization estimate the cost of something it has not consumed yet, and compare model or service rates across vendors before committing spend. The model-identity properties already merged describe a SKU price, so this is the dataset they were built for. Column naming is being settled in parallel.
This is the largest single piece of 1.5 and the difference between reporting on cost and negotiating it.
A standard shape for optimization recommendations across providers.
Every provider emits rightsizing, modernization, and commitment-purchase recommendations in its own format. A practitioner consuming them from more than one cloud has no common structure to build against.
A normalized Recommendations dataset so those actions arrive in one shape regardless of source. Promoted from champion scope, and now the second-largest piece of work in the release.
Worked examples for mapping AI billing into FOCUS.
The gap is not the schema. FOCUS already has the columns to carry token consumption. The gap is that practitioners cannot tell how those columns apply to AI billing, so every vendor gets normalized differently.
“every single one has a different data format”
Becky Canterbury, Shutterstock, on working with 20-plus AI vendors
Non-normative worked examples with backing datasets, scoped to already-defined FOCUS columns, including the prepayment drawdown pattern where capacity is bought up front and drawn down over time. Requested by NatWest, SLB, UK Government Digital Service, Shutterstock, Syngenta, Anglepoint, AWS, and the FinOps Foundation.
Cost rows can identify the person, service, or agent that drove the spend.
Actor and identity dimensions on the Cost and Usage dataset, identifying the actor behind a charge. The maintainers settled on a set of columns for this (a principal identifier plus related credential and detail columns) rather than a single field.
As spend shifts from provisioned infrastructure to per-call model invocations, the question changes from “which account owns this instance” to “which developer, team, or autonomous agent burned these tokens.” This is what makes that answerable inside billing data rather than by joining to observability.
Clearer guidance for splitting shared cost across consumers.
Improved split cost allocation guidance for data generators, including a new AllocatedServiceName column to name the service a split charge is allocated to. Foundational parts, including that column, have already merged; the remaining guidance is still in review.
Shared platform and container costs have to be divided among the teams that used them. Without consistent allocation guidance, two providers split the same shared cost differently and the numbers stop reconciling.
A revised set of allowed Service Category values.
Revises the ServiceCategory allowed values and the framing around them, continuing the move away from cloud-only assumptions so AI, SaaS, and on-premises spend classify cleanly.
Service category is the first cut most analyses make. A taxonomy that assumes everything is cloud misclassifies the growing share of spend that arrives from vendors who are not cloud providers.
Feature levels revised to make FOCUS more globally applicable.
Revisits the feature levels that say how strongly each column is required, so the requirements hold up across regions and billing models rather than reflecting a narrower set of providers.
Feature levels are what a conformance claim is measured against. If they encode assumptions that do not hold globally, providers outside those assumptions cannot conform without distorting their data.
Tighter specifications for list and contracted pricing columns.
Revisits the requirements for ListCost, ListUnitPrice, and the contracted-price columns, resolving ambiguity about how each is populated relative to the others.
These columns feed effective savings rate and rate-optimization analysis. When their definitions leave room for interpretation, two conformant datasets can report different savings for the same purchase.
The contributor guidelines refactored for consistency.
A unified markdown style and a navigable index across the guidelines directory, replacing rules that had drifted apart over successive releases.
Inconsistent guidelines produce inconsistent contributions, and lately hallucinated rules from AI coding assistants working off contradictory source. A single coherent set reduces both.
The Requirements Model and release enablement that carries 1.5.
The behind-the-scenes workstreams that a specification release depends on, grouped here because none is a spec change a reader would evaluate on its own:
(FR 1935), plus enablement artifacts for the 1.2 and 1.3 models (FR 1627, FR 1911).(FR 1685, FR 1687, FR 2445).(items 2180, 2238, 2370).Validation tooling and enablement material are how a normative change reaches practitioners as something usable rather than as prose. If they lag the spec, conformance testing tests the wrong version.
Champion scope: stretch goals for the 1.5 development cycle. Four are still possible for the release and are marked Advancing. The rest are prioritized work that now carries into 1.6. They stay listed because they show where the specification is heading, not because they are expected in December.
Still possible for 1.5
Separate tokens served from cache from tokens processed fresh.
Cached and uncached tokens can differ in price by an order of magnitude at the same vendor. Without the distinction, a rise in token cost cannot be separated from a fall in cache hit rate, so the single most actionable AI optimization lever is invisible in cost data.
Distinguish globally served models from region-pinned ones.
Global and regional serving carry different rates and different data residency characteristics. This is one of the few AI cost dimensions that is simultaneously a finance question and a compliance question, which makes it awkward to leave undeclared in billing data.
Every spec example passes the FOCUS Validator.
Assurance that every worked example in the specification passes the validator, so the examples can be used as authoritative reference implementations rather than sources of validation friction.
A convention for representing multi-condition column presence.
A consistent way to express applicability criteria that depend on more than one condition, so complex presence rules are written the same way throughout the spec.
Carries to 1.6
Prioritized champion work that will not reach the December release. It is grouped by theme below, and it is the natural starting point for 1.6 scoping.
AI pricing dimensions
Represent committed AI capacity the way other commitment discounts are.
Provisioned throughput is a commitment purchase, structurally similar to a reserved instance or savings plan, and FOCUS already has a mature commitment discount model. The open question is whether provisioned AI capacity maps onto it cleanly or needs its own treatment. This is where committed AI dollars sit and where utilization against them is measured.
Distinguish model costs that vary by context window size.
Several vendors price the same model differently above a context-length threshold. The rate change is invisible in cost data today, so a cost increase driven by longer prompts is indistinguishable from one driven by more calls.
Deeper AI service subcategories, including Agentic AI.
Extends the existing AI and Machine Learning subcategories so AI spend can be analyzed in layers, and revises the taxonomy so “Bots” becomes “Agentic AI” to reflect modern autonomous systems. Today the infrastructure, the model serving, and the application can all land in one bucket, which is why “what did AI cost us” is hard to answer consistently.
New datasets and extensions
A SKU Properties dataset for normalized attributes across providers.
Lets practitioners and tooling filter, compare, and build against normalized SKU attributes such as vCPU, memory, and region across providers, without parsing provider-specific JSON. The largest champion item after the Recommendations dataset that was already promoted.
Contract Commitment dataset, phase 2.
The remaining Contract Commitment columns deferred from 1.4, covering balance tracking, commitment intervals, and true-up status, so negotiated commitments can be monitored continuously without manual reconciliation against the provider.
Invoice detail enhancements for reconciliation.
Payment lifecycle tracking and additional invoice detail deferred from 1.4, for practitioners who reconcile FOCUS data against the invoices they actually pay.
Pricing and discount clarity
Allow ListCost to be null for negotiated-only pricing.
Data generators with “call us” or negotiated-only pricing no longer have to emit a misleading zero where no public price exists.
Defaulting rules for list cost and list unit price.
Clear defaulting rules for data generators that do not publish unit prices exclusive of discounts, so the same situation is represented the same way everywhere.
Tier handling in list unit price.
Unambiguous guidance on which pricing tier must be reflected in ListUnitPrice and ListCost, removing the savings inflation that occurs when providers default to the highest tier.
Pricing categories for SaaS contractual commitments.
A conformant way for SaaS vendors to represent contractual commitments such as annual spend and term agreements, which the current pricing categories do not cover cleanly.
A Charge Subcategory to split usage and credit types.
Lets practitioners distinguish usage types (actual consumption vs. unused commitment) and credit types (promotional vs. goodwill) within a single ChargeCategory.
Payment currency support.
A standardized way for practitioners in non-USD regions to reconcile FOCUS cost data against actual payments in their local currency, without manual exchange-rate lookups outside the dataset.
Normative requirements for what content belongs in each column.
Requirements describing what content belongs in a column, beyond its type, presence, and null handling, resolving long-standing ambiguity for older columns such as InvoiceIssuerName and RegionId.
Classification and defaults
Service-model classification, IaaS / PaaS / SaaS.
A normalized FOCUS column for segmenting spend by service delivery model across providers, without maintaining external mapping tables.
Default behavior for null name columns.
Consistent behavior when a provider does not supply a display name, so querying by resource or account name behaves predictably instead of varying by source.
Worked examples and spec quality
Line-item examples for adjustment scenarios.
Complete FOCUS-row examples for discounts, credits, refunds, and true-ups, resolving ambiguity about when an adjustment is a separate line item versus a modification to an existing charge.
Pricing unit conversion examples.
Worked examples for populating quantity and unit columns when the consumed unit differs from the pricing unit (e.g. consumed per hour but priced per GB), a frequent source of implementation variance.
Automated internal link validation in CI.
A CI check that catches broken internal cross-references before merge, replacing manual link review and keeping stale references out of published versions.
Two different things live here. The first group was ruled out or deferred on the merits, with reasons on the record. The second falls out on timing alone.
Ruled out or deferred on the merits
Clarifying included vs. excluded discounts in contracted cost.
Closed as not planned. The intent, resolving a known divergence in which discounts are reflected in contracted cost, is partly picked up by the list and contracted pricing revisit now in Core (FR 2492), which is a cleaner home for it.
Four AI price-detail requests filed but not carried into 1.5.
These are filed and understood, but were not flagged as 1.5 candidates, so they sit in the backlog rather than champion scope. Each is a plausible 1.6 item.
(FR 2487).(FR 2488).(FR 2489).(FR 2437).Observability-side identifiers, and token type as a first-class column.
A few finer-grained ideas were considered alongside model identity and set aside:
SkuMeter. Whether it should become a column or defined property is explicitly left open.Falls to 1.6 on timing
Champion candidates that miss the 1.5 window.
The window to open new 1.5 work has closed, so any champion candidate that is not already drafted and moving through review carries to 1.6 rather than 1.5, regardless of merit. It is a timing outcome, not a judgment on the work. The four advancing items are the ones still on track to clear; the rest of the champion list moves, and the 1.6 scoping window opens once 1.5 is finalized.
How to read the buckets. They are sorted by release confidence, not by importance. A champion item in bucket 3 may matter more to practitioners than a core item in bucket 1; it simply has less certainty of shipping in this release. The Core and Champion tags, and the scope filter above, are the other axis: what the working group has confirmed for the release versus what it is stretching to include.
Scope is broader than this page. A handful of standalone 1.5 fixes outside the curated core and champion lists have also merged (for example a PricingQuantity requirement cleanup and the PDF build changes). This page tracks the two curated scopes, not the full release changelog.
A terminology note. Inside the FOCUS repository, an issue prefixed “AI” is an Action Item, a unit of working-group work, and has nothing to do with artificial intelligence. Bare issue numbers on this page are feature requests unless labeled otherwise.
Sources. This page is drawn from the FOCUS working group’s public records: the 1.5 core board, the champion board, merged commits on the working draft, and the 1.5 release plan. Those are the live sources; follow them for day-to-day movement. Nothing here is a commitment on behalf of the working group.1.5 core boardChampion board1.5 release plan