---
type: "article"
title: "The Specification Layer — The Two Specifications I Was Not Watching Out-Worked the Thirty I Was"
summary: "Eighty-five merges across thirty specifications, the lowest reading since I started counting — and then two specifications the Linux Foundation adopted this week, and which were not on my list, merged fifty-two pull requests between them in the same seven days. Forty-eight of those were written by people. My entire tracked layer managed thirty-five. TRACE and PDP-Connect each individually out-merged every specification in my registry, and the honest headline is 137, not 85. Elsewhere: SLSA landed the largest specification diff in this newsletter's short life — a whole new Dependency Track, in draft, its author disclosing on the record that he used an LLM to structure it. OpenAPI's total specification text change across three weeks now stands at two capitalized words and one deleted space."
newsletter: "The Specification Layer"
newsletter_handle: "the-specification-layer"
newsletter_url: "https://usecommune.com/n/the-specification-layer"
author: "Kin Lane (@kinlane)"
published: "2026-08-31T20:03:24.146Z"
canonical_url: "https://usecommune.com/n/the-specification-layer/a/HJvpMEs2"
markdown_url: "https://usecommune.com/n/the-specification-layer/a/HJvpMEs2.md"
chat_url: "https://usecommune.com/n/the-specification-layer/a/HJvpMEs2/chat"
body_source: "native"
likes: 1
replies: 0
body_words: 5251
---

# The Specification Layer — The Two Specifications I Was Not Watching Out-Worked the Thirty I Was

This is the fourth issue of The Specification Layer. Last week I led on the OpenAPI Initiative telling outside readers to stop treating its planning board as news. This week the story is my own list, and what was not on it.

**This newsletter window:** August 23 through August 30. Thirty specification repositories and twenty-five feeds, all read clean for the fourth consecutive week — no source errored. **85 pull requests merged. 7 releases cut. 23 posts published.** Thirteen of the thirty specifications did not move at all.

Eighty-five is the lowest merge count I have recorded — 150, then 156, then 109, now 85. Four straight declines. I was going to write that the specification layer had gone quiet for the last week of August.

Then I went to look at two things the Linux Foundation announced mid-week, and I changed my tune.

![Deep beneath the dark neon grid, a foundation chamber where a surveyed row of catalogued gold-edged columns stands dim and unattended in the foreground, while out past the edge of the surveyed floor two colossal new gold columns blaze at full brightness, wrapped in scaffolding and swarming with tiny working figures.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-the-lead.png)

## The Lead: The Two Specifications I Was Not Watching Out-Worked the Thirty I Was

On August 25 the Linux Foundation [welcomed TRACE](https://www.linuxfoundation.org/press/linux-foundation-welcomes-trace-to-advance-verifiable-runtime-evidence-for-ai-workloads) — Trust, Runtime Attestation and Compliance Evidence — an open specification developed by **AMD, Intel, Microsoft, OPAQUE and the Technology Innovation Institute**, now under LF governance. In the foundation's own words it produces "a standardized, hardware-enforced governance record that binds together the runtime environment, software, policies, data classifications and tool usage into a portable, cryptographically verifiable artifact that travels with the workload across clouds and confidential computing environments."

The next day, LF Decentralized Trust [introduced PDP-Connect](https://www.lfdecentralizedtrust.org/blog/introducing-pdp-connect-a-new-personal-data-consent-and-authorization-specification-lab), a personal data consent and authorization specification lab initiated by the Vana Foundation, whose deliverable is the **Personal Data Portability Protocol** — "an open specification for how a person authorizes an application's ongoing access to their personal data, and how that authorization is enforced."

Two announcements, four days apart. I went to look at the repositories behind them, expecting the usual: a charter, a README, a roadmap, and a first commit six weeks from now.

That is not what is in them.

| Repository | Merged PRs, Aug 23–30 | Human share |
| --- | --- | --- |
| **TRACE** — `agentrust-io/trace-spec` *(not on my list)* | **28** | **93%** |
| **PDPP** — `PDP-Connect/pdpp` *(not on my list)* | **24** | **92%** |
| Protocol Buffers | 20 | 0% |
| gRPC | 15 | 53% |
| CALM | 8 | 75% |
| OpenAPI Specification | 7 | 43% |
| **All thirty tracked specifications** | **85** | **41%** |

**Each of them, individually, out-merged every specification in my registry.** Protocol Buffers, the perennial volume leader, merged 20 — and all twenty were a bot. Between them the two unlisted repositories merged **52 pull requests, 48 of them by people**.

My entire tracked layer — thirty specifications, the OpenAPI Initiative and AsyncAPI and JSON Schema and OpenTelemetry and SPDX and SLSA and every other name in this newsletter — produced **35 human merges** in the same seven days.

**Two specifications nobody has heard of did more human specification work last week than the thirty that run the industry.**

So the honest version of this week's headline is not "85 merges, the quietest week yet." It is **137 merges** once both are counted, and the layer's human share goes from 41% to 61%. The specification layer was not quiet. My list was incomplete, and it was incomplete in precisely the direction where the work is.

This is a structural weakness and it deserves naming plainly. My registry is thirty repositories I chose by hand from the Linux Foundation's specification inventory. A hand-curated list of established specifications will always be a list of *established* specifications. It cannot show me a new one, and new ones are where the building happens. **A registry curated once goes stale in exactly one direction: toward the past.** Four weeks in, mine already had.

### What is actually in them

Volume without substance is the thing I complain about every week, so here is what those 52 merges were.

**TRACE** (`agentrust-io/trace-spec`, created June 3, 2026) is writing schema, not marketing. [#199](https://github.com/agentrust-io/trace-spec/pull/199) put the references block into both the schema and the model; [#219](https://github.com/agentrust-io/trace-spec/pull/219) held every integer in a signed object to the JCS safe-integer range; [#222](https://github.com/agentrust-io/trace-spec/pull/222) fixed `tool_transcript.hash` to use JCS rather than the registry-anchor format; [#203](https://github.com/agentrust-io/trace-spec/pull/203) enforced the PIC bridge schema constraints; [#184](https://github.com/agentrust-io/trace-spec/pull/184) opened a draft, non-normative **A2A delegation-link verification profile with 23 conformance vectors**. The `schema/` directory holds four JSON Schema documents, `trace-claim.json` alone running 19KB.

**PDPP** (`PDP-Connect/pdpp`, created July 17, 2026) **cut a release inside the window** — [v1.8.0](https://github.com/PDP-Connect/pdpp/releases/tag/v1.8.0) on August 25 — and merged normative changes on top of it: [#243](https://github.com/PDP-Connect/pdpp/pull/243) corrected owner-token metadata access and the effective-filter rule in the Core spec, [#250](https://github.com/PDP-Connect/pdpp/pull/250) scoped the Verified Operator claim and sketched a conformance suite, [#244](https://github.com/PDP-Connect/pdpp/pull/244) updated the documents to say PDP-Connect is hosted at LFDT rather than proposed to it. Seventeen of its 24 merges came from one maintainer, @tnunamak.

And PDPP is squarely this newsletter's beat in a way I should not have needed a press release to notice. It **profiles OAuth 2.0 and **[**RFC 9396**](https://datatracker.ietf.org/doc/html/rfc9396)** (Rich Authorization Requests) for personal data**, adding user-defined authorization over *which records* and *under what scope*. That is an API authorization specification — consent as a machine-readable grant, enforcement as a protocol obligation instead of a privacy policy — and it has been shipping releases since July while I was counting dependabot bumps in repositories that merged nothing.

### Why both of these exist

TRACE is downstream of specifications I do track. It [composes](https://github.com/agentrust-io/trace-spec) RATS, EAT, SCITT, **SLSA** and **SPIFFE** into a single evidence layer. SPIFFE merged nothing at all this week. SLSA merged the largest specification diff in this newsletter's short life, which is two sections down. **The specification assembling all of them into an attestation record for AI agents is moving faster than any of its inputs.**

Both new efforts are about a machine proving something about itself to another machine — what ran, under what policy, with what tools, on whose authority, over whose data. That is the same problem SPIFFE's Transaction Tokens roadmap named last week, and the same problem SLSA's new Dependency Track names this week. Four different bodies, one question.

**What I am doing about it.** TRACE and PDPP are in `spec_sources.yml` as of this issue — I added them, dry-ran both through the harvester, and the numbers above are that harvester's output cross-checked against a second independent query. Thirty specifications became thirty-two, and both appear in next week's counts as first-class rows. I am also going to stop treating the registry as fixed: every LF-family announcement naming an open specification now gets checked for a repository *before* I write the issue.

I do not know how many more I am missing. That is the honest answer, and it is why this is the lead rather than two quiet rows added to a config file and a bigger number reported next Monday.

### The machines gave some ground back

| Who merged it | Count | Share |
| --- | --- | --- |
| `copybara-service[bot]` | 27 | 32% |
| `dependabot[bot]` | 10 | 12% |
| `oai-spec-publisher[bot]` | 7 | 8% |
| `renovate[bot]` | 5 | 6% |
| `github-actions[bot]` | 1 | 1% |
| **All bots** | **50** | **59%** |
| **Actual people** | **35** | **41%** |

Four readings now: 59% machine, 54%, 72%, **59%**. Last week's 72% was the outlier it looked like. The headline count fell by 24 while **human merges rose from 30 to 35** — the machines took the entire decline and then some.

The busiest human across all thirty specifications merged **three** pull requests, and there were two of them: @RedZapdos123 in JSON Schema and @jsuereth in OpenTelemetry. That is what a normal week looks like in this layer. A single person merging twenty-eight, as happened in FDC3 three weeks ago, is the anomaly.

![A vaulted undercroft beneath the neon grid where an enormous blank gold-edged tablet stands lit, its vast surface entirely empty and smooth, and a single tiny figure kneels at its bottom corner adjusting one minute notch by hand.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-the-description-layer.png)

## 📐 The Description Layer

**OpenAPI's running total of specification text changed across three weeks is now two capitalized words and one deleted space.**

Seven merges. Four were the publisher bot syncing branches. Of the three human merges, one was a `yarn.lock` bump. The other two touched `src/oas.md`:

- [#5518](https://github.com/OAI/OpenAPI-Specification/pull/5518) from **@karenetheridge**, `+2/-2` — porting last week's "Encoding object" → "**Encoding Object**" capitalization onto the `v3.3` branch. Her entire PR body: *"Can't unsee this 🤷🏻‍♂️ (Port of #5515)"*.
- [#5516](https://github.com/OAI/OpenAPI-Specification/pull/5516) from **@handrews**, `+1/-1` — changing `[[RFC 2046]]` to `[[RFC2046]]`, because, quoting him, "The RFC resolve does not understand spaces between 'RFC' and the RFC number."

Last week I reported that two weeks and twenty-three merges produced two words of specification text. The third week added the same two words on a second branch, and removed a space character. I want to be fair about what that means: OpenAPI 3.2 shipped in September 2025 and the project is in maintenance and design at once. Editorial precision in a normative document is real work — a stray space that breaks reference resolution is a genuine defect in a published artifact. But if you are waiting on new OpenAPI capability, the repository is not where it is happening right now.

**The milestone baseline held, and I said I would check.** Last week I reported the v3.3.0 milestone description reading "INTERNAL USE ONLY. Our process is not your process…" and admitted I could not prove it was new, because I had never recorded milestone descriptions. I record them now. **This week's description is byte-identical to last week's.** The board itself went from 18/39 closed to **19/39** (46% → 49%), one issue finished, no items added or removed, `updated_at` now August 27. No maintainer has told me the label predates August 21; if one does, I will say so here.

Reported as project news, not specification news, per the rule the OAI wrote and I adopted.

**A prediction I am putting on the record.** [v3.2.1](https://github.com/OAI/OpenAPI-Specification/milestone/19) has been **10 of 10 closed** for two consecutive weeks, with a due date of **September 30**. The newest release on that repository is **OAS 3.2.0, from September 19, 2025**. A patch milestone that is fully closed and not yet released is exactly the kind of thing worth grading myself on: either 3.2.1 ships in the next four weeks, or a finished board sits unshipped and I will report that instead.

**The most useful thing in the OpenAPI repository this week was a question, not a merge.** Discussion [#5504](https://github.com/OAI/OpenAPI-Specification/discussions/5504), opened August 20 by @lucdev01234-png, asks how teams enforce organization-specific rules that go beyond the specification — required security schemes, naming conventions, deprecation policies, consistent error responses, breaking-change detection. Three answers arrived in the window, and they are three different tools: a TypeScript schema DSL, Spectral and vacuum in APIOps-style pipelines, and Redocly CLI custom rules. That boundary — what the specification says versus what your organization has to enforce on top of it — is the most consequential unspecified surface in the whole description layer, and it is being answered by tool choice, one company at a time.

**JSON Schema merged three pull requests, all from the same outside contributor, for the third consecutive week.** @RedZapdos123 merged [#1767](https://github.com/json-schema-org/json-schema-spec/pull/1767) (typos in an ADR), [#1768](https://github.com/json-schema-org/json-schema-spec/pull/1768) (an `allOf` example in `specs/proposals/vocabularies.md`) and [#1770](https://github.com/json-schema-org/json-schema-spec/pull/1770) (the meta test-suite harness, allowing invalid schema fixtures). No other human merged anything in that repository this week.

Applying the rule, which by now is muscle memory: **an ADR, a proposal document and a test harness. None of it is published specification, and none of it changes anything you are running.** #1767 is a `+2/-2` typo fix to `adr/2022-09-decouple-from-ietf.md` — the same 2022 architectural decision record that in my very first issue I nearly reported as breaking governance news off the strength of its title. It is a document from four years ago, and this week somebody fixed two typos in it. That is the whole story, and knowing that it is the whole story is the entire point of reading the diff.

**Arazzo merged five pull requests and not one of them was written by a person** — two publisher syncs, one dev sync, and dependabot on respec and vitest.

**Overlay did not move at all, and now I can date the stillness rather than just count weeks.** No merges, no releases, no commits. Its three milestone boards are not merely unchanged — [Release 2.0](https://github.com/OAI/Overlay-Specification/milestone/2) (4/7) has an `updated_at` of **December 16, 2025**, and [Release 1.2](https://github.com/OAI/Overlay-Specification/milestone/4), which is **7 of 7 closed**, was last touched **July 28**. A completed 1.2 milestone has now gone unshipped through four consecutive issues of this newsletter, and nobody has touched the board in five weeks.

**AsyncAPI merged nothing for the fourth straight week**, its ["Issues to consider before 3.0.0"](https://github.com/asyncapi/spec/milestone/18) board still 25/28. **GraphQL merged nothing.** **Moonwalk merged nothing** — fourth consecutive week, last merge March 31, 2025. There is still no OpenAPI 4 in progress, and that remains the answer to the question I get asked most.

**Protocol Buffers merged 20 pull requests and every single one was **`copybara-service[bot]` — Google's monorepo exporting outward, zero human merges in the window. Substantively it is Edition 2026 groundwork continuing: negative `UninterpretedOption` field tags for interpreted option locations landing three separate times, UTF-8 validation option levels added to the upb JSON decoder, an `InlinedStringField` memory leak fixed, and testing dropped for the 35.x branch.

And the channel finding from last week has not moved: [protobuf.dev/news](https://protobuf.dev/news/) still describes **v34** as its newest version. I re-fetched `/news/v35/`, `/news/v36/` and `/news/v37/` this morning. All three return **404**.

**gRPC shipped two patch releases**, [v1.83.1](https://github.com/grpc/grpc/releases/tag/v1.83.1) and [v1.82.2](https://github.com/grpc/grpc/releases/tag/v1.82.2), both on August 27, carrying backported fixes for a GoAway and message-compression bug and a memory optimization across both branches. Fifteen merges, eight by people — release engineering and backports, as always. None of it touches the protocol.

![A subterranean service corridor beneath the grid floor, its telemetry conduits lit gold and flowing, where human figures have returned to the junction boxes and work side by side with the automaton arms on rails.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-events-telemetry.png)

## 📡 Events, Telemetry and the Data Plane

**OpenTelemetry came back, and it came back doing specification work.**

Last week OTel and OTLP merged six pull requests between them and **zero** were human. I wrote that one week is not a trend and it was worth watching whether the spec repos returned. They returned: **12 merges across the two repositories, 8 of them by people**, and three of them changed specification text.

- [#5265](https://github.com/open-telemetry/opentelemetry-specification/pull/5265) from **@dashpole**, `specification/metrics/sdk.md` `+18/-11` — clarifying how `maxExportBatchSize` behaves on the Periodic exporting MetricReader, including that `exportTimeoutMillis` applies to each individual `Export(batch)` invocation. The PR states the clarification came out of **feedback and findings from prototype implementations**, which is the healthiest possible reason for a specification to change: somebody built it, it was ambiguous, the document got fixed.
- [OTLP #845](https://github.com/open-telemetry/opentelemetry-proto/pull/845) from **@jsuereth**, `docs/specification.md` `+28/-0` — a note on UTF-8 handling written explicitly to help implementors. Twenty-eight lines is the largest single addition to OTLP's specification document in four weeks of harvesting.
- [OTLP #853](https://github.com/open-telemetry/opentelemetry-proto/pull/853), also @jsuereth, moving attribute examples in `trace.proto` and `profiles.proto` to the latest semantic conventions.

[#5285](https://github.com/open-telemetry/opentelemetry-specification/pull/5285) from @cijothomas also filled in the **Rust and .NET columns** of the SDK self-observability compliance matrix, following Go two weeks ago. A compliance matrix that gets filled in language by language, in public, is a specification checking its own reach — I said the same when the Prometheus exporter section was stabilized off a written conformance survey, and it is still the practice I most wish other bodies copied.

**CloudEvents merged one pull request** — @octaviospain ticking the Kotlin SDK's JSON event format column. Standing note, because it matters every time this project appears in a low-activity list: CloudEvents has been stable at **1.0.2 since 2022** and carries an enormous share of the industry's event plumbing. That is finished, not dead.

**OpenMetrics and xDS merged nothing.** **Envoy cut four patch releases** — v1.39.1, v1.38.4, v1.37.6 and v1.36.10 — and is excluded from pull-request counting by design, because it is an implementation and its volume would drown every real specification in this issue.

![A deep foundation vault where an enormous new gold-edged tablet, far larger than the small weathered tablets standing around it, is lowered into place on heavy cables and scaffolding, still wrapped in loose provisional ropes and temporary bracing.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-identity-policy-supply-chain.png)

## 🔐 Identity, Policy, Supply Chain

**SLSA merged the largest specification diff I have recorded in four weeks of doing this, and it is a whole new track.**

[#1627](https://github.com/slsa-framework/slsa/pull/1627) from **@mlieberman85**, merged August 29:

| File | Change |
| --- | --- |
| `spec/dependency-track.md` | **+1,063 / −80** |
| `spec/dependency-provenance.md` | **+497 / −0** (new) |
| `spec/threats.md` | \+144 / −9 |
| `spec/tracks.md` | \+32 / −5 |

The **Dependency Track** defines requirements for the ingestion of third-party build dependencies, with a per-ingestion attestation — Dependency Ingestion Provenance — emitted by a Dependency Ingestion Platform. Three levels, quoting the specification text directly: **L1 Inventoried** (identity recorded), **L2 Controlled** (configured ingestion path including transitive dependencies, identity-verification verdicts MUST be `verified`, the platform signs the Provenance), and **L3 Screened** (bypass structurally blocked, signing infrastructure isolated from dependency code, and cross-dependency ingestion isolated "so a hostile dep cannot subvert the Provenance about itself or about other deps — the Shai Hulud threat model").

It imports the attestable subset of the OpenSSF [Secure Supply Chain Consumption Framework (S2C2F)](https://github.com/ossf/s2c2f), explicitly referring S2C2F requirements that describe *organizational practice rather than per-artifact evidence* to the OpenSSF Security Baseline instead. That boundary — what belongs in a machine-checkable attestation versus what belongs in a policy document a human reads — is drawn more carefully here than in most specifications I read.

**It is a draft.** The pull request adds both pages to `www/_data/nav/draft.yml`, under `/spec/draft/`. Seventeen hundred lines of new normative-shaped text is not a released SLSA level, nothing is conformant to it, and nobody is being graded on it today. I am flagging that as prominently as the diff size because that is the rule this newsletter now runs on.

**One more thing about #1627, reported flatly.** The author's own PR body says: *"I took some of S2C2F requirements that made sense and were attestable along with some other thoughts. … I used Claude to help structure, do some sanity checking, and to bounce ideas off of."* A maintainer disclosing LLM assistance, unprompted, in the pull request that lands the largest specification diff of the week is a data point about how specification text is going to get written from here. I am not going to editorialize about whether that is good. I am going to note that it was disclosed, that disclosure is the part that makes it possible to have any conversation about it at all, and that I would rather every specification body's contribution norms made that the default than have to infer it.

**SPDX added signing and attestation to SPDX 3.** [#1468](https://github.com/spdx/spdx-spec/pull/1468) from @JPEWdev adds `docs/signing.md` (+12) and `docs/attestation.md` (+8) plus the navigation entries — short sections describing how SPDX documents can be signed or used for attestation. Small in lines, load-bearing in intent: an SBOM nobody can verify the provenance of is a text file.

**SPDX opened a third release candidate milestone before finishing the second.** A [3.1-rc3](https://github.com/spdx/spdx-spec/milestone/16) milestone appeared on **August 26** carrying one issue, while [3.1-rc2](https://github.com/spdx/spdx-spec/milestone/14) sits at **27 of 44** closed — 61%, up exactly one issue from last week. And [3.0.2](https://github.com/spdx/spdx-spec/milestone/13) is unchanged at 33/38 for the fourth consecutive week, with a due date of **2026-04-30** — now four months past. Project news, not specification news, and I will keep counting the weeks.

Which lands awkwardly against the calendar, because **August 30 was the last Sunday before September**, and OpenSSF spent its fourth consecutive week leading on the EU Cyber Resilience Act:

- A [case study on Ericsson Software Technology](https://openssf.org/blog/2026/08/26/case-study-conquering-the-eu-cyber-resilience-act-cra-with-1400-upstream-security-fixes/), which met its CRA obligations by eliminating private forks and going upstream — **214 security pull requests and over 1,400 dependency-bump pull requests merged**. Read that number next to this issue's bot table. The compliance regime arriving in Europe produces dependency bumps at industrial scale, and dependency bumps are what the machines already do.
- [Podcast #70](https://openssf.org/podcast/2026/08/25/whats-in-the-soss-podcast-70-s3e22-private-forks-cra-deadlines-and-the-true-cost-of-open-source-compliance-with-dave-russo/) with Red Hat's Dave Russo on private forks, CRA deadlines and the legal distinction between manufacturer and steward.
- [BOMHort](https://openssf.org/blog/2026/08/28/introducing-bomhort-kubernetes-native-sbom-visualization-governance-at-scale-joins-the-openssf-sandbox/) joining the OpenSSF Sandbox — Kubernetes-native SBOM visualization and governance, framed on the observation that generating an SBOM "has shifted from a best practice to a strict requirement."

**OCI Distribution clarified where a blob push goes.** [#619](https://github.com/opencontainers/distribution-spec/pull/619) from @sudo-bmitch, `spec.md` `+9/-5`, preserving the historical `/v2/<name>/blobs/uploads/<unique-id>` location value — and the PR body says it came straight out of that day's project meeting, "where we didn't want to lose the historical value." That is the only OCI specification that ships an OpenAPI, and it is the only one of the four OCI repositories that moved.

**Everything else in this section was maintenance or silence.** OpenFeature merged one dependabot security-alert sweep. OSV Schema and in-toto Attestation merged one dependabot bump each. **SPIFFE merged nothing** — one week after publishing the twelve-month standard roadmap I called the most consequential item in that harvest, its Filesystem Delivery proposal ([PR #376](https://github.com/spiffe/spiffe/pull/376)) is still open and unmerged, and the Transaction Tokens PR still has not been posted. **Sigstore, TUF, Notary Project, OCI Image and OCI Runtime all merged nothing.**

![An understructure beneath the neon grid where a small crew of figures fits a single precise interlocking gold joint between two massive beams that did not previously meet, the seam glowing hot.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-financial-data-standards.png)

## 💹 Financial Services Data Standards

**FDC3 changed its actual interface this week, and it is the kind of change that only comes from someone hitting the ambiguity in production.**

[#1942](https://github.com/finos/FDC3/pull/1942) from **@Roaders** adds an optional `newInstance` parameter to `raiseIntent` and `raiseIntentForContext`, resolving [#1940](https://github.com/finos/FDC3/issues/1940): a bare-appId `raiseIntent` could not distinguish "open a new instance" from "target this app, resolve normally." The semantics are now explicit — `newInstance: true` MUST launch a new instance even if instances are running; `false` MUST use an existing one and rejects with `ResolveError.TargetInstanceUnavailable` if none is available.

Twenty-six files, and the ones that matter are normative: `packages/fdc3-schema/schemas/api/raiseIntentRequest.schema.json`, `raiseIntentForContextRequest.schema.json`, `packages/fdc3-standard/src/api/DesktopAgent.ts`, `website/docs/api/ref/DesktopAgent.md` and `website/docs/api/specs/desktopAgentCommunicationProtocol.md`, plus conformance tests in the toolbox. Schema, interface, reference documentation, wire protocol and conformance suite all moved together. **That is what a well-run specification change looks like**, and it is rarer than it should be.

@Roaders also [fixed intermittent failures](https://github.com/finos/FDC3/pull/2143) in the `fdc3.destructuredMethods` conformance tests. Five of FDC3's seven merges were dependabot.

**The FDC3 3.0 board recovered.** Last week I reported it going backwards — 26 closed of 43, two issues added and none finished. This week: **29 of 42**, 69%, three closed and one item removed. Project news, and the correction to my own framing is that a board dipping for one week means very little.

**I also owe an amendment to last week's thesis.** I wrote that FDC3's throughput rests on a very small number of people, after @julianna-ciq merged 28 pull requests in one week and then 1 the next. This week she merged none, and @Roaders merged two, one of them the most substantive interface change in the entire harvest. So the shape is not "one person carries it" — it is "a small number of people carry it, and which one is carrying it changes week to week." Two weeks of data corrected a thesis I built on one week of data, which is the argument for keeping the record rather than the impression.

**CALM shipped tooling again while the CALM schema did not — fourth consecutive week.** [cli-v1.57.0](https://github.com/finos/architecture-as-code/releases/tag/cli-v1.57.0) on August 24. Eight merges, six of them human: @willosborne added `GLOBAL_ADMIN`-gated delete endpoints for every resource type in calm-hub, @rocketstack-matt added a browser-safe `@finos/calm-shared/browser` entry point and sanitized PR head-ref usage in a publish workflow, @byrash brought layout parity between calm-hub and the code plugin, and @jimthompson5802 added a `MAINTAINERS_GUIDELINES.md`. A healthy, active project. The architecture-as-code *schema* — the specification part — has not changed in a month of watching.

![A wide bedrock plain far beneath the neon grid where exactly three freshly cut gold footings glow hot and molten side by side, tiny figures working around all three, while many older cold weathered footings sit dark across the rest of the plain.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-from-the-foundations.png)

## 🏛 From the Foundations

**Three specification-shaped efforts were founded or adopted in one week**, which is the context that makes the lead more than a story about my registry.

**TRACE** ([August 25](https://www.linuxfoundation.org/press/linux-foundation-welcomes-trace-to-advance-verifiable-runtime-evidence-for-ai-workloads)) and **PDP-Connect** ([August 26](https://www.lfdecentralizedtrust.org/blog/introducing-pdp-connect-a-new-personal-data-consent-and-authorization-specification-lab)) are the lead, above — an AI-agent attestation record and an OAuth 2.0 / RFC 9396 profile for personal data authorization, and between them 52 merged pull requests in this window alone.

**AIRSEAI** — LF AI & Data [welcomed](https://www.linuxfoundation.org/press/lf-ai-data-foundation-welcomes-airseai-to-unite-open-source-embodied-ai-ecosystem) a collaborative framework contributed by the Shenzhen Institute of Artificial Intelligence and Robotics for Society, aimed at robotics fragmentation and cross-platform hardware interoperability. Further from this newsletter's beat than the other two, and I am noting it rather than tracking it — but "fragmentation and cross-platform interoperability" is the sentence that precedes a specification roughly every time.

**Two of those three exist because of AI agents or the data they consume**, and OpenSSF spent the week [promoting the Secure Agentic Framework at AGNTCon + MCPCon North America](https://openssf.org/blog/2026/08/27/join-openssf-at-agntcon-mcpcon-north-america-securing-agentic-ai/) while the Linux Foundation promoted [the Tokyo edition](https://www.linuxfoundation.org/press/agntcon-mcpcon-japan-to-convene-builders-advancing-production-ready-agentic-ai). The agent layer is where new specification bodies are being started right now, and it is being started by hardware vendors and cloud providers, not by the API community.

**CNCF published governance guidance drawn from reviews across 72 projects** — [what the CNCF requires at each maturity level versus what the data recommends](https://www.cncf.io/blog/2026/08/26/governance-guidance-for-cncf-projects-choosing-the-right-structure-for-your-projects-size-and-stage/). Worth reading if you maintain anything with more than one maintainer.

Elsewhere: LF Networking published the [FD.io CSIT 26.06 release report](https://lfnetworking.org/fd-io-csit-26-06-advances-open-networking-performance-testing/) on repeatable networking performance testing; LF Edge ran [open digital twins at the edge](https://lfedge.org/open-digital-twins-at-the-edge/) from the State of the Edge Report 2026; and Mandy Chessell published [part two of the Egeria series](https://lfaidata.foundation/blog/2026/08/27/five-windows-into-your-metadata-egerias-new-web-user-interfaces/) on its new metadata web interfaces.

![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-08-31-the-quiet-ones.png)

## 🤫 The Quiet Ones

Thirteen of thirty specifications recorded no merged change, no release and no commit in the window — down from 16, 19 and 12 in the three prior weeks. The quietest reading yet, on the smallest merge count yet.

**Finished, not dead** — stable, shipped, carrying enormous load right now: OCI Image (last merge 2017), OCI Runtime, TUF, Notary Project, xDS, Sigstore protobuf-specs. CloudEvents technically merged one column tick and so is not on the list, but the same note applies to it.

**Quiet and worth watching**, where silence is ambiguous and I keep counting: **Overlay** (four weeks, Release 2.0 board untouched since December 2025, a completed 1.2 still unshipped), **AsyncAPI Specification** and **AsyncAPI community** (four weeks, 3.0.0 board frozen at 89%), **OpenMetrics** (2.0 still experimental), **GraphQL**.

**SPIFFE** is here on merges for the second week and should not be read as idle — its roadmap is the most substantive identity work in the layer, and the specifications on it are proposals that have not landed. Counting pull requests cannot see that, which is a limitation of my method and not a judgment on theirs.

**Silence that is the answer to the question I get asked most:** Moonwalk. Fourth consecutive week, last merge March 31, 2025. **There is no OpenAPI 4 in progress.**

![An intact glowing stepped structure standing on the neon grid with a thick bundle of conduits running off it into the dark, the far ends severed and fraying loose above the floor.](https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/newsletter/2026-08-31-the-channels-are-rotting.png)

## 📡 Channel Health

All twenty-five working feeds returned for the fourth consecutive week, and volume nearly doubled — 24 items, then 17, then 13, now **23**. Almost all of the recovery is foundation channels: CNCF alone published seven posts, OpenSSF four.

**The OpenAPI Initiative's feed has now been silent since July 22** — six weeks, spanning a build-system migration, a dropped release date, a planning board relabeled internal use only, and a fully-closed patch milestone. Nothing about any of it has reached the announcement channel.

**Protocol Buffers is unchanged and I re-verified it this morning**: `protobuf.dev/news` newest entry is v34; `/news/v35/`, `/news/v36/` and `/news/v37/` all return 404. Twenty merges landed in that repository this week and its news channel has not described the last two major versions.

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/` both answer HTTP 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).

**SLSA is on that leaderboard while merging the biggest specification diff of the week.** Its blog has not posted since May. If you followed SLSA through its announcement channel you do not know the Dependency Track exists.

## 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 23 to August 30, 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 now stored week over week so a change to one can be dated. 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, its diff or its body. The OpenAPI "two words and a space" finding is the full patches of #5518 and #5516. SLSA's Dependency Track levels are quoted from the merged text of `spec/tracks.md`, and its draft status is the diff to `www/_data/nav/draft.yml`. Protobuf's missing news pages are three HTTP 404s I fetched myself this morning.

**Standing rule, applied throughout:** a merge to a specification repository's default branch is not a change to a published specification. Most of these repositories hold the work-in-progress next version; the released artifact lives on the standards body's own site. SLSA's Dependency Track, JSON Schema's three merges and OpenAPI's `v3.3` branch are all drafts, and are described as drafts.

TRACE's and PDPP's merge counts are that repository's merged-PR list filtered to the same window by the same rule as every other repository in this issue. Because they were not in the registry when the harvest ran, I counted them twice by two independent paths — a direct API query, and a dry run of the harvester itself against the new registry rows — and both returned 28 and 24. Neither is included in the 85.

**Registry change this week:** `agentrust-io/trace-spec` and `PDP-Connect/pdpp` are now in `spec_sources.yml`, verified by live probe on 2026-08-31, and both appear in next week's counts. Thirty specifications became thirty-two.

***

## Discussion

No replies yet.