A Proposal to join Cost to Value in an AI Value Data Layer

Every organization spending on AI is being asked the same question: what did we get for it?  The answer is scattered across disparate datasets, held in disparate systems, and very few can connect them.

Shawn Alpay, Director of Data Engineering at the Linux Foundation, has proposed a structure that joins cost, telemetry, tasks, outcomes, and value on common keys, and a process for standardizing it with FOCUS and OpenTelemetry.

He presented the idea at the Tokenomics Foundation’s AI Economics Forum in San Francisco. The design is a draft, and industry inputs are needed to work toward making it an achievable standard. Next it will be discussed on Dec 8 in NYC at the Tokenomics Executive Forum.

The Problem: Five Kinds of Data, Five Islands

The AI value journey breaks into five types of data. Each answers a different question:

No single source tells the whole story. The bill knows what you paid but not why. Telemetry knows what happened but not what it cost. Tasks, outcomes, and value live siloed wherever each team happens to track them.

For a finance leader, this is why AI dashboards don’t reconcile to the P&L. For an engineer, it’s why “cost per task” is so hard to compute even when every request is logged. The point is simple: you can’t calculate a KPI that spans cost and value unless all five live in one data store with keys that join them.

The Proposal

I proposed four steps to help organizations attribute value, to be delivered at the Foundation’s conference Tokenomicon FinOpsX in June 2027.

Step 0: Keep Building on FOCUS

FOCUS, the FinOps Open Cost and Usage Specification, already normalizes billing data across clouds, SaaS, and other variable spend, and it ships a new version every six months. Billed AI costs across the whole tokenomics stack are already landing in FOCUS today. The FOCUS 1.6 release cycle, running from November 2026 through April 2027, continues that work.

Step 1: Put Cost Context Into Telemetry

The first new piece is a FOCUS-aligned telemetry schema that extends OpenTelemetry, the widely adopted open standard stewarded by the Cloud Native Computing Foundation. OpenTelemetry already has conventions for generative AI, cloud resources, HTTP, and more.

This proposal would add a schema for cost context. In practice, it means stamping FOCUS keys such as the resource, billing account, and service provider onto the traces and metrics that AI systems already emit. Because cost-centric join keys have been mostly stable since FOCUS’s early versions, the schema would work across all versions of the FOCUS spec.

The most important addition is three identifiers: a workload ID, a task ID, and an outcome ID. Together with the billing keys, they let a request be traced forward to the result it produced and backward to the bill that paid for it.

Note that this does not put dollar costs into telemetry, since you often don’t know the cost of a request while it’s running. This step just adds the keys. Cost gets joined later.

The plan has two stages:

• Publish. A dedicated task force in the FOCUS 1.6 cycle would author the schema in its own repository, as OpenTelemetry’s semantic conventions group recommends, and work toward its inclusion in the official attribute registry. The legal and process framework for that collaboration is being set up now within the Linux Foundation.
• Enable. A schema that no one emits is useless, so the team would send lightweight contributions to LLM gateways, agent routers, harnesses, and inference engines, work with routing platforms to support the schema natively, publish a collector for enterprises running homegrown harnesses, and work with cloud and observability providers to generate and ingest the data with dashboards out of the box.

Step 2: Turn Value Classification Into Datasets

The Tokenomics Foundation‘s working groups have been developing a methodology for classifying value in ways a CFO can defend. Step 2 operationalizes that methodology, along with the telemetry from Step 1, into four new FOCUS datasets:

• A telemetry dataset that rolls OpenTelemetry traces up into time windows that match billing periods (typically hourly), so each charge can be split across the workloads and tasks that used it, in proportion to their activity, such as tokens consumed. Usage that can’t be tied to a task is counted as scrap.
• A task dataset that records each deliverable unit of work, such as a coding assignment or a claims investigation, and whether it passed a quality check before going out the door, such as automated tests. Work that fails the check, or is abandoned partway, is counted as scrap rather than dropped.
• An outcome dataset that records whether a given outcome, over a given time frame, passed its post-delivery quality gate, such as a shipped release running without a rollback or incident for 14 days. It holds the details around the result, such as the number of attempts, the count of qualified outcomes, and the human review and rework time that offsets them.
• A value dataset that classifies each outcome by the kind of value realized and how it’s measured: dollars, hours, risk mitigated, or another unit. Each value claim is also marked as reported (notional capacity, such as hours returned) or booked (hard impact that FP&A has verified on a P&L line) and tracked from planned to estimated to realized value.

The work would run in two places. Requirements come from the Tokenomics working groups, and design and specification happen in the FOCUS working group.

Many organizations will attribute at the workload level long before they can attribute at the level of individual outcomes. The current draft handles this without a separate dataset: a workload ID is stamped on every dataset, and an organization can start in a coarse cohort mode, treating each workload as its own task and outcome over a monthly window, before it instruments individual requests.

Step 3: A Data-Driven Tokenomics Playbook and Reference Implementation

Datasets alone don’t tell anyone what to do. The third deliverable, targeted for June 2027, has two parts. A playbook explains how each persona uses these structures, how to adopt them in stages, and how to govern the data. A reference implementation puts that guidance into working form: the actual joins in SQL, sample data, and worked calculations for KPIs such as:

• Cost per qualified outcome: total workload cost, including scrapped and failed attempts, divided by outcomes that passed the quality gate.
• Scrap rate: the share of spend that went into abandoned sessions and tasks that failed their technical quality check.
• Cost per unit of value and net workload economic margin: how much spend it takes to produce each dollar of realized value, and what’s left over.

These artifacts would debut as a public demonstration, ideally at Tokenomicon FinOpsX, built with practitioners and vendors to show the whole chain working end to end.

How the Value Chain Data Fits Together

Picture five tables in one data store:

• Cost and usage (FOCUS) tells you what each model, resource, and provider cost.
• Telemetry (OpenTelemetry, with FOCUS keys) tells you which requests ran, tagged with workload, task, and outcome IDs.
• Tasks tell you which units of work those requests served and whether each passed its technical check.
• Outcomes tell you which of those tasks produced a result that passed the bar after delivery.
• Value tells you what each qualified result was worth.

Consider a hypothetical AI coding agent. FOCUS records what the team paid its model provider this month. Telemetry shows every agent run, each stamped with the workload ID for the coding agent and a task ID for each pull request it works on. The task dataset records each pull request, how many attempts it took, and whether it merged after passing automated tests.

The outcome dataset records each release those pull requests shipped in, and whether it ran for, say, 14 days without a rollback or incident. The value dataset classifies each successful release, perhaps as engineering hours saved at an agreed rate, net of the time reviewers spent checking the agent’s work.

Join the five and the team can answer questions it couldn’t before. What did each shipped release cost, including every pull request and retry behind it? How much spend went to attempts that never merged? Did the value of the hours saved exceed the full cost? Is that ratio improving month over month?

That’s the conversation a CFO and a CTO keep failing to have with data. This structure gives them shared numbers to connect the AI value chain.

Questions From the Room

The attendees pushed hard on the proposal. Here are some of my answers.

Where does a “job to be done” live? Not in cost and usage, which has no visibility into tasks. It enters through telemetry, which has to be enriched from the work itself, such as the pull request or the support ticket. From there it joins to task, outcome, value, and back to cost. The proposal deliberately doesn’t track individual roles; that’s the wrong level of granularity.

Will this work across industries? I originally doubted it, but working through the design changed my mind. The structure indexes on a function, tying value to cost, not on a domain. Each organization defines its own unit of outcome, whether that’s a claim, a trade, or a customer issue that stays resolved, and the quantities follow.

Where do evals and quality checks go? Deciding what counts as passing is inherently a judgment call. Once an organization makes it, the pass or fail result is loaded into the task dataset for in-flight checks, such as tests or automated evals, or the outcome dataset for post-delivery checks, possibly by an agent. Telemetry can carry eval results too, but the official pass or fail lives in these datasets.

Can the outcome data be trusted? Outcome records could be populated by a person or entirely by a system. One participant asked about governance over what goes into them. I expect the playbook to include governance guidance, and I invited people to shape it in the working groups.

Isn’t real-time attribution expensive? One practitioner who has tried it warned that it’s painful. Billing data typically arrives daily, while AI requests arrive by the second, and attributing each request to a business unit requires streaming metadata. I agreed and described a crawl, walk, run approach. Attributing at the workload level, using metrics, sidesteps much of the data volume. Attributing at the level of individual pull requests or tickets means accepting a lot more processing.

My advice: pick one to three priority workloads, capture them fully, and sample the rest. The current draft also keeps volume manageable by rolling telemetry up into hourly windows that match billing periods, so individual traces never land in the finance warehouse.

Is this the Tokenomics framework? In short: it isn’t. It’s an implementation that supports one, much as FOCUS gives data structure to the FinOps Framework. But several board members saw more in it. One said the model lit up how the work maps to people: a business owner defines the outcome and its value, an engineer collects the signals, users benefit, and a funder is looking for the result.

Another argued it implies a role that doesn’t exist yet: the person who asserts in advance what state change an investment should produce. That raises an incentive question. People need to be able to make that call without being punished when an experiment doesn’t pan out. The draft gives that value assertion a place to live: a planned value recorded before the work, compared later with realized value.

Is it really left to right? One member argued the flow is a loop, since measured value feeds back into investment decisions. I agreed; the arrows already run both ways, and the visual could become a circle.

Who owns it? I was asked who is accountable when it doesn’t work; this is still open. Ultimately, value attribution is a cross-functional exercise, but the final playbook will need to say at the top who it’s for.

Why It Matters Beyond AI

This isn’t only a tokenomics exercise. The same five-way join works for any unit economics. A FinOps practitioner measuring the value of cloud spend has the same problem: a bill on one side, outcomes on the other, and nothing standard connecting them. The Tokenomics Foundation is driving the work, but the benefit runs across the broader FinOps and technology value community.

It also follows a pattern that has worked before. FOCUS succeeded because it was built in the open by practitioners, providers, and vendors who all needed the same answer. The proposal grows out of what the community has said it needs.

What Happens Next

The next step is bringing the proposal to the Tokenomics Foundation members and working groups, testing it against their value classification work, and refining it to cover most of the real need. A draft white paper, Value Attribution Data Architecture: Schema and Explainer, is circulating for review.

1. 1. Come talk to us in person at an upcoming Tokenomics event to continue the conversation.
   2. Email us at hello@tokeneconomics.com to receive a copy of the white paper when it launches. Include your name, organization, and role (practitioner, provider, or vendor), plus one AI workload you’d test this on.
   3. Want to get deeply involved as a design partner? Consider organization membership in the Tokenomics Foundation to join the working groups and get early previews. Design partners test early drafts against their own data and shape the specifications before they reach 1.0, with the goal of a working demonstration at Tokenomicon + FinOps X in June 2027.

The goal is ambitious, but delivering even part of it by next June with your help would move the industry meaningfully forward.