Standard Reports — the Linux Foundation backlog
Status as of 2026-08-06. Nine Standard Reports are published and all of them are now free
(see PAPER-TYPES.md §3). This file is the ranked backlog of the specifications named in the API
Evangelist Linux Foundation inventory (research/linux-foundation/standards.md, captured 2026-06-30)
that do not yet have a report.
It exists because the LF inventory implies twenty-one more reports and the honest constraint is not
writing time — it is evidence. A Standard Report’s spine is the coalition graph and the
claim-versus-ship gap, and those come from the pipeline-standards skill having profiled the body
first. Writing the prose without that step produces opinion with a price tag on it, which is the one
thing this line cannot be.
Published (9) — all free
| Report | Standard | Version |
|---|---|---|
the-camara-standard |
CAMARA | 1.1 |
the-openapi-standard |
OpenAPI | 1.1 |
the-asyncapi-standard |
AsyncAPI | 1.1 · published: false, held for a wording revision since 2026-08-01 |
the-json-schema-standard |
JSON Schema | 1.0 |
the-mcp-standard |
Model Context Protocol | 1.0 |
the-openid-connect-standard |
OpenID Connect | 1.0 |
the-oauth-2-standard |
OAuth 2.0 | 1.0 |
the-ard-standard |
Agentic Resource Discovery | 1.0 |
the-a2a-standard |
Agent2Agent | 1.0 · new 2026-08-06 |
The evidence constraint
Only two bodies have a full pipeline-standards profile in all/<slug>/ — people/,
companies/, leads/, governance/, taxonomy/, working-groups/, releases/, repositories/:
| Body | Profile state |
|---|---|
openapi-initiative |
complete |
asyncapi |
complete |
json-schema |
partial — releases/ + repositories/ only |
camara, cncf, openssf, linux-foundation, oci, open-container-initiative, spdx, openchain, grpc, cloudevents, opentelemetry, spiffe, openfeature, sigstore, in-toto, tuf, notary, graphql, openjs-foundation, envoy |
none |
So every row below carries a prerequisite, and for most of them it is a pipeline-standards run.
The four reports already shipped without a full profile (MCP, ARD, OAuth, OIDC, A2A) worked because
their spine was a corpus measurement the catalog could supply directly — security schemes across
14,195 OpenAPI documents, or a well-known-path probe across 22,341 hosts. That is the pattern to
look for when ranking: a report is cheap when the catalog can already measure the adoption gap.
Ranked backlog (21)
Ranked by (value of the finding) × (evidence already in hand). Tier 1 is measurable now.
Tier 1 — the catalog can already measure the gap
| # | Standard | Slug | Why it ranks here | Prerequisite |
|---|---|---|---|---|
| 1 | Arazzo | the-arazzo-standard |
OpenAPI Initiative sibling at 1.1.0. The catalog holds first-party Arazzo artifacts and the arazzo-workflows-initiative work has a corpus. Adoption is measurable today, and the finding writes itself: a workflow spec whose adoption is almost entirely one author’s. |
Count all/*/arazzo/ first-party vs derived |
| 2 | OpenAPI Overlay | the-overlay-standard |
1.1.0, and API Evangelist has published a whole series on Overlay use cases plus a tooling-support survey. Tooling adoption is the spine and the survey exists. | Re-run the tooling survey as a table |
| 3 | GraphQL | the-graphql-standard |
The one major description standard with no JSON metaschema — a grammar, not a schema. That is a genuine finding against the JSON-Schema-is-the-connective-tissue thesis, and the catalog holds all/*/graphql/ artifacts to size adoption. |
Count graphql/ artifacts; GraphQL Foundation governance |
| 4 | CloudEvents | the-cloudevents-standard |
CNCF graduated at 1.0.2, and the AsyncAPI report already found the protocol reality (https/webhooks 422, wss 311, against Kafka 11 / AMQP 7 / MQTT 6 / NATS 4). CloudEvents is the envelope those events should carry and almost certainly do not. Strong pairing. | Probe catalog event artifacts for CloudEvents attributes |
| 5 | gRPC + Protocol Buffers | the-grpc-standard |
One report, both specs — Protobuf is the IDL and is not LF-governed, which is itself the finding: the largest binary API surface in the industry depends on a schema language outside the foundation that governs everything around it. | Count .proto artifacts across all/* |
Tier 2 — needs a pipeline-standards run, high value
| # | Standard | Slug | Why it ranks here | Prerequisite |
|---|---|---|---|---|
| 6 | SPDX | the-spdx-standard |
ISO/IEC 5962. The LF’s flagship ISO play and the SBOM format everything else points at. The claim-versus-ship gap is directly measurable: who says SBOM, who serves one. | pipeline-standards spdx |
| 7 | OCI (three specs) | the-oci-standard |
Image 1.1.0, Runtime 1.3.0, Distribution 1.1.0. The Distribution spec ships an OpenAPI — a standards body describing its own HTTP API in the format it asks everyone else to use, which is the counter-example to the recurring finding in the OpenAPI report. | pipeline-standards open-container-initiative |
| 8 | SLSA | the-slsa-standard |
OpenSSF, 1.0, and the levels are prose while the provenance is in-toto JSON. A levels-versus-attestations gap that nobody has counted. | pipeline-standards openssf |
| 9 | Sigstore | the-sigstore-standard |
Protobuf bundle format, OpenSSF. Pairs with SLSA and Notary as the signing trio; strongest when all three are profiled together. | pipeline-standards openssf |
| 10 | in-toto | the-in-toto-standard |
The attestation envelope under SLSA and Sigstore both. Best written after those two so it can be the connective piece. | pipeline-standards in-toto |
| 11 | OpenTelemetry / OTLP | the-otlp-standard |
OTLP 1.10.0, Protobuf, and the most widely deployed telemetry contract in existence. Adoption is high, which makes it the useful positive control against the failures in the rest of the series. | pipeline-standards opentelemetry |
| 12 | SPIFFE | the-spiffe-standard |
Graduated CNCF, and the workload-identity layer under every authorization finding in the OAuth and OIDC reports. The agentic angle is live: identity for callers nobody logged into. | pipeline-standards spiffe |
| 13 | TUF | the-tuf-standard |
Graduated, oldest spec in the supply-chain set, and the most frequently reinvented badly. A “why does everyone rebuild this” report. | pipeline-standards tuf |
| 14 | OSV Schema | the-osv-standard |
OpenSSF JSON format with real consumer adoption in scanners. Measurable: which ecosystems publish OSV records and which still ship prose advisories. | pipeline-standards openssf |
Tier 3 — narrower, or the finding is thinner
| # | Standard | Slug | Why it ranks here | Prerequisite |
|---|---|---|---|---|
| 15 | Notary Project | the-notary-standard |
1.1.0 signature spec. Real, but best folded into the signing trio unless it earns its own. | pipeline-standards notary |
| 16 | OpenFeature | the-openfeature-standard |
Incubating. OFREP has an OpenAPI, which is a nice detail. Feature flags as undocumented contract surface is a good argument with a small corpus. | pipeline-standards openfeature |
| 17 | OpenMetrics | the-openmetrics-standard |
1.0.0 with 2.0 experimental. Largely subsumed by the Prometheus exposition format in practice; the finding is mostly “this won by being absorbed”. | pipeline-standards openmetrics |
| 18 | xDS | the-xds-standard |
The largest production Protobuf API surface most teams never look at. Genuinely interesting, but the audience is narrow and adoption is hard to measure from outside. | pipeline-standards envoy |
| 19 | OpenChain | the-openchain-standard |
ISO/IEC 5230 + 18974, and the only process standard in the set — there is no artifact to parse. Would have to be written differently from every other report in the line, which is either the reason to do it or the reason not to. | Public conformance registry |
| 20 | Service Mesh Interface | — | Archived. Not worth its own report, but it is the best available case study of a standard that failed by setting its ceiling below what its adopters needed. Recommend folding it into a Market Report or a blog post rather than a Standard Report. | none |
| 21 | JSON Schema (IETF revival) | — | Not a new report — a version bump to the-json-schema-standard once the new IETF working group (charter-ietf-jsonschema) produces something. The existing report’s finding is that the spec was never ratified; that may be about to change. |
Watch the IETF WG |
Sequencing recommendation
- Tier 1 first, in order. Five reports whose spine the catalog can already measure. No
pipeline-standardsruns needed, so they ship at roughly the cadence of the writing. - Then one
pipeline-standardscampaign coveringopenssf+spdx+open-container-initiative. That single campaign unlocks rows 6–10 and 14 — six reports off three profile runs, because the supply-chain specs share a coalition. - Restore
the-asyncapi-standard. It is written, it is free, and it is currentlypublished: false. Finishing the wording revision is the cheapest report in the backlog. - Then the remaining Tier 2, each behind its own profile run.
- Tier 3 opportunistically, and drop rows 20 and 21 from the report line entirely — one is a blog post, the other is a version bump.
Rules that apply to every row
- No report without evidence. If the coalition graph is not harvested, the report says so
explicitly, in its own section, the way
the-a2a-standard§5 does. It does not guess. - Every Standard Report is free.
price: "0.00"andfree: truein the teaser; no Stripe price. SeePAPER-TYPES.md§3 for the full mechanic and whatscripts/check-paywall.shenforces. - Two-way linking is mandatory. A
papers:entry on the standard’sapi-evangelist/standards/_store/<slug>.md, and a “Standards referenced in this report” section in the paper. - Then run
standards-from-paperso the catalog learns from the report.