# UFMS:001:2026 **IFO4 Universal Financial Metadata Schema, v1.0** --- Spec ID: UFMS:001:2026 Version: 1.0.0 Publisher: IFO4 Standards Council Adopted: 2026-04-25 License: CC BY 4.0 Hard enforcement: 2026-05-25 Audit retention: 730 days --- ## Foreword UFMS:001:2026 is the third standard published by the International Federation for Financial Operations (IFO4), following RING:1000:2026 and TGS:001:2026. It defines a universal financial-metadata schema for cloud resources: a single set of labels every IFO4 member organization applies to every resource it provisions, in every cloud, regardless of vendor. The motivation is plain. In 2026, the average enterprise FinOps team spends more time reconciling tag conventions across business units, clouds, and tools than it spends optimizing cost. The status quo guarantees three failure modes: orphan spend (no cost-center label), miscategorized spend (each cloud uses a different key for "Application"), and untraceable spend (a workload's lifecycle is not recorded as a property of the workload). UFMS removes all three. This document is the canonical spec. It is published under CC BY 4.0 so any organization can adopt it without negotiation, and any tool can be built against it without licensing friction. --- ## 1. Cover ### 1.1 What UFMS gives you - 10 required tags. Every cloud resource must carry all ten. - 7 optional security tags, each with a sane default that the auto-tagger applies when a resource enters production. - 6 lifecycle states, with a directed transition graph that never loops backward into "decommissioning". - 4 crosswalks (FOCUS v1.0, AWS, Azure, Kubernetes) plus the GCP reference implementation. - A reference validator with three runtimes (CLI, TypeScript, Python). - A conformance attestation flow leading to the publicly-listed UFMS-Compliant badge. ### 1.2 Compliance horizon | Date | Milestone | |----------------|------------------------------------------| | 2026-04-25 | UFMS:001:2026 adopted by IFO4 Council | | 2026-05-25 | Hard enforcement begins. CI gates on | | 2027-04-25 | First annual re-attestation cycle ends | | Annually | Re-attestation required to stay listed | --- ## 2. Schema UFMS defines two tag families: required and optional. ### 2.1 Lexical rules - Keys: lowercase ASCII, underscore-separated. - Values: lowercase ASCII, hyphen-separated. - Required prefix on every key: `ifo4_`. - Maximum key length: 63. - Maximum value length: 63. - Encoding: ASCII only. Unicode values are rejected by the validator. ### 2.2 Required tags (ten) | Key | Name | Format | Validation | Inheritable | |-----------------|------------------|--------------|-----------------------------|-------------| | ifo4_cc | Cost Center | cc-NNNN | `^cc-[0-9]{4}$` | no | | ifo4_org | Organization | org-slug | `^[a-z][a-z0-9-]{1,30}$` | yes | | ifo4_app | Application | app-slug | `^[a-z][a-z0-9-]{1,30}$` | yes | | ifo4_svc | Service | svc-slug | `^[a-z][a-z0-9-]{1,40}$` | no | | ifo4_owner | Owner | handle | `^[a-z][a-z0-9-]{1,30}$` | yes | | ifo4_env | Environment | enum | production, staging, qa, dev, sandbox, ephemeral | yes | | ifo4_platform | Platform | constant | ifo4 | yes | | ifo4_lifecycle | Lifecycle State | enum | new, ramping, existing, optimizing, migrated, decommissioning | no | | ifo4_product | Product | product-slug | `^[a-z][a-z0-9-]{1,30}$` | yes | | ifo4_unit | Unit Metric | unit-slug | enum (see registry) | no | #### 2.2.1 Per-tag semantics - **ifo4_cc** is the atomic financial accountability unit. Every dollar lands here. Cost centers are four-digit codes, prefixed `cc-`, owned by a named executive. - **ifo4_org** is the top-level legal entity / billing org. It is stable across rebrands. A subsidiary that re-prices into a parent organization should be modeled with a single `ifo4_org` and differentiated via `ifo4_app`. - **ifo4_app** is the logical business application. May span many services. Inheritable from the project / folder level. - **ifo4_svc** is the concrete deployable component within an application. Always per-resource, never inherited. - **ifo4_owner** is the engineering owner. Format is a `handle`, mapped to a human in the people registry. Surface this in incident responses. - **ifo4_env** drives FinOps allocation rules and access policy. The six values are `production`, `staging`, `qa`, `dev`, `sandbox`, `ephemeral`. No new environment values may be added without a UFMS revision ballot. - **ifo4_platform** is `ifo4` for IFO4-managed resources. It exists to enable cross-tenant joins in shared dashboards. - **ifo4_lifecycle** is the single tag that drives commitment vs on-demand pricing decisions and right-sizing cadence. See section 3. - **ifo4_product** attributes spend to a customer-facing product line. Used for revenue attribution and product P&Ls. - **ifo4_unit** is the metric you count to compute cost-per-unit. Drives the `unit_metrics` view in your warehouse. ### 2.3 Optional security tags (seven) | Key | Default | Allowed values | |--------------------|--------------------|----------------| | ifo4_data_class | internal | public, internal, confidential, restricted, regulated-pii, regulated-phi, regulated-pci | | ifo4_compliance | none | none, soc2, iso27001, hipaa, pci-dss, fedramp-low, fedramp-moderate, fedramp-high, gdpr, ccpa | | ifo4_residency | us | us, eu, uk, ca, au, br, in, global, us-eu-only | | ifo4_carbon | compute | compute, storage, network, database, ai-inference, ai-training, egress | | ifo4_chargeback | shared | shared, dedicated, showback, billback, internal-only | | ifo4_dr_tier | tier-2 | tier-0, tier-1, tier-2, tier-3, best-effort | | ifo4_managed_by | ufms-auto-tagger | terraform, cloud-build, cloud-run-deploy, manual, ufms-auto-tagger | These are inferred by the auto-tagger when absent. They become required when the resource enters a regulated lane (HIPAA, PCI, FedRAMP). --- ## 3. Lifecycle Six states. Twelve allowed transitions. One direction of gravity. ### 3.1 The state machine ``` new ----> ramping ----> existing ----> optimizing | | | | v v v v +--------> +--------+---> migrated | | | | v v v decommissioning <-------------+ ``` ### 3.2 State semantics | State | Age window | Pricing policy | |-----------------|----------------|-------------------------------| | new | 0-30 days | On-demand only | | ramping | 30-90 days | No CUDs yet | | existing | 90+ days | Eligible for CUDs | | optimizing | review window | Look-back snapshots required | | migrated | source frozen | +30 days to decommission | | decommissioning | shutdown queue | Block new commits | ### 3.3 Allowed transitions - new -> ramping - new -> decommissioning (cancellation) - ramping -> existing - ramping -> optimizing - ramping -> decommissioning - existing -> optimizing - existing -> migrated - existing -> decommissioning - optimizing -> existing - optimizing -> migrated - optimizing -> decommissioning - migrated -> decommissioning A workload that has entered `decommissioning` cannot leave it. To revive it, you must create a new resource in `new`. --- ## 4. Crosswalks ### 4.1 FOCUS v1.0 (FinOps Open Cost and Usage Specification) | UFMS key | FOCUS column | |------------------|-------------------------------------------------| | ifo4_cc | BillingAccountId / SubAccountId | | ifo4_app | ResourceCategoryGroup / ServiceCategory | | ifo4_svc | ServiceName | | ifo4_env | Tags['environment'] | | ifo4_unit | PricingUnit / UsageUnit (where pricing is per-unit) | | ifo4_lifecycle | CommitmentDiscountStatus + custom | | ifo4_product | ProductName | ### 4.2 AWS tags | UFMS key | AWS legacy tag | |------------|----------------| | ifo4_cc | CostCenter | | ifo4_app | Application | | ifo4_svc | Service | | ifo4_owner | Owner | | ifo4_env | Environment | | ifo4_product | Product | Emit both: the canonical `ifo4_*` key and the legacy PascalCase alias. ### 4.3 Azure tags | UFMS key | Azure legacy tag | |------------|------------------| | ifo4_cc | CostCenter | | ifo4_app | Application | | ifo4_svc | ServiceName | | ifo4_owner | Owner | | ifo4_env | Environment | | ifo4_product | Product | ### 4.4 GCP labels (reference implementation) GCP labels round-trip 1:1 with UFMS keys. No translation layer needed. ### 4.5 Kubernetes labels | UFMS key | Kubernetes label | |----------------|---------------------------------| | ifo4_cc | ifo4.org/cost-center | | ifo4_app | app.kubernetes.io/part-of | | ifo4_svc | app.kubernetes.io/name | | ifo4_env | ifo4.org/environment | | ifo4_owner | ifo4.org/owner | | ifo4_lifecycle | ifo4.org/lifecycle | | ifo4_unit | ifo4.org/unit | | ifo4_product | ifo4.org/product | --- ## 5. Validator The reference validator runs the same regex and enum checks across three runtimes. ### 5.1 CLI ``` brew install ifo4/tap/ufms-validate # or curl -fsSL https://get.ifo4.org/ufms | sh ufms-validate < labels.yaml ufms-validate --gcp-project ifo4-production ``` ### 5.2 Node / TypeScript ``` npm install @ifo4/ufms-validator import { validate } from '@ifo4/ufms-validator'; const result = validate({ ifo4_cc: 'cc-1011', ifo4_svc: 'matrix-advisor', // ... }); if (!result.ok) process.exit(1); ``` ### 5.3 Python ``` pip install ifo4-ufms from ifo4_ufms import validate result = validate({ "ifo4_cc": "cc-1011", "ifo4_svc": "matrix-advisor", }) assert result.ok, result.errors ``` ### 5.4 CI gate Drop the validator into Cloud Build, GitHub Actions, or GitLab CI. Any merge that ships a non-conforming label set fails before it deploys. ``` # cloudbuild.yaml steps: - name: gcr.io/cloud-builders/gcloud entrypoint: bash args: - -c - | curl -fsSL https://get.ifo4.org/ufms | sh ufms-validate \ --terraform-plan tfplan.json \ --fail-on-missing ``` --- ## 6. Adopt The recommended rollout is six weeks. Each step unblocks the next. ### Step 1 - Inventory and assign cost centers (Week 1) Pull the full account / project list from your cloud billing export. Map each one to a four-digit cost-center code (`cc-NNNN`). Park the registry in version control. ### Step 2 - Adopt the canonical key set (Week 2) Update Terraform / Bicep / Pulumi modules so every newly-provisioned resource carries the full UFMS label set. Use module defaults for the inheritable keys. ### Step 3 - Wire the validator into CI (Week 2) Run `ufms-validate` in pre-merge CI. Wire it into pull-request status checks. Configure it to read the Terraform plan JSON. ### Step 4 - Backfill existing resources (Weeks 3-4) Run the auto-tagger across all clouds. Review the dry-run diff with a human, then apply. Target less than 0.5% drift. ### Step 5 - Build the unit-cost view (Week 5) Join cost rows to traffic rows by `ifo4_unit`. Compute cost-per-unit nightly. Surface in a dashboard that finance and engineering both look at. ### Step 6 - Earn the badge (Week 6) Run `ufms-attest`, submit the proof, receive your registry listing within 5 business days. --- ## 7. Examples Five real production examples from IFO4. Real values from `standards/ufms/v1/services.json`. ### 7.1 matrix-advisor (AI workload, Cloud Run) ``` ifo4_cc: cc-1011 ifo4_org: ifo4 ifo4_app: matrix ifo4_svc: matrix-advisor ifo4_owner: derris ifo4_env: production ifo4_platform: ifo4 ifo4_lifecycle: new ifo4_product: matrix ifo4_unit: consultation ifo4_carbon: ai-inference ifo4_data_class: internal ifo4_compliance: soc2 ifo4_residency: us ``` ### 7.2 ifo4-primary (database, AlloyDB cluster) ``` ifo4_cc: cc-1013 ifo4_org: ifo4 ifo4_app: data ifo4_svc: alloydb-primary ifo4_owner: derris ifo4_env: production ifo4_platform: ifo4 ifo4_lifecycle: existing ifo4_product: ifo4-platform ifo4_unit: shared ifo4_data_class: confidential ifo4_carbon: database ifo4_dr_tier: tier-1 ``` ### 7.3 score_warehouse (BigQuery dataset) ``` ifo4_cc: cc-1012 ifo4_org: ifo4 ifo4_app: score ifo4_svc: score-warehouse ifo4_owner: derris ifo4_env: production ifo4_platform: ifo4 ifo4_lifecycle: existing ifo4_product: score ifo4_unit: score-snapshot ifo4_data_class: confidential ifo4_carbon: storage ``` ### 7.4 ifo4-platform-events (Pub/Sub topic) ``` ifo4_cc: cc-1001 ifo4_org: ifo4 ifo4_app: platform ifo4_svc: platform-events ifo4_owner: derris ifo4_env: production ifo4_platform: ifo4 ifo4_lifecycle: existing ifo4_product: ifo4-platform ifo4_unit: request ``` ### 7.5 ifo4-healthcare (regulated vertical, HIPAA) ``` ifo4_cc: cc-1008 ifo4_org: ifo4 ifo4_app: verticals ifo4_svc: ifo4-healthcare ifo4_owner: derris ifo4_env: production ifo4_platform: ifo4 ifo4_lifecycle: ramping ifo4_product: vertical-healthcare ifo4_unit: tenant ifo4_data_class: regulated-phi ifo4_compliance: hipaa ``` --- ## 8. Conformance and re-attestation To list as UFMS-Compliant: 1. Run `ufms-attest --org-slug --billing-export `. The tool samples your billing export and validates every line item. 2. Submit the resulting signed proof to the IFO4 Standards Council via `POST /api/ufms/attestations`. 3. Receive a registry listing within 5 business days. Re-attestation runs annually. Loss-of-conformance triggers a 30-day grace window before the listing is removed. --- ## 9. Revisions UFMS revisions are governed by the IFO4 Standards Council ballot process. Any organization on the registry may propose a revision. Proposals are open for public comment for 30 days before a Council vote. The first scheduled review is 2027-04-25. --- ## 10. Acknowledgments UFMS:001:2026 was authored by the IFO4 Standards Council Standards & Research working group, drawing on the FinOps Foundation FOCUS v1.0 specification, the AWS / Azure / GCP cloud-tagging best-practice docs, and the Kubernetes labels and selectors documentation. Names of contributors are recorded in the public ballot record. This spec is published under CC BY 4.0. Re-use, adapt, embed in your own standards. Just credit IFO4. --- End of UFMS:001:2026.