Value Attribution Data Architecture: Schema and Explainer

1.1 Five Datasets

Each dataset represents a distinct stage in the unit economics value chain, stewarded by a different part of the organization:

1.2 Standards and Sources

These five datasets build upon established open specifications and enterprise platforms that already exist inside most organizations:

These sources rarely share keys or formats, and some Task, Outcome, and Value data is not queryable at all, such as an outcome tracked only in an executive dashboard or a value objective set by leadership. Such records can be entered one at a time, with Value claims recording who attested to them, or gathered by an agent that asks their owners and writes the answers back in queryable form. Governance for how these records are populated belongs in the Implementation Playbook (Section 5).

1.3 Execution Hierarchy

To connect raw infrastructure spend to business value without forcing a single team to "grade its own homework," organizations need a shared anatomy for AI execution. Before examining database schemas, we must align on the five-level hierarchy that bridges executive portfolio management down to individual model invocations: Span -> Trace -> Task -> Outcome -> Workload.

(An upstream Outcome may optionally trigger a downstream Task. See Section 1.3.1 for more information.)

The most granular entities (Span and Trace) are OTel terms that capture runtime engineering observability and aggregate into the Telemetry dataset. Because OTel is already the industry standard for tracing cloud-native software, extending it into unit economics allows organizations to build on telemetry their engineering teams already collect, wrapping those technical traces inside the top three business layers (Task, Outcome, and Workload).

1.3.1 Task to Outcome Relationship

Across enterprise value chains, what constitutes a finished Outcome versus an intermediate Task is relative to the organizational altitude and stage of the workflow being governed. In complex domains like the Software Development Lifecycle (SDLC), work naturally recurses across stages: an upstream team's verified Outcome frequently serves as the input trigger for a downstream process's Task (Task -> Outcome -> Task -> Outcome).

Organizations can model this flexibility in two ways: (1) Single-Altitude Selection, where the team defines Task and Outcome at the single governance altitude that matches their System of Record (e.g., Merged PRs as Tasks rolling directly into a Production Release Outcome), or (2) Multi-Stage Chaining, where Stage 1's verified OutcomeId is linked to Stage 2's downstream Task via the optional UpstreamOutcomeId foreign key on the Task table.

2.1 Logical Overview

While Section 1 introduced the five datasets from an organizational and business perspective, implementing them in an enterprise data warehouse requires understanding their distinct table archetypes, row grains, and lifecycle behaviors.

These datasets are logical. The schema fixes their keys, row grain, and reserved values, not where they are stored: they can be landed in one warehouse or platform, or assembled at query time from each system of record, for example through Model Context Protocol (MCP) servers. The shared keys are what make either approach work. Reconciling allocated cost to the bill is simplest when the data sits in one place, so finance-grade KPIs will usually call for landing it centrally.

A high-level description of each table follows, with their schemas available in Section 3.

2.1.1 Logical Datasets

2.1.2 Dataset Joins

The five datasets connect through a relational chain of primary and foreign keys anchored by standardized UTC time windows:

2.1.3 Optional Multi-Outcome Chaining

When a verified business result in Stage 1 (OutcomeId, e.g., a merged Pull Request or an escalated Tier-1 security alert) triggers new deliverable work in Stage 2 (e.g., a release integration task or an incident remediation workflow), the downstream Task record may reference the prior stage's OutcomeId in UpstreamOutcomeId.

• Cost Rollup Guardrail: Telemetry activity always binds strictly once to the specific TaskId where tokens were consumed. UpstreamOutcomeId provides lineage to roll up cumulative end-to-end value-chain cost across stages without ever double-counting EffectiveCost in portfolio aggregations.

2.2 Telemetry Schema

The Telemetry dataset is meant to be populated from aggregated telemetry data in OpenTelemetry (OTel) format, leveraging a forthcoming telemetry schema using the focus.* namespace. This will facilitate organizations leveraging harmonized FOCUS-aligned semantics across all data sources, and it will ensure that there is a place to stamp each trace with the relevant Workload and Task (and Outcome, where it is known at runtime).

A proposed second FOCUS working group, the FOCUS SemConv WG, shall partner with the OpenTelemetry Semantic Conventions Special Interest Group (OTel SemConv SIG) to author and publish this telemetry schema, starting in the FOCUS 1.6 release cycle. The schema will be authored in its own repository, an approach OTel supports, with the goal of upstreaming its concepts into the official OTel semantic conventions.

Then, we shall enable use of this schema in the ecosystem through a combination of pull requests issued to agent harnesses and orchestration frameworks (e.g., LangGraph, CrewAI), open-source gateways and routers (e.g., LiteLLM, Higress, agentgateway, Agent Router), inference engines (e.g., vLLM, llm-d), commercial routers (e.g., OpenRouter), cloud service providers (e.g., AWS, Azure, GCP), and observability platforms (e.g., Datadog, Grafana).

Because no provider emits focus.* yet, the first artifacts will support enterprises that enrich their own telemetry without upstream help: a reference Collector configuration and sample data (Section 5).

That work will proceed between now and June 2027, and this paper will be updated to reflect progress. The proposed attributes, the rules for where they go, and governance will be set out in a forthcoming design brief.

2.2.1 gen_ai.* vs focus.*

The proposed focus.* semantic convention namespace is intentionally orthogonal to domain-specific OpenTelemetry namespaces such as gen_ai.*, http.*, or db.*. Rather than duplicating technical consumption counters (such as gen_ai.usage.input_tokens or gen_ai.response.model), focus.* provides the universal commercial billing-scope keys and business value-lineage identifiers (focus.workload.id, focus.task.id, and focus.outcome.id). This allows the architecture to govern AI token economics today while scaling seamlessly to non-AI cloud and infrastructure workloads. Note that focus.* carries join keys, not dollar costs. The cost of an individual request is often unknown while it runs, so cost is joined later from CostAndUsage through the Consumption Scope.

2.2.2 Attribution Layers

Attribution keys reach telemetry at three layers: runtime emitters (items 1 and 2), the OTel Collector (item 3), and the enterprise before rows enter the Telemetry dataset (item 4). Until harnesses, gateways, and providers emit focus.* natively, an enterprise should assume it receives no keys from upstream and plan to supply every key at the last two layers.

2.3 Aggregation & Allocation

Retaining individual OpenTelemetry Spans and Traces inside a data warehouse creates unnecessary data volume and risks double-counting tokens across parent and child spans.

2.3.1 Leaf-Span Aggregation

The Telemetry dataset aggregates only leaf-level spans, such as model inference and tool spans, into time windows matching Cost and Usage billing periods. Tracing identifiers (span_id, parent_span_id, trace_id) are omitted from the dataset, reducing row volume by orders of magnitude while preserving attribution dimensions (e.g., SubAccountId, ServiceName, ResourceId, WorkloadId, TaskId, OutcomeId).

Leaf level is judged separately for each Consumption Scope. A span counts toward the charges its billing-scope attributes identify, and an attribute set on a span overrides the same attribute on the emitting service's OpenTelemetry Resource. For each scope, the dataset aggregates the deepest spans that carry its keys. When a support bot running in a container calls a model API, the model call counts toward the model provider's charges, while the container's charges are weighted by the span that handled the request, whose duration includes time spent waiting on the model.

2.3.2 Allocating Shared Spend via ActivityWeight

Because a single billed resource (e.g., provisioned throughput deployment or shared GPU cluster) serves multiple workloads and tasks simultaneously, raw token counts cannot be summed equally to split a bill. The Telemetry schema introduces ActivityWeight as a normalized numeric weight for each row. A task's allocated share of EffectiveCost for a given Consumption Scope and time window is calculated as its share of total ActivityWeight on that Consumption Scope during that window.

Note on Future Standardization: The exact weighting formulas used to compute ActivityWeight (for example, weighting output tokens at 3x–5x input tokens and cached reads at 0.1x based on vendor rate cards or hardware FLOP profiles) require further working group discussion and will be standardized in a future release. Where a scope's charges carry different rates, such as for input, output, and cached tokens or by region, weights should be matched to the charge rows priced for that usage.

This schema standardizes the inputs to shared cost allocation, the join keys and the usage weights, not the allocation method. Organizations and FinOps tools already allocate shared cost, with methods that vary by provider and service; ActivityWeight lets any of those methods be applied consistently across the five datasets.

Allocating by ActivityWeight also spreads the cost of unused capacity, such as an idle hour on a provisioned deployment, across whoever used the resource in that window. Organizations should decide explicitly whether to spread it or hold it separately so utilization stays visible; a future version may define how.

2.3.3 Costs without Telemetry

Not all cost reaches a workload through telemetry. Some billed charges, such as enterprise support or SaaS seats, have no usage signal to join, and some costs of operating a workload, such as labor, appear on no bill at all. The allocation described in this section covers only cost that telemetry can match. One option, not yet represented in the proposed schema, could extend the Telemetry dataset to cover the rest:

2.4 Scrap, Friction, and Rework

A core design requirement of this schema is preventing "happy-path bias," where organizations divide only the tokens of their final successful prompt by their business outcomes, ignoring failed iterations and human cleanup. The schema accounts for waste across three distinct mechanisms.

2.4.1 Early- and Late-Binding Attribution

In automated pipelines, TaskId and OutcomeId may be injected synchronously at runtime by the agent harness via OpenTelemetry baggage (Section 2.2.2). In interactive workflows (such as an engineer working in an IDE before a Pull Request exists), those foreign keys are resolved asynchronously post hoc.

When telemetry activity is not linked to a downstream Task or Outcome, whether because the work was abandoned or because the link was never recorded, TaskId and OutcomeId default to the reserved value 'UNLINKED'. This guarantees that 100% of EffectiveCost matched to telemetry (Section 2.3.3) is accounted for in unit economics denominators rather than being silently dropped by inner joins.

Scrap Rate (Section 4.2) counts unlinked cost as scrap until it is linked, and reports it as a separate line so missing links are not mistaken for failed work.

Planned non-production compute, such as offline evals, fine-tuning, and RAG indexing, is not scrap. It is stamped with the reserved value 'NON_PRODUCTION_OVERHEAD' (or a dedicated overhead WorkloadId) so that it is reported separately from broken production execution. (Specific post-hoc correlation methodologies are out of scope for this document.)

2.4.2 Two Quality Gates

• TaskQualityBarMet (In-Flight Technical Gate)
  1. Evaluates whether a deliverable unit of work passed technical inspection (e.g., code compiled, CI tests passed, or draft passed automated evaluation). Failed tasks (FALSE) represent in-flight scrap.
• OutcomeQualityBarMet (Post-Delivery SLA Gate)
  1. Evaluates whether a shipped result survived its settlement window without rollback, ticket reopen, or customer failure. Failed outcomes (FALSE) represent post-delivery warranty recalls. OutcomeQualityBarMet is recorded on every entry, so an Outcome's latest entry always shows its current status. A failure inside the settlement window updates the Pending entry; a failure after settlement that undoes the Outcome is recorded as an amending entry with OutcomeQualityBarMet = FALSE and a negative QualifiedOutcomeCount.

2.4.3 Friction and Rework Penalties

Both Task and Outcome track raw output (ObservedTaskQuantity, ObservedOutcomeQuantity) alongside two deduction columns, shown here without their Task or Outcome prefix:

• FrictionQuantity (Babysitting/Triage Tax)
  1. Human verification, review, and editing drag incurred even when the AI passes its quality bar.
• ReworkPenaltyQuantity (Failure Cleanup Tax)
  1. Human labor spent reverting, debugging, or redoing work when a Task or Outcome fails its quality bar. Subtracting both from the observed quantity (or comparing against the baseline) yields the net quantity (NetTaskQuantity or NetOutcomeQuantity), which can be negative when a failed outcome creates more cleanup toil than value. When OutcomeUnit is a discrete count (e.g., 'deflected_tickets'), friction and rework measured in time cannot be subtracted from it directly; they are recorded in the Task table in time units and monetized in Value as a separate, negative value claim.

2.5 Value Lifecycle

The Value dataset separates operational measurement from financial recognition.

2.5.1 Multi-Stakeholder Claims (ValueClaimId & StakeholderRoleName)

A single verified Outcome can be valued through different executive lenses (e.g., CFO cost reduction, CTO engineering velocity, CISO risk avoidance) using a governed ConversionMultiplier. These claims are alternative lenses on one result, not additive value: RealizedValue must never be summed across StakeholderRoleName claims for the same OutcomeId. Portfolio KPIs are segmented by StakeholderRoleName or restricted to a single designated claim per Outcome.

2.5.2 Recognition Status (ValueStatus)

Distinguishes between 'Reported' value (notional productivity capacity returned to employees or estimated operational benefit) and 'Booked' value (hard-dollar budget reductions, vendor contract savings, or realized revenue margin verified by FP&A in a specific General Ledger or Cost Center destination). Booked value must also be attested: AttestorId, AttestorRoleName, and AttestedDateTime record who verified the claim, in what role, and when. The attestor's role must differ from the claimant's StakeholderRoleName, so no team grades its own homework. Each attestation covers the claim's current ValueStatus and RealizedValue; Reported value may remain unattested.

When an Outcome is valued in revenue, the claim should record contribution margin rather than gross revenue, as in the ConversionMultiplier example of $42.00 margin per order. A claim at gross revenue would make Net Workload Economic Margin and ROI subtract only the workload's own costs, not the cost of producing that revenue, and overstate the return.

2.5.3 Lifecycle Valuation (PlannedValue, EstimatedValue, RealizedValue)

Allows organizations to compare budgeted business-case projections (PlannedValue) and in-flight accruals (EstimatedValue) against post-settlement audited worth (RealizedValue). Outcomes still inside their settlement window at an accounting close carry EstimatedValue with a NULL RealizedValue, and settle into RealizedValue once the settlement window set by the line of business closes, at which point FP&A books RealizedValue against the net Outcome as of that date (OutcomeCutoffDateTime). An amending entry that arrives after a claim is booked does not restate it; it produces an adjusting claim, which may be negative, in the current period. Comparing PlannedValue with RealizedValue also closes the loop between measurement and investment: the result an owner asserts when work is funded becomes the benchmark for the next funding decision.

2.6 Attribution Modes

Not every workload needs request-level attribution. Billing data typically arrives daily while AI requests arrive by the second, so attributing every request to a specific Task or Outcome requires streaming lineage metadata and considerably more processing. The schema therefore supports two attribution modes, chosen per workload. They differ in precision and cost, not in structure, and neither is a stage on the way to the other.

2.6.1 Cohort Mode

Each workload is treated as its own Task and Outcome over a monthly window, with TaskId and OutcomeId set to a cohort identifier that combines the WorkloadId and the window (for example, 'coding_agent_2026_10'). Telemetry is attributed at the workload level from aggregate metrics, and Outcome rows record cohort volumes in AttemptedOutcomeCount and QualifiedOutcomeCount. It suits workloads whose decisions are made at the workload level, such as whether to keep funding a capability.

2.6.2 Atomic Mode

TaskId and OutcomeId are recorded per request, either stamped on telemetry or linked afterward through the Task dataset, so cost is attributed to individual Tasks and Outcomes. It suits workloads whose decisions depend on individual results, such as which kinds of tasks are worth automating.

Choose each workload's mode by the decision it informs, and invest in precision only where that decision depends on it. A portfolio will usually mix modes. Every mode produces the same five datasets, so KPIs remain comparable across them.