OASA ↔ FOCUS 1.4 Mapping

Status: Draft 0.2 · 2026-10-22 · companion to OASA 0.1.3 · License CC BY 4.0 Scope: FOCUS 1.4 Cost and Usage dataset (65 columns) and Invoice Detail dataset; notes on FOCUS 1.5 token tracking Repository: github.com/onaro-io/agent-spend-attribution · docs/focus-mapping.md

1. Purpose

FOCUS answers what was billed. OASA answers which agent, on whose behalf, against which cost object, and what the books should say. This document specifies how the two join, column by column, so that:

• a FOCUS dataset from any provider or FinOps platform can be ingested as OASA charge records with no transformation beyond field renaming;
• an OASA ledger can be exported as a FOCUS-conformant dataset, with attribution carried in x_-prefixed custom columns per FOCUS 1.4 Custom Column Handling;
• a controller can trace any GL line → OASA record → FOCUS row → invoice line.

OASA is additive to FOCUS. Nothing here redefines a FOCUS column; where OASA carries a FOCUS value, the FOCUS semantics apply unchanged.

2. Join model

Three record types participate.

A mapping record is not a FOCUS cost row and is not written into a FOCUS cost dataset.

focus_charge_ref is a provider-neutral pointer. Recommended form: focus:<dataset-id>:<row-key> where row-key is the data generator's stable row identifier when one exists, else a hash of (BillingAccountId, ChargePeriodStart, SkuPriceId, ResourceId, SubAccountId).

3. Column mapping: FOCUS 1.4 Cost and Usage → OASA

Treatment codes: Carried = value copied into an OASA field with identical semantics. Derived = OASA field computed from the column, or vice versa, under a stated rule. Referenced = stays on the FOCUS row, reachable through focus_charge_ref; not needed for attribution or booking.

Summary: 14 carried, 12 derived, 39 referenced. Nothing in FOCUS 1.4 Cost and Usage is lost; 39 columns simply stay where they are.

4. Token economics

FOCUS 1.4 expresses token consumption through existing columns rather than token-specific ones: ConsumedQuantity with ConsumedUnit = Tokens, PricingUnit (e.g. 1M Tokens), and SkuMeter distinguishing input, output, cached-input and reasoning meters. FOCUS 1.5 (scheduled December 2026) is expected to add native token tracking and a Price Sheet dataset; this section will be revised when it ratifies.

Consequences for the join:

• One provider request produces one OASA usage record carrying input_tokens, output_tokens, cached_tokens, reasoning_tokens, and up to four FOCUS rows, one per SkuMeter. The OASA charge records rated from that usage keep the per-meter split; units_consumed on each charge equals the FOCUS ConsumedQuantity for that meter.
• pricing_ref on an OASA record should hold the FOCUS SkuPriceId when the provider is the price source, so the rate used for a rated cost can be audited against the provider's ListUnitPrice.
• cost_source makes the FOCUS relationship explicit: invoiced means billed_cost came from a FOCUS row; rated means OASA priced metered usage before any FOCUS row existed; measured means cost was observed at the gateway.

5. ChargeCategory and ChargeClass

6. Invoice Detail dataset (FOCUS 1.4) and settlement

FOCUS 1.4 adds an Invoice Detail dataset: InvoiceId, InvoiceDetailId, InvoiceIssueDate, InvoiceIssueStatus, PaymentDueDate, PaymentTerms, PaymentCurrency, PaymentCurrencyBilledCost, PurchaseOrderNumber, ReferenceInvoiceId, plus billing-period and issuer columns. It describes the invoice; it does not record that money moved.

7. Allocation: FOCUS Allocated* columns and OASA allocation records

FOCUS 1.3 introduced data-generator-calculated split cost allocation (AllocatedMethodId, AllocatedMethodDetails, AllocatedResourceId, AllocatedResourceName, AllocatedTags) for cases where the provider splits a charge. OASA allocation records cover the far more common case where the practitioner splits a charge across cost objects after the fact.

When Onaro, or any OASA implementation, publishes a derived FOCUS dataset, OASA allocation records serialize into the Allocated* columns: allocation_rule_id → AllocatedMethodId; the split factors and split_fraction → AllocatedMethodDetails.Elements; the cost object → AllocatedResourceId/Name; allocation-time tags → AllocatedTags. The original provider row is preserved as the origin charge, with the unallocated remainder, if any, as its own row per FOCUS rules.

8. What FOCUS does not carry

These OASA groups have no FOCUS equivalent and travel as x_ columns on export.

9. Exporting OASA as a FOCUS-conformant dataset

An OASA ledger can be published as a FOCUS 1.4 Cost and Usage dataset so that any FOCUS-consuming tool can read attributed agent spend. Rules:

1. Every FOCUS Mandatory column is populated from the Carried and Derived mappings in §3; Referenced columns are copied from the source FOCUS row when one exists, else null per FOCUS nullability rules.
2. Attribution fields are emitted as custom columns with the x_oasa_ prefix, per FOCUS 1.4 Custom Column Handling: x_oasa_record_id, x_oasa_agent_id, x_oasa_agent_name, x_oasa_trace_id, x_oasa_task_type, x_oasa_cost_center, x_oasa_project_id, x_oasa_customer_id, x_oasa_cost_source, x_oasa_budget_id, x_oasa_settlement_ref, x_oasa_reconciliation_status, x_oasa_attribution, x_oasa_unattributed_reason. x_oasa_attribution is the attribution object as one JSON value, so the dataset does not grow by one column per provenance member. x_oasa_unattributed_reason is present when the reason is set.
3. Self-hosted inference (cost_source = rated, no provider row) is emitted with ServiceProviderName = the organization's own name, ChargeCategory = Usage, PricingCategory = Standard, and x_oasa_cost_source = rated, so it sits beside provider charges in the same dataset. This is the only case where OASA originates a FOCUS row rather than referencing one.
4. The dataset metadata declares the x_oasa_* columns per FOCUS schema metadata requirements.

10. Worked example

One request by a support agent, 1,200 input tokens, 340 output tokens, 800 cached tokens, OpenAI, September 1. All costs and rates in this example are illustrative and do not represent any provider's current pricing.

FOCUS 1.4 Cost and Usage, three rows (abridged)

OASA usage record (one): agent_id agent-support-47, trace_id 4bf9…, task_type ticket_resolve, input_tokens 1200, output_tokens 340, cached_tokens 800, cost_source measured, cost_center Customer Success.

OASA charge records (three): one per FOCUS row, each with focus_charge_ref = focus:openai-2026-09:L-8842x, invoice_id INV-2026-09-01, list_cost/billed_cost/effective_cost copied, units_consumed = that row's ConsumedQuantity, agent_id and cost_center inherited from the usage record via trace_id (method inherited on those fields).

Resulting GL line: AI services expense, Customer Success, $0.0061, with an audit trail of GL line → 3 OASA charges → 3 FOCUS rows → invoice INV-2026-09-01 lines L-88421 to L-88423.

Note the asymmetry the example shows: FOCUS tells you 1,540 tokens cost $0.0061 on proj_support; only the OASA side says which agent, which ticket, and which department's budget.

10b. Worked example: cloud-hosted model with provider-side attribution (Amazon Bedrock)

The OpenAI example above is a direct provider invoice with no attribution in the billing data. Bedrock is the other case: the provider carries a practitioner tag onto the billing row, so attribution exists upstream and OASA's job is to read it, not reconstruct it. All costs are illustrative. The AWS-side setup (inference profiles, cost allocation tag activation, IAM enforcement) and the month-end entries are covered in How do I allocate Amazon Bedrock costs by department?

One request through an application inference profile tagged oasa_cost_center=cc-4100, 4,000 input tokens and 900 output tokens, September 1. The profile serves more than one agent, so the row has no oasa_agent tag. A mapping record binds the profile ARN to agent_id support-triage.

FOCUS 1.4 Cost and Usage, two rows (abridged, from the AWS FOCUS-format export)

OASA charge records (two): one per row; provider = Amazon Web Services, service = Amazon Bedrock, focus_charge_ref to each row, cost_source = invoiced, units_consumed = that row's ConsumedQuantity. cost_center is cc-4100, declared, identity type aws.bedrock.inference_profile_tag, identity value oasa_cost_center. agent_id is support-triage, mapped from the profile ARN. The tag is also copied to tags. A golden record for the input-token row is examples/charge-declared-tag-mapped-agent.json.

Rules this example sets

• A convention key in Tags declares the field. The names the spec defines are oasa_cost_center, oasa_agent, oasa_owner, and oasa_project. identity_value is the key. The tag value is the common field.
• An implementation MAY accept a configured alias, such as an existing key CostCenter or Agent. An accepted alias is still declared, and identity_value is the key on the row.
• ResourceId becomes agent_id as declared only when the resource is the agent. When one profile serves several agents, a mapping record may set agent_id (mapped) while the convention tag still declares cost_center.
• A row with no convention key, no accepted alias, and no usable ResourceId or SubAccountId has no common field. The reason is tag_missing or no_identity. It is not given a default cost center.
• HostProviderName = ServiceProviderName here; for a marketplace-hosted third-party model on Bedrock the two differ, and OASA keeps provider = the service provider while referencing the host.

Resulting GL line: AI services expense, cost center cc-4100, $0.0255, with the audit trail GL line → 2 OASA charges → 2 FOCUS rows → inference profile ARN → the oasa_cost_center tag on the bill and the mapping record for the agent.

Where the OpenAI example shows OASA adding attribution that billing lacks, this one shows OASA preserving attribution that billing already has, and making the untagged remainder visible rather than smearing it.

11. Open questions for the FinOps Foundation FOCUS working group

1. When FOCUS 1.5 ratifies native token tracking, should per-meter token counts collapse to one row with typed columns (as OASA models them), or remain one row per SkuMeter? OASA can map either; the choice affects every AI cost dataset's row count by 3–4×.
2. SubAccountId is the closest FOCUS has to a practitioner cost object. For AI providers, is a provider project or workspace an appropriate sub-account, and should FOCUS guidance say so?
3. Is there appetite for a standardized actor dimension (agent or service identity) in a future FOCUS release, or is that correctly left to x_ columns and specifications like OASA?
4. Self-hosted inference has no data generator. Should FOCUS guidance address organization-originated rows for owned infrastructure, or is that out of scope by design?

12. Changelog

• 0.2 (2026-10-22): convention keys declare common fields; a tag key on the row is declared and a mapping record is mapped. Per-field provenance exports as x_oasa_attribution. Companion to OASA 0.1.3.
• 0.1 (2026-10-05): initial draft against FOCUS 1.4 (June 2026) and OASA 0.1.1.

This mapping is published by Onaro (BrianOnAI LLC) under CC BY 4.0. FOCUS™ is a trademark of the FinOps Foundation; referencing it does not imply endorsement.