The Specification Layer

Most of what an API is built on is decided in a small number of specification repositories and the working-group calls around them. API Evangelist reads 52 specifications every week, from the Linux Foundation and its foundations — CNCF, OpenSSF, FINOS, LF AI & Data, the Agentic AI Foundation, LF Decentralized Trust, NeoNephos — plus the few non-LF pieces they depend on, and reports what actually changed.

The newsletter

The Specification Layer is a Monday read on the contracts, not the commentary: what merged into these specifications in the past week, what was released, what was decided on the calls, and what didn't move. Every issue reports the share of changes made by people rather than bots, grades the predictions it made the week before, and corrects itself in the open when it gets something wrong. It is built from 52 repositories and 25 foundation feeds, and from the working-group meetings those groups record or publish notes for.

Read the archive · Latest issue: OpenAPI 3.3 Learned to Say What It Depends On

What we track

46 specifications form the core series compared week over week. 6 more are added — newer or narrower, reported alongside the core and never folded into its numbers. Each links to its repository and, where we have one, its entry in this catalog. The list is generated from the newsletter's own registry (2026-10-26).

The Description Layer 12

How APIs are described: contracts, workflows, overlays, schemas.

AI & Agents 10

How agents find, describe, call and are held accountable for what they do.

Events, Telemetry & the Data Plane 8

Event formats, registries, telemetry and the proxies traffic runs through.

Identity, Policy & Data Rights 4

Workload identity, feature flags, policy languages and personal data.

Supply Chain & Artifacts 14

Software bills of materials, attestations, signing, vulnerabilities, containers.

Financial Services 4

Desktop interoperability, architecture as code, domain models, payments.

Release-Path Dependencies 2

Not specifications — the tooling the specifications are published through.

The alignment work

Reading the repositories is half of it. The other half is showing up — in the calls, in the discussions, and in the places where these specifications have to fit together for the people building on them. What that has meant recently, each linked to its public record:

• Being in the rooms. I attend the OpenAPI community, Overlays and Arazzo calls, the A2A AI Catalog working group, MCP working groups and OpenLint's office hours, and I write up what I learn so others can follow along — Three Specification Calls in One Thursday.
• Funding the specifications we depend on. A public, working list of companies that build on OpenAPI, Arazzo and Overlays and are not members of the OpenAPI Initiative — If You Depend On OpenAPI Please Become a Member.
• One front door, not many. Agent protocols are converging on how a domain advertises what it offers — MCP Server Cards and A2A's draft both point at the AI Catalog, while Personal Agent Protocol defines its own file. We map every /.well-known/ path in use on the Well-Known URIs page, wrote about two front doors in one week, and requested IANA registration of /.well-known/apis.json (#109) after defining it in APIs.json 0.24.
• Measuring adoption, not announcements. We probe the APIs.io catalog for what providers actually publish — the first Personal Agent Protocol files, OpenAPI 3.2 support across tooling, and the well-known folder.
• Keeping specifications small and composable. On what Overlays are for, I argued in discussion #412 that an overlay is a layer, not a diff — An Overlay Is a Layer, Not a Diff.
• Governance that runs on open rules. We follow OpenLint — the community fork of Spectral — alongside policy languages like Cedar and Open Policy Agent, because how APIs are governed is becoming a specification problem of its own.

This page is built by PLANNING/build-specification-layer.py from the newsletter's registry. If a specification you maintain or depend on belongs here, tell us.