Reading the spec like a practitioner.

4.1 — Spec overview & versioning

The FinOps Open Cost and Usage Specification (FOCUS) is an open technical specification for technology-related billing data. It defines clear requirements that vendors follow to produce uniform cost and usage datasets and provides a common vocabulary for describing consumption-based billing models.

The specification is shaped by real-world feedback. Each version reflects what practitioners struggled with, where definitions needed clarity, and which new capabilities solve real problems.

Version history

This course uses v1.2 as the working example, but always refer to the version your provider actually publishes (check provider versions).

4.2 — Three audiences for the spec

• FinOps Practitioners — Use the spec to understand FOCUS-format datasets and apply them to FinOps Capabilities.
• FOCUS Data Generators — CSPs, SaaS vendors, ISVs who build FOCUS datasets. They must generate data that meets the requirements.
• FinOps Vendors — Consume and display billing data to assist customers. They use the spec to map data to FOCUS terminology in their applications.

4.3 — Three kinds of text

Normative text

Normative text defines the rules a data generator must follow to produce a conformant dataset. Normative keywords appear in ALL CAPITALS:

• MUST / MUST NOT
• REQUIRED
• SHALL / SHALL NOT
• SHOULD / SHOULD NOT
• RECOMMENDED / NOT RECOMMENDED
• MAY
• OPTIONAL

Interpreted per BCP 14 (RFC 2119 / RFC 8174). A lowercase “should” is not normative.

Non-normative text

Sections marked “This section is non-normative” don’t define rules — they give context that helps you understand why the rules exist.

Supporting content (the part everyone misses)

The FOCUS GitHub repository ships an open Supporting Content directory alongside the spec itself. It’s where the working group records the reasoning behind a rule, worked examples, edge-case clarifications, and the discussions that led to a particular wording. The spec tells you what is required; supporting content tells you why — which is what you need when a teammate or auditor asks “but what does this mean?”

• Supporting Content folder (working_draft) — per-column markdown explaining the rationale and worked examples.
• FOCUS_Spec repository — full source for the spec, all branches, all open and closed issues.
• FinOps-Open-Cost-and-Usage-Spec org — the umbrella GitHub organisation, including converters and the validator.

Practical habit: when the spec text confuses you on a column, search the matching markdown file in supporting_content/. It usually answers your question with a worked example.

4.4 — Anatomy of a column entry

When you look at a column definition in the spec, you’ll see three labelled parts:

• Title & Non-Normative Description — the explanation of the column. Aids understanding.
• Normative Text — the official, formal requirements.
• Breakout of Column Details — helpful text that further explains the requirements.

The Requirements Analyzer

The FOCUS specification includes over 600 requirements. The Requirements Analyzer makes them searchable. Filter by function type (composite, format, nullability, presence) or by keyword (MUST, SHOULD, MAY). Trace any failed validator rule back to the specific requirement.