FOCUS Working Group / Release 1.5
Where the FOCUS 1.5 release stands across the whole specification. Work already merged into the working draft ships in December. Work in review is expected once it clears Member review. Work that has started but is not yet certain is listed on its own, with what would settle it. Cards are sorted by how close the work is to shipping.
What 1.5 delivers
Merged into the working draft, or in review with a pull request moving through the release gates.
#1057#2018, #2099, #1941#2358#2492, #2315, #2325, #2377, #2335Started, not yet certain
Real work with an open question over whether it lands in 1.5 or the next release.
#975#2414Both are listed because the work is real and input now shapes it, not because either is expected. Details and where to weigh in are in bucket 3.
Everything on this page assumes the work clears Task Force and Member review before the 3 December ratification. The review gates are on the timeline below; they are the working group’s own deadlines, not commitments to anyone outside it.
If you use FOCUS data today: nothing here changes published 1.4 data before December. The new columns (Principal ID, Credential ID, Requester Details, Allocated Service Name) and the SKU Price dataset are additions, and existing column names are unchanged. Two places where values can shift: the list and contracted cost definitions in review, if you compute effective savings rate, and the Compute subcategories, where bare metal now classifies apart from virtual machines. The 1.5 changelog will classify every change’s compatibility during the October consistency review.
FOCUS 1.4 is the current published version. The 1.5 working draft is in its review gates now: pull requests had to start Task Force review by 10 September, must start Member review by 24 September, and must complete Member approval by 8 October. A three-week consistency review follows, then a 30-day intellectual property review. The working group approves and the Steering Committee ratifies on 3 December, and the public announcement is planned for the December Virtual Summit, with the publication date confirmed in December.
How to read the buckets. They are sorted by release confidence, not by importance. An item in bucket 3 may matter more to FinOps Practitioners than one in bucket 1; it simply has less certainty of shipping in this release.
No items match that filter.
Merged. These ship in 1.5 unless something is pulled during the consistency review, which is rare.
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. The cached-token properties in review (FR 2099) sit beside these, and the SKU Price dataset in review carries the same properties.
This is the piece that makes multi-provider AI spend comparable. Without it, an organization can say what it spent on models last quarter but cannot break that down by model without provider-specific parsing.
Cost rows can identify the principal that drove the spend.
A PrincipalId column on Cost and Usage, identifying the principal: the user, service account, or other entity in an identity and access management model that was granted access to the resource or service. It preserves a principal-level audit trail across PaaS, SaaS, and generative AI billing. Merged on 10 September. The actor columns are delivered incrementally: Requester Details and Credential ID follow in Member review (bucket 2). A Consumer ID column (PR 2495) is postponed and not part of 1.5.
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, with a column naming the receiving service.
A new AllocatedServiceName column naming the service a split charge is allocated to, updated split cost allocation supported features, and a field mapping for data generators. All three parts merged between 12 and 27 August. One refinement of the column’s normative requirements (PR 2655) is approved and finishing Task Force review; it settles what the column carries on the unallocated-portion row when one origin charge splits across more than one service.
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.
Service Category descriptions that no longer assume everything is cloud.
The ServiceCategory descriptions rewritten to be technology-agnostic (merged in July), then the Compute category revised to acknowledge physical compute and the Virtual Machines subcategory split into Bare Metal and Virtual Machines (merged 10 September). The feature request closed as complete on 17 September. A broader expansion of the allowed values for on-premises, SaaS, and physical infrastructure (PR 2518) remains a draft and is not part of 1.5.
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.
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. Follow-through merged in September: the criteria are now called operating model conditions, every Conditional column’s Content Constraints table names the condition that governs it, and the dataset overview tables use one convention for columns whose presence depends on more than one condition, which closed FR 2441.
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 unchanged, 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 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 contributor guidelines refactored for consistency.
A unified markdown style and clarified rules across the guidelines directory (merged in June), and the refactored normative requirements guidelines (merged in August), replacing rules that had drifted apart over successive releases. A restructuring of the repository’s instructions for AI coding assistants (PR 2652) is still in review and a related pull request (PR 2514) is moving to 1.6; neither changes the specification text.
Inconsistent guidelines produce inconsistent contributions, and lately hallucinated rules from AI coding assistants working off contradictory source. A single coherent set reduces both.
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.
Smaller corrections and build improvements already in the working draft.
None of these is a feature a reader would evaluate on its own, but each is in 1.5:
PricingQuantity(FR 2130, PR 2579).ContractCommitmentDurationType split so the compound rule reads as two (PR 2549).(PR 2506, merged 17 September).(PR 2510, PR 2534).(PR 2462, PR 2472, PR 2609, PR 2622).(PR 2594).Open pull requests in Task Force or Member review. Expected in 1.5, and each card says what is left, including whether the approvals sit on the current commit. The next gate is 24 September, when a pull request needs one approval on its latest commit to start Member review.
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.
Two decisions landed in September. The dataset is Conditional, gated on IncludesUnitPricing, the same operating model condition as the four Cost and Usage columns that point into it (SkuId, SkuMeter, SkuPriceId, SkuPriceDetails), settled on 15 September. And the two unit price columns collapse into one, so a list price and a contracted price each get their own row, confirmed by TF-1 the same day. That reshape is being applied now; because it changes structure, the pull request needs fresh approval on the new head before it can start Member review. Three companion pull requests move with it: the two SKU Price supported features, catalog discovery and price estimation and rate optimization and contract evaluation (PR 2595, approved); reconciled identifiers in the commitment discount example data (PR 2640, approved and moving to Member review); and the consumption currency scoping of CurrencyFormat (PR 2617, one change request outstanding).
This is the largest single piece of 1.5 and the difference between reporting on cost and negotiating it.
Requester Details and Credential ID complete the actor columns.
Two more Cost and Usage columns beside the merged PrincipalId: CredentialId, identifying the credential used to make the request, and RequesterDetails, a JSON array of key-value entries carrying the principal and credential detail a provider can supply. An entry names a principal only when PrincipalId is populated, and a credential only when CredentialId is. Approved by four reviewers, two of them on the current commit, and in Member review since 17 September.
A Consumer ID column (PR 2495) is postponed and not part of 1.5. Scoped detail configuration, which would let practitioners choose how much actor detail a dataset carries, moved to 1.6 on 16 September (bucket 4). The wider JsonObjectFormat change that arrays call for becomes a 1.6 feature request (Action Item 2700).
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 provider. 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.
Two FOCUS-defined properties on SkuPriceDetails, each with allowed values: TokenCacheAction, how a request’s tokens interacted with the cache, and TokenDirection, request or response tokens. They replace the single TokenType property drafted earlier, and worked examples and example queries ship with them. It moved to Member review on 17 September, with an approval on its current commit and two on earlier ones.
The two property descriptions are being rewritten, and whether “Uncached” becomes “None” is open. A cache cost efficiency query drafted for the Cost Comparison supported feature came out before Member review, to return once the SKU Price dataset and these properties have been tested together.
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 provider 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, plus a supported feature. The scenarios cover per-token API billing, the prepayment drawdown pattern where capacity is bought up front and drawn down over time, a first-party model served by a cloud provider, and a multi-model marketplace invoice. Requested by NatWest, SLB, UK Government Digital Service, Shutterstock, Syngenta, Anglepoint, AWS, and the FinOps Foundation.
TF-2 confirmed on 16 September that it stays in 1.5. Dave Moreau and Graham Murphy joined the author on it, and the work is due to finish over the following three weeks. Six findings posted in that session on the newest scenarios are being fixed, and the examples may keep improving during Member review as long as the data shape holds.
Tighter specifications for list and contracted pricing columns.
Revised definitions for ListCost, ListUnitPrice, ContractedCost, and ContractedUnitPrice that decouple the cost definitions from unit price, formalize tiering and contracted defaults, and align aggregation guidance with covering and covered charge terminology. The IncludesUnitPricing condition stays in 1.5, decided by the Maintainers on 14 September; the version retaining it merged into this branch on 17 September, which left its four approvals on earlier commits, so it needs a fresh one on the new head to enter Member review. Removing the condition is a 1.6 feature request.
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.
A rubric for which columns are Mandatory or Conditional, so feature levels hold up globally.
A feature-level rubric for Mandatory and Conditional columns, so the requirements hold up across regions and billing models rather than reflecting a narrower set of providers. Three approvals on earlier commits; the latest push, from 10 September, is awaiting re-approval. The completed Feature Level value lists that accompany it merged on 17 September.
The column-level changes that would apply the rubric have been parked since May and now conflict with the base: upgrading three Cost and Usage columns, downgrading eight, and adding Data Originator Name and Data Provider Name (PR 2375, PR 2374, PR 2430). Treat those as open, not expected.
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.
Spec examples checked against the FOCUS Validator, starting with the flexibility examples.
An adjusted validation path so the flexibility example datasets can be run through the Validator, with a validation script and a contributor guideline. Approved by one reviewer and mergeable; the owner is answering five open review threads, one of them about columns the specification no longer defines, before the 24 September gate. Two sibling pull requests, SaaS validation and the commitment discount scenario datasets, are out of the 1.5 cycle.
Examples that fail the validator teach implementers the wrong thing. Examples that pass become reference implementations rather than sources of validation friction.
One canonical way to write a contract commitment duration.
Requires ContractCommitmentDurationType to be expressed in the largest whole unit that fits, so the same term is not written several ways across providers. Targeted at 1.5 by TF-1 on 15 September; the author is closing the remaining review threads.
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). The 1.5 model’s structure is merged, and an automated extraction workflow that pulls the rules from the specification in GitHub Actions is in review, with its approvals on earlier commits (PR 2670). The 1.5 rule additions follow the spec pull requests they describe.(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.
Work has begun on these, and whether they land in 1.5 is still open. Input now shapes what eventually ships.
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 draft Recommendation dataset (PR 2444), opened in June as a wireframe for the group to react to, and a draft supported feature (PR 2583). Since then the working group has put roughly a hundred review threads into it, renamed the provider column to RecommendationProviderName, and proposed FOCUS-defined properties for RecommendationDetails. The design question underneath is which columns a first release needs and which are additions.
Not decided. On 16 September TF-2 set the test: the pull request starts Member review in 1.5 only if it is a clean pull request with an approval by the following week; otherwise it moves to 1.6. The author is trimming it to a smaller scope the group will not dispute, with the contested right-sizing configuration columns proposed as 1.6 targets. The position recorded from the 16 September session: the dataset is a question of when, not if.
If you produce recommendations, as a cloud provider, a FinOps platform, or an optimization tool, or consume them from more than one source, the draft is open for review now. Two questions on the pull request shape the first release: which recommendation types it needs to carry, and which identifiers link a recommendation back to the resource, SKU, or commitment it targets.
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.
A SkuPriceDetails property carrying the pricing region scope. PR 2613 introduces it as ServingScope and holds two approvals; PR 2667, stacked on it, renames it to RegionScope, the name the working group’s research recommended, adopted on 17 September. TF-2 sent the property to the Open Forum of 18 September; if it is not sufficiently complete after that, it moves to 1.6. Consistency with the SKU Price columns being introduced is the other check.
Three groups live here. Work moved to the next cycle by a decision made during this one. Work ruled out or deferred on the merits, with reasons on the record. And prioritized candidates that never entered the 1.5 window, which fall out on timing alone.
Moved to 1.6 during the cycle
Decisions made in September that push work to the next release.
(PR 2473, under FR 2358).IncludesUnitPricing condition. The SKU Price dataset and the four Cost and Usage columns that reference it stay gated on it in 1.5; a 1.6 feature request carries the analysis. Decided by the Maintainers on 14 September (AI 2691).(PR 2564).JsonObjectFormat support for arrays beyond what Requester Details needs: the attribute name, key uniqueness for array entries, and nesting rules become a 1.6 feature request (TF-2, 16 September).(PR 2661, PR 2662).(PR 2518).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 Member review (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 taken up as 1.5 work, so they sit in the backlog. 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:
TokenDirection defined property on SkuPriceDetails rather than as a column.Candidates that did not enter the 1.5 window
Prioritized feature requests that were available for a contributor to take up in 1.5 and did not get a pull request before the window closed. They carry into 1.6 scoping on timing, not merit, and are the natural starting point for it. Grouped by theme.
AI pricing dimensions.
(FR 2371).(FR 2521).(FR 1943).New datasets and extensions.
(FR 1045).(FR 1938).(FR 1936).(FR 2654).Pricing and discount clarity.
ListCost to be null for negotiated-only pricing, so “call us” pricing does not emit a misleading zero (FR 1523).(FR 1832).(FR 1625).(FR 1933).ChargeCategory(FR 1934).(FR 1997).(FR 1890).Classification and defaults.
Worked examples and spec quality.
(FR 1489).(FR 1490).(FR 2012).Scope is broader than this page. A number of smaller editorial and build fixes have also merged; the most visible are grouped in one card in bucket 1. This page tracks the release story, not the full 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 v1.5 board, the v1.5 milestone, merged commits on the working draft, and the 1.5 release plan. Those are the live sources; follow them for day-to-day movement. Status here is as of 17 September 2026 and supersedes the 18 August edition. Nothing here is a commitment on behalf of the working group.v1.5 boardv1.5 milestone1.5 release plan