Most organisations can now say what they spent on AI last month. Far fewer can say what that spend produced. On 5 November 2026 the Tokenomics Foundation, a Linux Foundation project, published a draft proposal to close that gap at the level of data: an "AI value data layer" that joins the AI bill to the work it paid for, whether the work held up, and what it was worth.
It is a draft, and it is written for data engineers and FinOps teams. It still matters to a CFO or chief AI officer, because it shows what evidence of AI value could look like in a common format, and gives executives a way to ask for that evidence now.
In short: the proposal would add workload, task and outcome identifiers to system telemetry, and four new datasets alongside FOCUS billing data: telemetry, tasks, outcomes and value. Joined, they would give cost per qualified outcome, the share of spend wasted on failed or abandoned work, and value booked against cost. That covers the evidence for the first three of this site's five layers. It does not decide what to fund, how AI work lines up with the portfolio, or who is accountable when attribution fails. Executives should pick one to three priority workloads, define what a passed outcome means for each, record planned value before work starts, and start reporting two numbers: cost per qualified outcome and scrap rate.
Why this matters now
That is the AI Value Gap described from the data side: cost is measured to the token, value mostly is not, and the two cannot be compared because nothing connects them. This site made the same point about the workload join in the instrumentation blueprint. What is new is that a neutral standards body now proposes a common way to make the join, in the same family of specifications that finance teams already use for cloud billing. InterpretationThe timing is set by the standards calendar. FOCUS, the FinOps Open Cost and Usage Specification, releases about every six months, and the proposal places its first piece of work in the next cycle.
What the proposal is, in plain English
The design has four steps, numbered from zero.
- Keep building on FOCUS. Billed AI cost already lands in FOCUS. Nothing changes here.
- Put cost context into telemetry. Extend OpenTelemetry, the open standard for traces and metrics, so that each AI request carries the FOCUS billing keys plus three new identifiers: a workload ID, a task ID and an outcome ID. Dollar amounts stay out of telemetry, because the cost of a request is often not known while it runs. Cost is joined later. The intent is for model gateways, agent routers and inference engines to emit these keys by default.
- Turn value classification into datasets. Four new datasets sit alongside FOCUS:
- Telemetry, rolled up into billing-aligned windows, usually hourly, with each charge split across workloads and tasks by activity such as tokens consumed. Usage that cannot be tied to a task is counted as scrap.
- Tasks, one record per unit of work, such as a coding assignment or a claims investigation, with whether it passed its quality check before release. Failed or abandoned work is also scrap.
- Outcomes, recording whether the result passed a post-delivery quality gate over a set period, with the number of attempts and the human review and rework time it took.
- Value, classifying each outcome by kind and unit (money, hours, risk) and marking each claim as reported, meaning notional capacity such as hours returned, or booked, meaning finance has verified it on a P&L line. Each claim is tracked from planned to estimated to realised.
- A playbook and reference implementation, with SQL joins, sample data and worked KPI calculations, targeted for June 2027.
An organisation does not have to instrument every request to start. In "cohort mode" each workload is treated as its own task and outcome over a monthly window.
The proposal's worked example is an AI coding agent. The bill comes from FOCUS. Telemetry tags each agent run with the agent's workload ID and a task ID per pull request. The task dataset records each pull request and whether it merged after passing tests. The outcome dataset records whether each release ran, for example, 14 days without a rollback or incident. The value dataset prices each successful release as engineering hours saved, net of the time reviewers spent checking the agent's work. Joined, these give cost per shipped release including every retry, spend on work that never merged, and whether value exceeded full cost.
How it maps to the five layers
This site organises AI value management into five layers, each depending on cleaner evidence from the one below. The proposal's datasets line up with the first three.
| Their dataset or measure | Our layer or measure | Relation |
|---|---|---|
| Cost and usage (FOCUS) | Layer 1, Usage Transparency | Direct overlap |
| Telemetry with workload, task and outcome IDs | Layer 1, and the workload join | The proposal goes further: it says where the keys live and how cost is allocated |
| Tasks, with an in-flight quality check | Layer 2, Output Quality, and the quality floor | Direct overlap |
| Outcomes, with attempts and review time | Layers 2 and 3, and verification cost | Partial |
| Value, reported or booked, planned to realised | Layer 3, Productivity Value, and the AI value ledger | Partial: the site adds evidence strength |
| Workload ID as a dimension | Layer 4, Delivery Alignment | The site goes further |
| (none) | Layer 5, Portfolio Strategy | The site goes further |
| Cost per qualified outcome | Cost per successful outcome | Same measure |
| Scrap rate | Attribution coverage | Related, not the same |
| Cost per unit of value | AI value density | One is the inverse of the other |
Two of those rows need a word.
Where it stops
- Delivery alignment. A workload ID is not a funded initiative. Nothing in the draft connects AI work to the epics, products or portfolio commitments it is meant to serve, so it cannot show whether AI effort is going where the strategy says it should.
- Portfolio strategy. Scale, hold, redesign or stop decisions weigh risk, supplier dependency, scarce review capacity and opportunity cost. Those are judgements made with the data, not fields in it. See Scale, Hold, Redesign or Stop.
- Evidence strength. A booked claim from a before-and-after comparison is weaker than one from a holdout group. The draft records whether value was booked, not how well the change was evidenced. This site's E0 to E4 evidence levels fill that gap.
- Accountability when attribution fails. The author records this as still open: who answers for a workload that cannot be attributed, or that fails its gate.
- Governance of outcome data. Outcome records may be written by a person or entirely by a system, possibly an agent. How they are checked is left to a future playbook.
- Individuals. The proposal deliberately does not track individual roles, so personal accountability stays a management question.
What to do in the next 90 days
None of this requires waiting for the specification. The proposal's own advice is to start small: pick one to three priority workloads, capture them fully and sample the rest.
- Choose one to three workloads where spend is material and the outcome is countable: a coding agent, a claims or case assistant, a customer-service deflection flow. Give each a workload ID and a named business owner.
- Define the unit of outcome and its gate for each. A merged pull request is a task; a release that runs 14 days without an incident is an outcome. Write both down before measuring.
- Record planned value before the work starts. The proposal makes this a field so that realised value can be compared with what was promised. It also makes experimentation easier to defend, because a missed plan is visible but not a surprise.
- Start in cohort mode. Report each workload by month. Go finer only where a decision needs it.
- Report two numbers each month: cost per qualified outcome, with scrap included, and scrap rate. Put attribution coverage next to them for the portfolio as a whole.
- Mark every value claim reported or booked, and take only booked value to the budget conversation.
- Ask your gateway, observability and FinOps suppliers whether they plan to emit the proposed keys, and in which FOCUS version. Ask for it in writing; do not take a roadmap slide as support.
What to watch
- FOCUS 1.6, the cycle in which the telemetry schema would be written, from November 2026 to April 2027.
- The Tokenomics executive forum in New York on 8 December 2026, where the proposal is next to be discussed. The Foundation lists it as Tokenomics Executive NYC, invitation only for senior executives.
- The white paper, "Value Attribution Data Architecture: Schema and Explainer", which the Foundation says is circulating in draft.
- The June 2027 demonstration at Tokenomicon + FinOps X in San Diego (7 to 10 June 2027), with the playbook and reference implementation. A London edition runs on 8 and 9 February 2027.
Sources
- Shawn Alpay, "AI Value Data Layer: Joining AI Cost to Value With FOCUS", Tokenomics Foundation, 5 November 2026. Draft proposal. Licensed under CC BY 4.0; paraphrased, adapted and mapped to this site's framework. The mapping and all recommendations are this site's, not the Foundation's.
- Tokenomics Foundation, "Classifying and Measuring Realized Value from AI", Release Candidate 2, 16 September 2026, CC BY 4.0.
- FinOps Foundation, "FinOps for AI Overview", read 5 November 2026.