---
type: "article"
title: "The Specification Layer — Nine Days Without a Bibliography"
summary: "A maintainer cancelled a credit card he thought was unused. It was the one Heroku had on file for SpecRef — the bibliography database every ReSpec-built specification resolves its normative references against. For nine days no OpenAPI specification could be released, and I watched the OpenAPI TDC hit the wall live on Thursday's call. SpecRef came back on Saturday, moved to a new org, and its maintainer opened a governance issue this morning asking who should own it. Also: the OpenAPI validation schema accepts a version number written with a Bengali digit, and this time the defect really is in the published artifact. And 167 merges made this the first human-majority week — entirely because of two specifications I only started tracking eight days ago."
newsletter: "The Specification Layer"
newsletter_handle: "the-specification-layer"
newsletter_url: "https://usecommune.com/n/the-specification-layer"
author: "Kin Lane (@kinlane)"
published: "2026-09-07T13:53:05.424Z"
canonical_url: "https://usecommune.com/n/the-specification-layer/a/JRESmcPx"
markdown_url: "https://usecommune.com/n/the-specification-layer/a/JRESmcPx.md"
chat_url: "https://usecommune.com/n/the-specification-layer/a/JRESmcPx/chat"
body_source: "native"
likes: 0
replies: 0
body_words: 5393
---

# The Specification Layer — Nine Days Without a Bibliography

This is the fifth issue of The Specification Layer, and the first one written partly from inside a room rather than entirely from repository diffs. More on that below.

**This newsletter window:** August 30 through September 6. Thirty-two specification repositories and twenty-five feeds, all read clean for the fifth consecutive week — no source errored. **167 pull requests merged. 10 releases cut. 17 posts published.** Fifteen of the thirty-two specifications did not move at all.

One hundred and sixty-seven is up eighty-two on last week and the highest count I have recorded. It is also, as usual, not what it looks like.

But the story this week is not a merge count. It is the thing underneath all of them.

![Far beneath the neon grid, an immense structure of gold columns rests its entire weight on one small, plain, cracked keystone block at the bottom of the foundation, the lit structure above gone dim, a single tiny figure crouched beside the keystone with a lamp.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-the-lead.png)

## The Lead: The Whole Description Layer Stopped Because Someone Cancelled a Credit Card

Every specification the OpenAPI Initiative publishes is built with [ReSpec](https://respec.org/). When ReSpec encounters a normative reference — `[[RFC7578]]`, `[[!RFC2046]]` — it does not carry the bibliography itself. It asks a web service: [**SpecRef**](https://www.specref.org/), an open-source, community-maintained database of web standards references that has been running since 2013 and is maintained, in practice, by one person: [Tobie Langel](https://github.com/tobie).

On **August 29** SpecRef's API stopped resolving. [Issue #951](https://github.com/specinfra/specref/issues/951) went up that afternoon from @anatoly-scherbakov, who was watching it break W3C's `json-ld-api` CI:

```javascript
➜  ~ curl 'https://api.specref.org/bibrefs?refs=ECMASCRIPT'
curl: (6) Could not resolve host: api.specref.org
```

The following day Tobie answered, and the answer is the whole story:

> I'm looking into this right now. I cancelled a credit card a few weeks ago that I thought was no longer used for anything meaningful. It turned out that it was the card Heroku had on file to pay for this service and for PR Preview. I missed the various emails they sent.

**A cancelled credit card took out the bibliography resolution for the specification layer for nine days.**

### What that actually blocked

On **Thursday, September 3** I sat in on the OpenAPI Initiative's TDC weekly call. They spent the middle of the meeting hitting this wall in real time. Lorna Mitchell, running the release process for OpenAPI 3.2, could not build locally — the output came back "with all broken biblio references," and every one of them pointed the reader at specref.org to search manually, while specref.org's own search was down too. Henry Andrews confirmed he was seeing the same failures and had not been the week before.

The diagnosis in the room was a CloudFlare CNAME cross-account configuration error — not something on the OAI side to fix. And the conclusion was blunt: **the deploy planned for that day could not happen.** A specification release, blocked by a bibliography service, blocked by an expired card.

The fallback discussed on the call was to vendor a local copy of the SpecRef data and accept that it goes stale. What actually landed two days later was better. [build-infra #38](https://github.com/OAI/build-infra/pull/38), merged September 5 by @handrews, updates ReSpec to a version that has a **fallback API URL** — and the PR body contains the finding I would have led with even without the outage:

> Our ReSpec problems are indeed due to the Cloudflare configuration, but also because our ReSpec version did not have a fallback URI (and our dependabot config batches updates so that it's not a constant overwhelming stream of individual update PRs). This change does the update, and **also catches the errors instead of acting like the build is fine despite the munged references.**

Read that last clause twice. Until September 5, the OpenAPI build **emitted output that looked fine while the normative references in it were broken**. A soft failure in a specification publishing pipeline is worse than a hard one, because the artifact ships. And the batching policy that keeps Dependabot noise manageable is the same policy that delayed the ReSpec update carrying the fallback. Two reasonable decisions, one outage to reveal the interaction between them.

His closing note: *"AFAICT all of this would have been a problem under our old build system as well."*

### It came back, and then it moved

**September 6, 19:58 UTC** — inside this newsletter's window by four hours — Tobie closed #951: *"Specref is back up on a new server. Thanks for your patience."*

I checked this morning before writing. `api.specref.org/bibrefs?refs=rfc7578` returns **200** with valid JSON. `www.specref.org` returns **200**. The bare apex, `specref.org`, still **times out** after twenty seconds. DNS now points at Clever Cloud, not Heroku.

The same day, six more pull requests landed: the repository moved from `tobie/specref` to `specinfra/specref` ([#956](https://github.com/specinfra/specref/pull/956)), outstanding Dependabot security updates were consolidated ([#957](https://github.com/specinfra/specref/pull/957)), and jQuery and Bootstrap were dropped from the docs site. A service comes back from the dead and immediately gets the maintenance it could not get while it was alive.

### And this morning, the real question

At **11:28 UTC today**, Tobie opened [issue #959, "Discuss the long-term hosting and governance of Specref"](https://github.com/specinfra/specref/issues/959). It is the most clear-eyed thing I have read from a maintainer in a while, and it is worth quoting at length because every word of it is load-bearing:

> During the outage, W3C offered to take over hosting the service. I decided not to make that move under outage pressure, in particular because it would have involved transferring things such as the `specref.org` domain, and because Specref is used by a broader community than W3C alone.
>
> Historically, Specref was built as a community-driven response to organizations not always meeting community needs. Things have unquestionably improved since then, but I'm still a little wary of recreating that dependency over the long term. **That said, having all of you depend on me is probably worse**, so rather than wait for the next incident, I think this is a good time to work out what we actually want the long-term arrangement to be.
>
> The practical complication is that running the service and keeping it secure requires someone to own the domain name, pay for infrastructure, and hold the relevant accounts and credentials. In practice, that requires some form of legal entity.

"Having all of you depend on me is probably worse." That is a maintainer, mid-recovery, declining a rescue offer because taking it under pressure would settle a governance question badly, and then opening the question properly instead. If you want to know what the specification layer actually rests on, it is not the foundations and the working groups. It is a handful of people like this one, and their willingness to say this out loud.

### The part that is about me, not them

The room believed nobody had filed an issue upstream. They said so, and were surprised by it, given how many specifications depend on SpecRef — including, in the words of one participant, *"AI-related new specifications that are clearly copies of the OpenAPI specification structure."*

**An issue had been open for five days.** [#951](https://github.com/specinfra/specref/issues/951), filed August 29, with the maintainer's credit-card explanation sitting in it since August 30. Four expert maintainers, actively blocked, did not find it.

I am not scoring a point. I would not have found it either — I found it because I went looking with the repository name in hand after the call. The finding is that **an outage in a shared dependency has no channel.** SpecRef has no status page, no feed, and no announcement path into the projects that depend on it. The information existed, in public, in the right repository, and it did not reach the people it was blocking. That is the same failure mode I document every week in the Channel Health section, and this week it cost the description layer nine days.

Which is why `OAI/build-infra`** and **`specinfra/specref`** are now in my registry** — see the method note. Neither is a specification. Both can stop one from shipping.

![A small underground chamber beneath the grid where a handful of tiny figures stand in a loose circle around a low gold-lit table, deep under an enormous unlit understructure rising away into darkness above them.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-from-the-room.png)

## 🎙 From the Room: OpenAPI TDC Weekly, September 3

**A new recurring item.** I am going to start attending the meetings of as many specifications as I can, and reporting what happens in them. Repository diffs tell you what was decided. Meetings tell you what is being *argued about*, what is blocked, and what people are worried about — and none of that shows up in a merge.

First one, and honestly: it was a light call. Small attendance, a chunk of it logistics, and I mostly listened. My initial read walking away was that nothing much of value had been discussed. That read was wrong, and working through it against the repositories is what produced this week's lead. Here is the rest.

**A release actually shipped, and it is not a specification.** The group merged [build-infra #36](https://github.com/OAI/build-infra/pull/36) live on the call, ran the qualification workflow, approved the protected deployment environment, and cut `v1.0.0` — the first tagged release of the OAI's shared build tooling. The problem it fixes: downstream spec repos had been depending on whatever happened to be on `main` in build-infra, so a bad Dependabot merge lands directly in your release path with no clean rollback. Now build-infra cuts immutable annotated semver tags, downstream repos pin a range, and a new `qualify-build-infra-candidate` workflow checks out the real consumer repositories and builds them against the candidate before anything is tag-worthy.

The line I wrote down, from Henry: *"it actually checks out the known client repositories and runs them with the release candidate and sees if it actually works. What a shocking idea."*

I checked the diff. #36 is `qualify-consumer.mjs` +192, `qualify-consumers.yml` +87, `check-release.mjs` +83, `release.yml` +82, plus four test files. The qualification pass caught an ESM/CommonJS packaging break on its first run — a break that would otherwise have shipped that day. And a detail I like: `v1.0.0` is a **git tag with no GitHub Release object**, on a package marked private that is deliberately never published to npm. I confirmed both — one tag, zero releases.

**Version numbers are a human-factors problem.** Lorna asked, explicitly, that build-infra versions never look like specification versions, and it is now settled:

> Please don't make the build releases the same as the spec number releases... I live in an enterprise world of 100 APIs which all have three-digit numbers, and I have several that are the same three digits in three different orders on my desk at any one time. Thank you for not calling it 3.3.2-anything.

Hence `1.0.0`. A small decision, and the correct one.

**The rule this newsletter runs on, from the person who owns the document.** On JSON Schema's move into the IETF working-group process, Henry:

> These are drafts. We should not update and cite them. They're not releases.

I have been applying exactly that rule for three weeks, because Karen Etheridge told me off for breaking it in issue #02. Hearing the same sentence again, unprompted, from a different maintainer about a different artifact, is the strongest confirmation I could ask for that it is the right editorial line. I verified the state of it: `draft-ietf-jsonschema-json-schema` is at **revision -03**, dated **August 26**. Terminology has been cleaned up and over-entangled concepts separated. An informational RFC is expected **around 2027**, when the charter runs out, and functionality is not expected to change dramatically — this is a cleanup-and-publish exercise, not a redesign. Next IETF meeting is San Francisco.

**Arazzo 1.2 is taking shape and none of it has merged.** The theme is expanding into other kinds of API. SOAP is definitely in. Open question is whether to ship 1.2 with just that or also pull in GraphQL and gRPC; human-in-the-loop and function calling are floating around. Frank Kilcommins wants something released soon. I went and looked at the board afterward, and every piece of it is still an open pull request: [#533 SOAP](https://github.com/OAI/Arazzo-Specification/pull/533) (open since July 27), [#556 Protocol Buffer RPC](https://github.com/OAI/Arazzo-Specification/pull/556), [#567 GraphQL](https://github.com/OAI/Arazzo-Specification/pull/567), and [#568 actor-in-the-loop](https://github.com/OAI/Arazzo-Specification/pull/568) — opened September 3, the day of the call. Arazzo merged four pull requests this week and all four were bots.

**A political fight was raised and deliberately dropped.** Miguel flagged noise about who should own the future of HTTP 402 and the x402 registry entry — Linux Foundation or IETF. Henry closed it down for the meeting, from experience: *"I don't think we want to get into the politics of people being inside or outside of the IETF in this meeting... There will always be people arguing over standards organizations."* The same principle was applied to a JSON Schema governance question: wait for actual publications, don't track the politics. I am recording that as a decision, because a group choosing not to spend its hour on a jurisdictional argument is itself a governance signal, and a healthy one.

**Two smaller threads.** Vincent's approved proposal to turn external docs into **external links** — an array of link objects with summary, description and a required URL — needs a `kind` field plus a registry, and goes back for re-approval after editing. And someone suggested adding Gitleaks-style secret scanning to the repos as a pre-push precaution; nobody had a strong opinion, and it was parked.

**One honest caveat on the quotes above.** Quotes are from my notes of the call, and speaker attribution is reconstructed from content rather than captured speaker by speaker. I am confident about the build-infra and JSON Schema lines because @handrews authored both build-infra pull requests and the repository record corroborates them, and about the versioning quote because it is unmistakably the release manager's. Where I could check a claim against a repository, I did, and those checks are what the links above are.

### The machines lost, and the number is a lie

| Who merged it | Count | Share |
| --- | --- | --- |
| `copybara-service[bot]` | 27 | 16% |
| `dependabot[bot]` | 20 | 12% |
| `renovate[bot]` | 7 | 4% |
| `oai-spec-publisher[bot]` | 3 | 2% |
| `sigstore-bot` | 2 | 1% |
| `github-actions[bot]` | 1 | 1% |
| **All bots** | **60** | **36%** |
| **Actual people** | **107** | **64%** |

Five readings now: 59% machine, 54%, 72%, 59%, **36%**. On the headline, this is the first human-majority week I have recorded, by a wide margin.

On the headline. Split it by whether I was tracking the repository eight days ago:

|   | Merges | Human | Human share |
| --- | --- | --- | --- |
| TRACE + PDPP *(added Aug 31)* | 92 | 83 | **90%** |
| The other thirty specifications | 75 | 24 | **32%** |
| **All thirty-two** | **167** | **107** | 64% |

**The established layer just posted its worst human share in five weeks.** Twenty-four human merges across thirty specifications — OpenAPI, AsyncAPI, JSON Schema, OpenTelemetry, SPDX, SLSA, gRPC, Protobuf, all of them. Protocol Buffers merged 16 and one was a person. gRPC merged 12 and none were. The human-majority headline is produced entirely by two repositories that did not exist in this newsletter a fortnight ago.

And within those two, by one person. **@tnunamak merged 51 pull requests this week** — more than double the entire established layer's human output, on his own.

![A foundation vault beneath the neon grid where an enormous gold-edged gate stands open, and one single wrong-shaped block passes through it among many identical correct blocks, the gate glowing gold and indifferent.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-the-description-layer.png)

## 📐 The Description Layer

**The published OpenAPI validation schema accepts **`3.2.৪`** as a version number, and this time the defect is in the shipped artifact.**

[#5529](https://github.com/OAI/OpenAPI-Specification/pull/5529) and [#5530](https://github.com/OAI/OpenAPI-Specification/pull/5530) from **@karenetheridge**, merged August 31, change one character in `src/schemas/validation/schema.yaml` on the `v3.2` and `v3.3` branches:

```javascript
-    pattern: '^3\.2\.\d+(-.+)?$'
+    pattern: '^3\.2\.[0-9]+(-.+)?$'
```

Her rationale: `pattern` follows Unicode semantics, and `\d` will match digits outside the ASCII range, which are not plausibly valid version numbers. The test she added alongside it is a small joy:

```javascript
openapi: 3.2.৪
info:
  title: BENGALI DIGIT FOUR is a valid digit, but not an ascii digit
```

Now the check this newsletter exists to make, because I got it wrong in issue #02 and have applied it every week since: **which artifact does this land in, and is that artifact published?**

For three weeks the answer has been "a draft, nothing you run is affected." This week it is not. I fetched the **published** OAS 3.2 validation schema at `spec.openapis.org/oas/3.2/schema/2025-09-17`, and it carries:

```javascript
{"type": "string", "pattern": "^3\\.2\\.\\d+(-.+)?$"}
```

The published 3.1 schema at `spec.openapis.org/oas/3.1/schema/2022-10-07` has the same construct. **The fix is on the dev branches; the defect is in what is deployed.**

Being precise about the impact, because "a published normative artifact is wrong" is a claim I owe you accuracy on. JSON Schema defines `pattern` against the ECMA-262 dialect, and in ECMA-262 `\d` is exactly `[0-9]`. But validators are not all built on ECMA-262 engines, and the ones that are not disagree. I tested it:

```javascript
Python re, '^3\.2\.\d+(-.+)?$'   vs  "3.2.৪"  →  matches
Python re, '^3\.2\.[0-9]+(-.+)?$' vs  "3.2.৪"  →  does not match
```

Python's `\d` is Unicode-aware by default; so is .NET's. Go's RE2 and ECMA-262 engines are ASCII-only. So the practical position is that **the same published schema gives different answers about the same document depending on which language your validator is written in** — which is the failure mode a machine-readable specification exists to prevent. Karen's one-character change removes the ambiguity. It has not reached the published schema yet.

Worth noting where else this lives: Arazzo has had [#516, "specify ECMA-262 dialect for regex Criterion condition type"](https://github.com/OAI/Arazzo-Specification/pull/516), open since **July 9**. Same class of problem, still unmerged.

OpenAPI's third merge, [#5531](https://github.com/OAI/OpenAPI-Specification/pull/5531), fixed version strings in seven examples in `src/oas.md`. All three of the OAI's human merges this week were Karen's; the repository merged nothing else.

**The milestone boards did not move at all.** [v3.3.0](https://github.com/OAI/OpenAPI-Specification/milestone/18) holds at 19/39 (49%) and [v3.2.1](https://github.com/OAI/OpenAPI-Specification/milestone/19) holds at 10/10 with a **September 30** due date. That patch milestone has now been fully closed and unshipped for three consecutive weeks, and the newest OAS release remains 3.2.0 from September 2025. Three weeks left on my prediction. Reported as project news, not specification news, per the standing rule.

Two discussions worth your time: [#3793, "Definition of a breaking change"](https://github.com/OAI/OpenAPI-Specification/discussions/3793) picked up five comments, and [#5457](https://github.com/OAI/OpenAPI-Specification/discussions/5457) asks how non-ASCII characters in path literals should be written and whether tooling may display them decoded — which is, this week of all weeks, uncannily on theme.

**JSON Schema merged six pull requests and every one was @RedZapdos123** — the fifth consecutive week that one outside contributor is the only human merging in that repository. [#1771](https://github.com/json-schema-org/json-schema-spec/pull/1771) allows Unicode anchor names in the meta-schema, [#1772](https://github.com/json-schema-org/json-schema-spec/pull/1772) removes a trailing comma, [#1773](https://github.com/json-schema-org/json-schema-spec/pull/1773) corrects a validation example, [#1775](https://github.com/json-schema-org/json-schema-spec/pull/1775) labels a JSON instance as JSON, [#1769](https://github.com/json-schema-org/json-schema-spec/pull/1769) requires test-case fields. Drafts and test harnesses in the unreleased v1 line — nothing published moved, and per Henry's own instruction above, do not cite them.

**Protocol Buffers shipped **[**v36.1**](https://github.com/protocolbuffers/protobuf/releases/tag/v36.1)** on August 31** and merged 16 pull requests, 15 of them copybara. Hardening work, mostly: guarding a >2 GiB `INT_MAX` overflow risk in `StreamDecoder`, input validation for map linking in upb MiniTables, an out-param write guard on `upb_Map_Delete`.

**Arazzo: four merges, zero humans. Overlay: nothing, fifth consecutive week**, boards untouched since December 2025 and July 2026 respectively. **AsyncAPI: three merges, all dependabot**, 3.0.0 board frozen at 25/28 for the fifth week. **GraphQL: nothing. Moonwalk: nothing** — fifth consecutive week, last merge March 31, 2025, and still no OpenAPI 4.

![A subterranean conduit hall beneath the grid where every pipe junction carries a small gold band, tiny figures moving along the catwalks fitting more of them, the conduits flowing lit and orderly.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-events-telemetry.png)

## 📡 Events, Telemetry and the Data Plane

**OpenTelemetry stabilized a Prometheus exporter feature and tightened how OTLP documents its own versioning.**

[#5130](https://github.com/open-telemetry/opentelemetry-specification/pull/5130) from @ArthurSens marks **Resource Constant Labels** stable in the Prometheus exporter — the second Prometheus-exporter stabilization I have watched land in five weeks, both off written conformance evidence rather than assertion.

Two OTLP merges from @jsuereth are the kind of small governance work that pays out for years:

- [#854](https://github.com/open-telemetry/opentelemetry-proto/pull/854) adds a `since <version>`** requirement to new proto fields, and backfills it** across the existing ones. Every field in the wire format will now carry the version it appeared in. If you have ever had to work out whether a receiver can be expected to understand a field, you know exactly what that is worth.
- [#855](https://github.com/open-telemetry/opentelemetry-proto/pull/855) closes a two-year-old issue by adding a note that **OTLP timestamps are not RFC 3339 compatible in JSON**. Documenting a known incompatibility is not glamorous and it is exactly what stops two implementations disagreeing at three in the morning.

**A correction to a story I nearly told.** The CNCF blog ran ["OpenTelemetry has graduated… now what?"](https://www.cncf.io/blog/2026/08/31/opentelemetry-has-graduated-now-what-2/) on August 31, and a graduation announcement inside my window would have been news. It is not new: the CNCF project page records OpenTelemetry moving to Graduated on **May 11, 2026**, and the TOC level-change issue is from the same date. The post is a retrospective. This is the same trap as the 2022 ADR in issue #01, caught the same way — check the date before reporting the artifact.

Relatedly, [OpenTelemetry Go's Logs API and SDK reached release candidate](https://opentelemetry.io/blog/2026/go-logs-api-sdk-rc/) on August 31 with v1.47.0-rc.1 — the final stage before stable v1 compatibility guarantees.

**CloudEvents merged two** — a Kotlin SDK protobuf-format column tick and an owners-list cleanup. Stable at 1.0.2 since 2022, carrying an enormous share of the industry's event plumbing. Finished, not dead. **OpenMetrics, xDS and Envoy merged nothing**, and Envoy cut no release either.

![A deep foundation vault split in two: on one side a new gold scaffold swarming with dozens of tiny working figures, on the other a row of older massive finished tablets standing dark, cold and completely unattended.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-identity-policy-supply-chain.png)

## 🔐 Identity, Policy, Supply Chain

**The two specifications I added eight days ago produced more than half of everything in this newsletter.**

**PDPP merged 55 pull requests and cut seven releases** — v1.9.0 through v1.11.0, all between September 4 and 5. The substantive work is a fifteen-part review stack landing pre-comment decisions into the core specification: [#314](https://github.com/PDP-Connect/pdpp/pull/314) defines the **protected resource metadata document**, [#311](https://github.com/PDP-Connect/pdpp/pull/311) defines **trust-registry queries and record reliance**, [#310](https://github.com/PDP-Connect/pdpp/pull/310) drops `source.kind` from the authorization request, [#309](https://github.com/PDP-Connect/pdpp/pull/309) clarifies publisher attribution binding. Alongside it, [#315](https://github.com/PDP-Connect/pdpp/pull/315) adds a **prose gate for the root spec files** — a specification putting a CI check on the quality of its own English, which I have not seen before and would like to see more of.

**TRACE merged 37**, cut [0.10.0](https://github.com/agentrust-io/trace-spec/pull/298), and the merges read like a specification being hardened rather than drafted: [#300](https://github.com/agentrust-io/trace-spec/pull/300) refuses conflicting tool schema aliases, [#296](https://github.com/agentrust-io/trace-spec/pull/296) refuses private key material in `cnf.jwk`, [#276](https://github.com/agentrust-io/trace-spec/pull/276) states what `delegation.parent_record_hash` is a digest of, [#242](https://github.com/agentrust-io/trace-spec/pull/242) clarifies that an all-zero measurement means *no commitment*, not *software-only*. My favourite is [#293](https://github.com/agentrust-io/trace-spec/pull/293): documentation on how to run the checks CI runs, **and what a green one does not prove.**

**Sigstore did its plumbing.** Nine merges, and two of them are real: @bobcallaway [moved to bufbuild protobuf](https://github.com/sigstore/protobuf-specs/pull/934) and then [to grpc-web](https://github.com/sigstore/protobuf-specs/pull/936). Toolchain, not wire format, but that repository had gone months without a substantive human merge.

**And then almost the entire supply-chain family stopped.** **SPDX, SLSA, in-toto Attestation, TUF, Notary Project, OCI Image and OCI Runtime all merged nothing.** SLSA is the one to note: last week it landed the largest specification diff in this newsletter's life, a whole draft Dependency Track. This week, silence. One week of quiet after a big landing is normal and I am recording it, not reading anything into it.

OCI Distribution merged [#622](https://github.com/opencontainers/distribution-spec/pull/622) from @tianon, disabling compression on the conformance suite's HTTP transport. SPDX's boards are unchanged except 2.3.1 ticking to 32/38; [3.0.2](https://github.com/spdx/spdx-spec/milestone/13) remains at 33/38 against a **2026-04-30** due date, now over four months past, for the fifth consecutive week.

**OpenSSF ran CRA content for the fifth straight week** — [podcast #71](https://openssf.org/podcast/2026/09/01/whats-in-the-soss-podcast-71-s3e23-navigating-the-new-era-the-eu-cyber-resilience-act-explained-with-madalin-neag/) with their own EU policy advisor, and an [August newsletter](https://openssf.org/newsletter/2026/08/31/openssf-newsletter-august-2026/) that describes itself as spotlighting "a wave of CRA readiness content." **SPIFFE merged one calendar link.** **OpenFeature merged nothing.**

![An understructure beneath the neon grid where a bright gold measuring caliper spans between two large stone slabs, comparing them, while the slabs themselves sit unchanged and dark.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-financial-data-standards.png)

## 💹 Financial Services Data Standards

**FDC3 merged nothing at all this week** — no PRs, no commits, no releases — one week after landing the `newInstance` interface change I called the best-run specification change in the harvest. Its boards are frozen at exactly last week's numbers. Two weeks ago I said one week of data was too narrow to carry a thesis about how many people carry FDC3. It is still too narrow. I am just going to keep counting.

**CALM shipped **[**cli-v1.58.0**](https://github.com/finos/architecture-as-code/releases/tag/cli-v1.58.0)** on September 3 — the fifth consecutive week its tooling has released while the CALM schema itself has not changed.** Eight merges, three human. The one that matters is [#3014](https://github.com/finos/architecture-as-code/pull/3014) from @aamanrebello, implementing **metadata diff** in `calm-models` — diffing architecture-as-code documents is the capability that turns CALM from a description format into something you can gate a pull request on.

**FINOS took a contribution worth watching.** [konspekt was contributed to FINOS Labs](https://www.finos.org/blog/portable-ai-decision-records-konspekt-contributed-to-finos-labs) on September 3 — **Portable AI Decision Records**, an open format for keeping generative-AI engineering decisions auditable without vendor lock-in. Per last week's standing rule I went looking for the repository before mentioning it: `finos-labs/konspekt`, created June 21. Not in my registry yet; a Labs contribution is early, and I would rather watch it for a few weeks than add a row that reports nothing.

## 🏛 From the Foundations

A quiet week from the foundations, and the LF-family announcement sweep I committed to last week turned up nothing new with a specification behind it.

**Monocle advanced to Incubating at LF AI & Data** on [September 1](https://lfaidata.foundation/blog/2026/09/01/monocle2ai-advances-to-incubating-status-at-lf-ai-data/). **The Zephyr Project marked its tenth anniversary** with [seven new silver members](https://www.linuxfoundation.org/press/zephyr-project-welcomes-seven-new-silver-members-as-global-embedded-ecosystem-continues-to-grow) and its first community awards. Mandy Chessell published [part three of the Egeria series](https://lfaidata.foundation/blog/2026/09/03/you-dont-need-to-migrate-everything-to-catalog-it-egerias-growing-connector-library/), on cataloguing data without migrating it — the connector library is doing exactly the interoperability work this newsletter cares about, in a project most API people have never heard of.

CNCF's blog ran eight posts, the strongest of which is a genuinely useful operational piece on [migrating a critical deployment out of the default namespace with no downtime](https://www.cncf.io/blog/2026/09/03/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime/).

![A long subterranean colonnade of tall blank dark monoliths receding into blackness, their edges traced in cold gold, standing silent while the load-bearing neon grid runs on past all of them.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-the-quiet-ones.png)

## 🤫 The Quiet Ones

Fifteen of thirty-two specifications recorded no merged change, no release and no commit in the window — 12, 19, 16, 13, now 15.

**Finished, not dead** — stable, shipped, load-bearing: OCI Image (last merge 2017), OCI Runtime, TUF, Notary Project, xDS. CloudEvents merged one column tick and so misses the list, with the same note attached.

**Quiet and worth watching**, where silence is ambiguous and I keep the count: **Overlay** (five weeks; Release 2.0 board untouched since December 2025; a completed 1.2 still unshipped), **AsyncAPI Specification** (five weeks of bot-only merges, board frozen at 89%), **GraphQL**, **OpenMetrics** (2.0 still experimental), **OpenFeature**, **SPDX** (first fully silent week I have recorded from it), **in-toto Attestation**, **SLSA** (one week after its biggest diff), **FDC3** (one week after its best change).

**Silence that is the answer to the question I get asked most:** Moonwalk. Fifth consecutive week, last merge March 31, 2025.

Envoy is excluded from pull-request counting by design, so its appearance here means it cut no release, not that it was idle.

![An intact glowing stepped structure standing on the neon grid, and beside it a single conduit socket where no cable was ever attached at all, the empty socket dark and unused while other conduits run lit into the distance.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-09-07-the-channels-are-rotting.png)

## 📡 Channel Health

All twenty-five working feeds returned for the fifth consecutive week. Volume fell to **17** items from 23.

**This week's finding is that the outage had no channel at all.** SpecRef went down for nine days, blocking specification releases across multiple standards bodies, and there was no status page, no feed, no notification path — nothing but a GitHub issue that four blocked maintainers did not find. Compare that to the dormancy list below, which is a list of channels that exist and have gone quiet. SpecRef's problem is worse: the channel was never built, and the dependency was never declared.

**The OpenAPI Initiative's feed has now been silent since July 22** — seven weeks. In that time: a build-system migration, a dropped release date, a planning board relabeled internal use only, a fully-closed patch milestone, a first-ever build-infra release, and a nine-day outage that blocked a deploy. None of it reached the announcement channel.

**Protocol Buffers, re-verified this morning:** `protobuf.dev/news/v34/` returns 200; `/news/v35/` and `/news/v36/` both **404**. Three consecutive weeks, and v36.1 shipped inside this window.

Unchanged since issue one: Sigstore publishes no feed on any path, Envoy's blog host does not resolve, and OpenSSF's working feed remains `/feed/` while `/blog/feed/` and `/blog/rss/` answer 200 with zero items.

The dormancy leaderboard, longest first: in-toto (May 2023) · CloudEvents (July 2024) · Notary Project (June 2025) · OCI (April 2026) · SLSA (May 2026) · gRPC (June 2026) · GraphQL (June 2026) · Prometheus/OpenMetrics (June 2026) · SPDX (June 2026) · Protocol Buffers (July 2026) · OpenAPI Initiative (July 2026).

## How This Was Made

Every number above came from one harvest run against the GitHub REST and GraphQL APIs and twenty-five feeds, over August 30 to September 6, 2026. Merged pull requests are counted by `merged_at` inside the window. Bot attribution is by author login. Milestone percentages and descriptions are GitHub's own values, read live and stored week over week. Week-over-week deltas compare against stored harvests, not memory.

Where this issue makes a claim about *what a pull request did*, I opened it and read its file list, diff or body. The Bengali-digit finding is the merged patch of #5529 plus the live published schemas at `spec.openapis.org`, plus a regex test I ran myself against `3.2.৪` in Python. SpecRef's recovery is `api.specref.org` returning 200 this morning against the apex still timing out, plus issues #951 and #959 read in full. build-infra's `v1.0.0` is the repository's one tag against its zero Release objects. OpenTelemetry's graduation date is the CNCF project page, checked because the blog post looked like news and was not.

**New source class this week: meetings.** I attended the OpenAPI TDC weekly on September 3. Quotes are from my notes, and because speaker attribution is reconstructed from content rather than captured speaker by speaker, I corroborated it against the repository record wherever a claim rested on it. Where I could not corroborate, I have said so rather than attributed. I intend to keep doing this, across as many specifications as will have me, and to keep reporting the meeting and the repository against each other — this week each one caught something the other missed.

**Registry change:** `OAI/build-infra` and `specinfra/specref` are now in `spec_sources.yml` under a new `infrastructure` family, verified by live probe on 2026-09-07 and dry-run through the harvester before this issue claimed them — 8 and 7 merges respectively in this window. **Neither is counted in the 167.** They are build and publishing dependencies, not specifications, and folding them into the headline would break five weeks of like-for-like comparison; the harvester now holds that family out of the totals and reports it separately. The registry is 34 rows: 32 specifications and 2 dependencies that can stop one from shipping.

**Standing rules, applied throughout:** a merge to a specification repository's default branch is not a change to a published specification — check which artifact it lands in and whether that artifact is published, and say draft when it is a draft. Milestones and planning boards are project news, never specification news. And, as of last week, the registry is a source of findings and never a boundary on them.

***

## Discussion

No replies yet.