OKF and ARD Complementary by Accident - CourtneyR.dev's 2nd Brain

OKF and ARD: Complementary by Accident ![rw-book-cover](https://joost.blog/og/okf-ard.webp) 🔗 **Source:** [OKF and ARD: Complementary by Accident](https://joost.blog/okf-ard/) > [!note]+ Document Notes > tags: [agentic-web, open-source-governance, web-standards, interoperability, early-adoption, knowledge-packaging] > author: Joost de Valk > source: joost.blog > reference: https://joost.blog/okf-ard/ > date created: 2026-06-20 12:00 > > # 🏷️ Title: OKF and ARD: complementary by accident >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [specification.website](https://specification.website) — Joost's platform-agnostic site spec, source of the derived OKF bundle - [OKF spec page on specification.website](https://specification.website) (rated optional) - [ARD spec page on specification.website](https://specification.website) (rated optional) - Google Cloud — Open Knowledge Format (OKF) origin - Google developer blog — Agentic Resource Discovery (ARD) announcement - Linux Foundation — ARD base spec (Agent-Card/ai-catalog) - [joost.blog agent-ready plumbing](https://joost.blog) — runs ARD with a `did:web:joost.blog` identity ## 📝 Summary - **What happened.** Two new "agentic web" standards landed within a week of each other this month, both with Google's involvement: Open Knowledge Format (OKF), from Google Cloud, packages a knowledge base as typed Markdown concept files; Agentic Resource Discovery (ARD), announced on Google's developer blog atop a Linux Foundation base spec, is the discovery layer published at `/.well-known/ai-catalog.json`. Joost de Valk (Yoast founder) adopted both on specification.website and found they compose almost perfectly without referencing each other. - **Why it matters.** This is a working field report on how a still-forming standards layer actually gets composed, debugged, and improved by an early adopter — including filing the gaps back upstream. It models "ecosystem citizen" behavior for emerging agentic-web governance. - **Key stakeholders.** Google Cloud and Google's developer relations (the two spec authors), the Linux Foundation (base-spec steward), standards-body maintainers who must reconcile the field-name conflict, publishers adopting these specs, and AI agents that consume catalogs and bundles. - **Risks and tradeoffs.** The two specs disagree on a media-type field name (`mediaType` vs `type`); there is no registered media type for an OKF bundle, forcing an invented interim constant (`application/okf-bundle+gzip`); both specs are v0.9 drafts that can still move; Joost rates both "optional," not "recommended." - **Bottom line.** Don't wait for the dust to settle on a forming standards layer. Compose what exists, ship it publicly, and file what's missing upstream — that is what early adoption actually means. ## 📖 Main Content - **The two specs and what each does.** Open Knowledge Format (OKF), out of Google Cloud, packages a knowledge base: a tree of typed Markdown concept files with light front matter. It is deliberately narrow — serving the bundle and helping anyone find it are explicit non-goals, so a conformant OKF bundle sitting on a server is by design undiscoverable. Agentic Resource Discovery (ARD), announced on Google's developer blog and built on a Linux Foundation base spec, is the discovery layer OKF omits: you publish a catalog at `/.well-known/ai-catalog.json` listing what your domain offers, and an entry can point directly at an OKF bundle. - **Why they compose.** On their own each is partial — OKF packages a knowledge base it leaves undiscoverable; ARD is a discovery layer that only pays off when there's something worth pointing at. Composed, the catalog sends an agent straight to the bundle. That complementarity is why Joost shipped both rather than picking one. - **Everything derived, nothing hand-written.** specification.website is generated from one content collection: HTML pages, per-page Markdown mirror, llms.txt, and the data the MCP server reads are all derived from the same source. The OKF bundle is one more output of that pipeline, not a second copy to keep in sync. It comes to 604 Markdown files: 144 check concepts (paths mirror canonical URLs), 445 reference concepts (one per distinct cited source), plus OKF's index files; a `/okf.tar.gz` offers the whole thing in one fetch. The ARD catalog lists four pre-existing entries: the MCP server, the A2A agent, the Agent Skill, and the new bundle. - **The standard that disagrees with itself.** The AI Catalog format is pinned in two places — a base spec (`Agent-Card/ai-catalog`) and the ARD layer (`ards-project/ard-spec`) built on it — and they use different names for the media-type field: the base uses `mediaType`, ARD uses `type`. ARD also added a `representativeQueries` array. Joost's pragmatic fix: carry both field names with the same value in every entry. Because both specs require consumers to ignore unrecognised keys, the dual-field entry validates under either reading. - **The gap nobody registered.** There is no registered media type for an OKF bundle, so Joost invented `application/okf-bundle+gzip`, shipped as a single documented constant marked interim. Without a blessed type, a consumer can't recognise a bundle as OKF without opening it, and every publisher would invent a different string that never converges. So he filed the fix in both places — an issue on OKF to define and register the type, and one on ARD to recognise it (also flagging the `type` vs `mediaType` split) — offering the live bundle as a reference adopter. - **Optional, on purpose.** specification.website grades every feature required / recommended / optional / avoid. Both ARD and OKF pages are rated optional, not recommended, because they are v0.9 drafts that can still move; the site's rule is to adopt early but rate honestly. joost.blog also runs ARD atop its agent-ready plumbing with a `did:web:joost.blog` identity tied to a Bluesky account. - **Contested / uncertain.** Whether the two specs converge, which field name becomes canonical, and whether a registered OKF media type lands are all open. "Both have Google's fingerprints on them" is an attribution claim, not formal sole authorship — the base spec is a Linux Foundation artifact. ### 🗒️ Notes - Two agentic-web standards landed within a week; neither references the other; one (the AI Catalog format) doesn't even agree with itself on a field name. - OKF = Open Knowledge Format, from Google Cloud — packages a knowledge base as typed Markdown concept files with front matter. Deliberately narrow: serving and discovery are explicit non-goals. - A conformant OKF bundle on a server is, by design, undiscoverable — that's the gap ARD fills. - ARD = Agentic Resource Discovery, from Google's developer blog, built on a Linux Foundation base spec. Catalog lives at `/.well-known/ai-catalog.json`; an entry can point straight at an OKF bundle. - The two specs "fit exactly" by accident, not coordination — the headline thesis. - Derivation pipeline: one content collection → HTML, Markdown mirror, llms.txt, MCP data, AND the OKF bundle. The bundle is "one more output," not a synced copy. - Bundle size: 604 Markdown files = 144 check concepts (paths mirror canonical URLs) + 445 reference concepts (one per cited source) + OKF index files. Plus `/okf.tar.gz`. - ARD catalog lists four already-existing entries: MCP server, A2A agent, Agent Skill, new bundle. - Field-name conflict: base spec `Agent-Card/ai-catalog` uses `mediaType`; ARD layer `ards-project/ard-spec` uses `type`. ARD adds `representativeQueries` (sample prompts). - Fix: dual-field entries carry both `type` and `mediaType` with identical value; valid under either reading because both specs mandate ignoring unrecognised keys. - No registered media type for OKF bundles → invented `application/okf-bundle+gzip`, marked interim. Risk: every publisher invents a different string; they never converge. - "Ecosystem citizen" move: filed two upstream issues (OKF to define/register the type; ARD to recognise it + flag the `type`/`mediaType` split), offering the live bundle as reference adopter. - Both spec pages rated optional, not recommended — v0.9 drafts that can move; "adopt early but rate honestly." - joost.blog runs ARD too, with `did:web:joost.blog` identity tied to Bluesky — "a story for another day." - Closing frame: overlapping half-coordinated standards in one week is "the normal texture of a layer still forming," not a scandal. Useful response: compose, ship visibly, file what's missing. ## 📚 References - [OKF and ARD: complementary by accident](https://joost.blog/okf-ard/) — the article itself - [specification.website](https://specification.website) — the platform-agnostic site spec and source of the derived bundle - [okf.tar.gz](https://specification.website/okf.tar.gz) — the single-fetch OKF bundle Joost ships - Google Cloud — Open Knowledge Format (OKF) spec origin (primary) - Google developer blog — Agentic Resource Discovery (ARD) announcement (primary) - Linux Foundation — ARD base spec (`Agent-Card/ai-catalog`) (primary) - ARD layer spec (`ards-project/ard-spec`) (primary) - [joost.blog](https://joost.blog) — Joost's blog, runs ARD with `did:web:joost.blog` ## 🗣️ Paraphrase - Two agentic-web standards arrived this month within a week, both touched by Google, neither citing the other; Joost adopted both expecting overlap and found none. - OKF (Google Cloud) packages a knowledge base as typed Markdown files but deliberately refuses to handle serving or discovery, so a bundle sits undiscoverable. - ARD (Google dev blog, Linux Foundation base) is exactly the missing discovery layer: a `.well-known` catalog that can point straight at an OKF bundle, so the two compose perfectly. - Joost's whole site is generated from one content source, so the OKF bundle (604 files) is just another derived output, and the ARD catalog reuses four entries that already existed. - The AI Catalog format contradicts itself — base spec says `mediaType`, ARD layer says `type` — so Joost ships both field names with the same value, which validates under either spec. - There's no registered media type for an OKF bundle, so he coined an interim one and filed upstream issues on both specs to register and recognise it, offering his live bundle as a reference. - Both specs are v0.9 drafts rated "optional," and the lesson is that early adoption means composing what's there, shipping it publicly, and pushing the gaps back upstream rather than waiting. ## 📰 Newsletter **When two standards accidentally fit: Joost on OKF + ARD** Yoast founder Joost de Valk has a sharp little field report this week on the agentic web's plumbing — and there's a real lesson in it for anyone who cares about open standards and governance. Two specs landed within a week, both with Google's fingerprints: **OKF** (Open Knowledge Format, from Google Cloud) packages your knowledge base as typed Markdown files but flatly refuses to handle discovery; **ARD** (Agentic Resource Discovery, on a Linux Foundation base) is the `/.well-known/ai-catalog.json` discovery layer OKF leaves out. Neither references the other, yet they compose almost perfectly — the catalog points an agent straight at the bundle. Joost shipped both on specification.website, where the whole 604-file bundle is just another *derived* output of one content source (no second copy to keep in sync — chef's kiss). The juicy governance bit: the AI Catalog format disagrees with *itself* (`mediaType` vs `type`), and there's no registered media type for an OKF bundle at all. Rather than grumble, he carried both field names, invented an interim type, and filed fix-it issues upstream on both specs — offering his live bundle as a reference adopter. That's the takeaway worth stealing: "Being an early adopter is not only implementing the draft. It is finding the gap the draft left and pushing it back upstream." Adopt early, rate honestly, file what's missing. ## ✅ Action Items #### DevRel - Developer advocacy: write a talk/demo on composing OKF + ARD end-to-end, using a derived-from-one-source pipeline as the reference pattern. - Education: a workshop on `/.well-known/ai-catalog.json` authoring and on packaging a knowledge base as an OKF bundle. - Developer experience: publish a quickstart + template for a dual-field (`type` + `mediaType`) catalog entry that validates under both base and ARD specs. - Developer marketing: clip the "find the gap and push it upstream" framing as evergreen standards-citizenship content. - Community management: open a thread for early adopters to share interim media-type strings and converge on one before fragmentation sets in. - Internal/external/cross-project: coordinate with Google Cloud (OKF) and Google DevRel (ARD) maintainers on the field-name reconciliation. #### OSPO - Policy & Governance: define an internal "early-adopter etiquette" policy — adopt drafts, but file gaps upstream and mark invented constants interim. - License Compliance: confirm licensing/terms of the OKF and ARD specs and the Linux Foundation base before productizing adoption. - Security Management: review what a public `.well-known` catalog exposes about a domain's agent surface; threat-model discoverability. - Software Inventory: catalog which derived outputs (HTML, llms.txt, MCP data, OKF bundle) come from the single content source; track freshness SLOs. - Developer Support: consultation hours on adopting agentic-web specs and on `did:web` identity binding. - Community Engagement: fund or co-sign the upstream issues to register an OKF media type. - Strategic Alignment: track "specs adopted + gaps filed upstream" as an OSPO contribution KPI. #### Community - Maintainers: governance template for "two overlapping specs from related orgs" — how to reconcile field names without breaking either. - Contributors: a "first issue" rotation pointed at filing/clarifying spec gaps (like the `type` vs `mediaType` split). - Sponsors: report standards-citizenship contributions (upstream issues, reference adopters) as funded impact. - Ecosystem: coordinate a cross-publisher convention for the interim OKF bundle media type until registration lands. #### WordPress - Core: monitor whether agentic-web discovery (`.well-known/ai-catalog.json`) becomes something WordPress should expose by default. - Core Performance: assess cost of generating/serving derived bundles at scale; publish baselines. - Core AI: track OKF/ARD as candidate standards for exposing WP content to agents; document the "derive, don't duplicate" pattern. - **Core Program Team:** coordinate a cross-team position on agentic-web standards adoption. - Mobile: Not applicable to this source. - Playground: a reproducible lab that builds an OKF bundle + ARD catalog from a sample site. - Community: a WordCamp session on agentic-web readiness and open-standards citizenship. - Training: learning path on `.well-known` discovery, OKF packaging, and `did:web` identity. - Marketing: amplify the "open standards composed by accident" governance story. - Support: anticipate questions on adding agent catalogs to WordPress sites. - Design: document how typed-Markdown concept files map to editorial content models. - Documentation: examples-first guide to deriving an OKF bundle from one content collection. - Photos / TV / Openverse: Not applicable to this source. - Polyglots: glossary for OKF, ARD, agentic web, `.well-known`, `did:web`, media type. - Accessibility: ensure spec/doc pages and any generated HTML meet WCAG 2.2 AA (see Accessibility Assessment). - Meta: consider whether .org should publish an agent catalog and register relevant media types. - CLI: a WP-CLI command to emit an OKF bundle / `.well-known` catalog could be valuable — scope it. - Hosting: document serving `.well-known/ai-catalog.json` and `okf.tar.gz` across hosts. - Tide / Themes / Plugins: Not applicable to this source. #### The WPCC - Programs: a fellowship on open-standards stewardship — adopt, document, file upstream. - Projects: documentation sprint translating OKF/ARD into ecosystem-readable adoption guides. - Funding experiments: microgrants for reference adopters who file the gaps they find upstream. ### FAIR - Technical independence: a derived-from-one-source pipeline with local metadata and a `did:web` identity is a textbook independence + provenance play — document it. - Policies and covenants: codify "adopt early but rate honestly" and "mark invented constants interim" as anti-fragmentation covenants. - Productized governance artifacts: an adoption scorecard rating each spec required/recommended/optional/avoid, plus an upstream-issue log as a citizenship artifact. ## 🧪 Hypotheses - H1: Standards layers seeded by closely related teams (here, two Google orgs) will exhibit accidental complementarity more often than direct conflict, because each scopes itself narrowly to one concern. - H2: Early adopters who file upstream gaps (issues, reference adopters) accelerate spec convergence faster than adopters who merely implement and wait. - H3: Unregistered media types in a forming spec lead to publisher-specific divergence that does not self-converge without a registration authority stepping in. - H4: A "derive everything from one content source" architecture lowers the marginal cost of adopting each new agentic-web output (bundle, catalog, llms.txt) toward near-zero. - H5: Dual-field tolerance ("ignore unrecognised keys") in competing specs is sufficient to let an adopter satisfy both until the specs reconcile. ### 📊 Methodology - H1: catalog emerging agentic-web specs by authoring org and scope; code each pair as complementary / overlapping / conflicting; test association between shared-org provenance and complementarity. - H2: track time-to-convergence (field-name unification, media-type registration) for specs with vs. without active early-adopter upstream issues; event-study around issue filings. - H3: longitudinally scrape published catalogs for the OKF bundle media-type string; measure string diversity over time absent vs. after registration. - H4: instrument the specification.website build pipeline; measure incremental build cost per added derived output. - H5: validate a corpus of dual-field catalog entries against both base and ARD validators; measure pass rate. ### ❓ Questions - Which field name wins — `mediaType` (base) or `type` (ARD) — and who decides? - Will an OKF bundle media type get registered, and through which authority (IANA, the spec repos, Linux Foundation)? - Does the accidental complementarity survive the next spec revisions, or does coordination (or competition) break it? - How long should an interim constant stay "interim" before it becomes de facto permanent? - What does a public agent catalog reveal about a domain that publishers may not intend to expose? ### 🔮 Future Research - Empirical study of convergence dynamics in forming web-standards layers (field-name and media-type reconciliation). - The governance economics of "ecosystem citizen" behavior: do reference adopters measurably speed standardization? - Patterns for single-source content pipelines that emit multiple agentic-web artifacts without drift. - Security/privacy implications of `.well-known` agent-discovery surfaces. - The role of `did:web` identity in binding published agent resources to verifiable publishers. ### 💡 Implications - **Practice:** Derive agentic-web outputs from one content source instead of maintaining parallel copies; adopt drafts but rate their maturity honestly. - **Policy:** Standards bodies need a fast path to register media types and reconcile field-name conflicts before publisher divergence ossifies. - **Security:** Public agent catalogs expand a domain's disclosed surface; governance must threat-model what discoverability reveals. - **Education:** Teach standards citizenship — implementing a draft *and* filing the gap upstream — not just consumption. - **Funding models:** Funders can treat upstream issue-filing and reference adoption as fundable ecosystem contributions, not unpaid side effort. ### 🧠 Learning Styles Assessment - Reading level estimate: dense expository prose with technical nouns (media type, front matter, `.well-known`, `did:web`); estimated Flesch–Kincaid Grade 11–13, Flesch Reading Ease ~40–50. Sentences are short and declarative, which eases an otherwise specialist topic. #### 👀 Visual learners - Present: one fenced JSON code block (the dual-field catalog entry); an inline table comparing the two specs' media-type field names. - Improve: an architecture diagram of source → derived outputs (HTML, Markdown mirror, llms.txt, MCP data, OKF bundle); a sequence diagram of agent → catalog → bundle; a before/after of single vs. dual field. #### 🔊 Aural learners - Present: none — text-only blog post. - Improve: a 2–3 minute audio summary or TTS version; a short narrated walkthrough of the compose-and-file workflow. #### 🗣️ Verbal learners - Present: clear definitions of OKF and ARD inline; vivid phrasings ("disagrees with itself," "the gap nobody registered," "ecosystem-citizen thing"). - Improve: a glossary callout (media type, front matter, conformant bundle, `.well-known`, `did:web`). #### 🧩 Kinesthetic learners - Present: a copyable JSON entry and a real live bundle URL to fetch. - Improve: a step-by-step lab to build a bundle + catalog and validate it under both specs. #### 🧠 Logical learners - Present: clean cause→effect (OKF undiscoverable → ARD discovery → composed they fit); the comparison table. - Improve: a decision tree for "which field name to ship"; a flow showing how "ignore unrecognised keys" yields dual-field validity. #### 🧑‍🤝‍🧑 Social learners - Present: implicit community framing (filing issues, being an "ecosystem citizen"). - Improve: discussion prompts for adopters; links to the upstream issue threads for participation. #### 🧘‍♀️ Solitary learners - Present: a reflective, opinionated single-author narrative. - Improve: a self-check ("what derived outputs does my site already emit?") and a journaling prompt on early-adoption etiquette. #### 🌿 Naturalistic learners - Present: the "normal texture of a layer that is still forming" ecosystem-as-organism metaphor. - Improve: a lifecycle framing of a spec from v0.9 draft → registered → recommended; "ecosystem health" indicators for a standards layer. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: a blog article with headings and a structured comparison table (assumed marked up as a real `<table>`). - Improve: ensure the table has proper `<th>` scope; give the code block an accessible label; verify heading hierarchy on the rendered page. #### Keyboard navigation - Present: standard static article — links keyboard-reachable by default. - Improve: verify visible focus styles and logical tab order on the rendered joost.blog page. #### Contrast and readability - Present: cannot verify from text; joost.blog generally uses readable typography. - Improve: confirm 4.5:1 text contrast and adequate contrast on code-block syntax colors and link states. #### Text resizing and reflow - Present: cannot verify from text. - Improve: confirm the comparison table and JSON block reflow without horizontal scroll or clipping at 200% zoom and on narrow viewports. #### Media and captions - Present: no audio/video — text-only, so captioning is not implicated. - Improve: if a future audio summary is added, ship a transcript; provide a text alternative for the table data. #### Forms and interactions - Present: none beyond standard blog navigation. - Improve: ensure any comment/subscribe form has labels, error handling, and adequate target size. #### Standards reference - Maps to WCAG 2.2 AA: 1.3.1 Info & Relationships (table semantics), 1.4.3 Contrast (Minimum), 1.4.10 Reflow, 1.4.4 Resize Text, 2.1.1 Keyboard, 2.4.6 Headings and Labels, 2.4.7 Focus Visible, 2.5.8 Target Size (Minimum). ### 🌍 DEIB Assessment #### Cultural breadth - Present: neutral, globally legible technical subject; no region-locked references. - Improve: examples beyond Google/Linux Foundation orgs; note non-English documentation and global adopter perspectives. #### Inclusive language - Present: plain, jargon-defined-on-first-use language; no exclusionary terms. - Improve: expand a glossary for readers new to agentic-web vocabulary; avoid assuming familiarity with `did:web`/`.well-known`. #### Neurodiversity support - Present: short declarative sentences, consistent section structure, clear subheads ("Two ideas that connect," "The gap nobody registered"). - Improve: add a TL;DR/summary box and icon+text signposting for the key steps (compose → ship → file). #### Representation - Present: single expert author voice (Joost de Valk); limited to one practitioner's vantage. - Improve: cite or link other adopters and spec maintainers to broaden whose experience is represented. #### Psychological safety - Present: non-blaming framing — "not a scandal," "the normal texture of a layer still forming"; treats spec conflicts as routine, lowering adopter anxiety. - Improve: explicitly reassure newcomers that interim/imperfect adoption is acceptable and reversible. ### ✅ Logical Validity #### Strong reasoning - **Deductive (complementarity):** "OKF leaves discovery as an explicit non-goal" + "ARD is exactly a discovery layer" ⟹ they compose. Valid given the premises, drawn straight from each spec's stated scope. Clarify by stating the shared data model (an ARD entry can carry an OKF bundle URL + type) that makes composition mechanical, not merely conceptual. - **Inductive (forming-layer claim):** from one week's two-spec overlap, infers "the normal texture of a layer still forming." Reasonable but single-instance; strengthen with more examples of early-layer overlap. - **Causal (no registered type → divergence):** "without a blessed type… every publisher will invent a different string, and they will never converge." Plausible coordination-failure mechanism; strengthen by citing prior media-type fragmentation cases. - **Pragmatic (dual-field fix):** both specs require ignoring unrecognised keys, therefore a dual-field entry validates under either — a sound, well-grounded engineering inference. #### Fallacies - **Hasty generalization** — quote: *"Two overlapping, half-coordinated standards in a single week is not a scandal. It is the normal texture of a layer that is still forming."* Location: closing paragraph. Weakness: a sweeping claim about how standards layers behave, generalized from a single week's pair. Fix: frame as a hypothesis ("this looks like…") or cite additional examples of early-layer overlap. - **Loaded / suggestive framing (mild)** — quote: *"Both have Google's fingerprints on them."* Location: opening. Weakness: "fingerprints" implies coordinated authorship the post later undercuts (ARD's base is a Linux Foundation spec); slightly overstates common provenance. Fix: state precisely which org authored which artifact and that the base spec is Linux Foundation–governed. - **Anthropomorphism / rhetorical overstatement (minor)** — quote: *"one does not even agree with itself about what to call a field."* Location: opening and the "standard that disagrees with itself" section. Weakness: dramatizes a documentation inconsistency between two layered specs as self-contradiction. Fix: describe it plainly as a base-vs-layer field-name mismatch (which the body in fact does). #### Tone of voice - Confident, wry, practitioner-first, and constructively opinionated — e.g., "So I did the ecosystem-citizen thing" and "Being an early adopter is not only implementing the draft." Pedagogical without condescension; closes with an action-oriented imperative rather than a complaint. ### 🛡️ DARVO Analysis - Deny: Not applicable — the author makes no denials; he plainly names the specs' shortcomings (field conflict, missing media type) rather than minimizing them. - Attack: Not applicable — no accuser exists and no party is attacked; spec authors are treated neutrally, with gaps filed upstream rather than blamed. - Reverse victim/offender: Not applicable — no victim/offender dynamic is present; this is a constructive technical field report. - Overall: DARVO is not applicable to this source. Reason: it is a single-author, non-adversarial technical post that acknowledges problems openly and proposes fixes, with no defensive reframing of any accusation. ## 🎯 Conclusion - **Bottom line.** OKF (packaging) and ARD (discovery) were authored independently yet compose almost perfectly because each scopes itself to one concern; Joost adopted both on specification.website as derived outputs of a single content source, patched the specs' self-contradiction (`mediaType` vs `type`) with dual-field entries, invented an interim OKF-bundle media type, and filed the gaps upstream. The real lesson is governance behavior: in a forming standards layer, compose what exists, ship it where people can see it, and push what's missing back upstream. - **Next steps for readers.** (1) Audit what derived agentic-web outputs your site could emit from one content source (llms.txt, OKF bundle, `.well-known` catalog). (2) When adopting a draft spec, ship dual-field/tolerant entries so you satisfy competing readings. (3) When you hit a gap (an unregistered type, a field conflict), file it upstream and offer yourself as a reference adopter. (4) Rate each spec honestly (required/recommended/optional/avoid) rather than overselling drafts. ## 🔄 Refactor Appendix — OKF and ARD: complementary by accident > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults applied: 3 Literature, 1 Permanent. Resonance filter on. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Narrow specs compose because each leaves the other's gap > [!quote] ID:rw_pending > "OKF packages a knowledge base it deliberately leaves undiscoverable, and ARD is a discovery layer that only pays off when there is something worth pointing at." **Context & use**: - Core thesis: complementarity by accident, not coordination. - Cross-ref Open Source Governance MOC — interoperability via scoped, single-concern specs. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending)  #### [H2] Early adoption means filing the gap upstream, not just implementing > [!quote] ID:rw_pending > "Being an early adopter is not only implementing the draft. It is finding the gap the draft left and pushing it back upstream." **Context & use**: - The "ecosystem-citizen" move: two upstream issues + live bundle as reference adopter. - Cross-ref Commons & Community Governance MOC — contribution norms. **Tags**: #xref #aphorisms #share **Highlight**: [view highlight](readwise://pending)  #### [H3] Dual-field tolerance lets one entry satisfy conflicting specs > [!quote] ID:rw_pending > "Both specs require consumers to ignore keys they do not recognise, so the dual-field entry validates under either reading." **Context & use**: - Pragmatic fix for the `mediaType` (base) vs `type` (ARD) split. - Generalizable pattern for adopting competing draft specs. **Tags**: #xref **Highlight**: [view highlight](readwise://pending)  #### [H4] Unregistered media types fragment without a registration authority > [!quote] ID:rw_pending > "Every publisher will invent a different string, and they will never converge." **Context & use**: - Why Joost marked `application/okf-bundle+gzip` interim and filed for registration. - Cross-ref FAIR — provenance and shared metadata conventions. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending)  ### 🧠 Permanent Candidates (H4) #### [P1] Standards citizenship is implementing plus filing the gap upstream **Claim** (one sentence, Courtney's voice): An adopter contributes to an open standard's maturity only when they both implement the draft and push the gaps they find back upstream as registrable fixes and reference implementations. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for forming, governance-light standards layers where registration authorities and reconciliation paths exist. Breaks where a spec is frozen/closed, or where no upstream channel accepts contributions. **Links**: - [[Open Source Governance MOC]] — because extends - [[Commons & Community Governance MOC]] — because applies-in contribution norms - [[FAIR]] — because evidence-for provenance/interoperability via shared conventions  ### ✏️ Fleeting Queue - [F1] Audit which derived agentic-web outputs (llms.txt, OKF bundle, `.well-known/ai-catalog.json`) a WordPress site could emit from one content source — https://joost.blog/okf-ard/ #fleeting #inbox - [F2] Open question: how long should an "interim" media-type constant stay interim before it becomes de facto permanent? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft an "open-standards citizenship: adopt, then file the gap upstream" note for the WordPress governance audience — #things - [ ] Add the OKF/ARD "complementary by accident" case to the Open Source Governance MOC — #things  📄 **Full text:** ![[Full Document Contents/Articles/OKF and ARD Complementary by Accident.md|OKF and ARD: Complementary by Accident by joost.blog]] ## Highlights - [Agentic Resource Discovery](https://agenticresourcediscovery.org/) (ARD), announced on Google’s developer blog and built on a Linux Foundation base spec, is the discovery layer OKF leaves out. You publish a catalog at `/.well-known/ai-catalog.json` listing what your domain offers, and an entry can point straight at an OKF bundle. On their own, each is partial: OKF packages a knowledge base it deliberately leaves undiscoverable, and ARD is a discovery layer that only pays off when there is something worth pointing at. Composed, they fit exactly, with the catalog sending an agent straight to the bundle. That is why I shipped both instead of picking one. ([View Highlight](https://read.readwise.io/read/01kvkrnm3g4ja0aa7rge6zsw47)) - Note: H1 — the complementarity thesis: OKF (packaging, deliberately undiscoverable) + ARD (discovery, needs something to point at) compose exactly — a catalog at /.well-known/ai-catalog.json pointing to an OKF bundle. - Tags: open-standards, atom/literature/h1 - Both specs require consumers to ignore keys they do not recognise, so the dual-field entry validates under either reading. Early adoption sometimes means carrying two spellings of the same field until the base spec and the layer built on it line up. ([View Highlight](https://read.readwise.io/read/01kvkrnt3ksxcccgj8d8xf2ksn)) - Note: H3 — the dual-field tolerance pattern: because both specs ignore unrecognized keys, a dual-field entry validates under either — carry two spellings until the specs align. - Tags: open-standards, atom/literature/h3 - So I did the ecosystem-citizen thing and filed the fix in both places, offering the live bundle as a reference adopter: [one issue on OKF](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/111) to define and register the type, and [one on ARD](https://github.com/ards-project/ard-spec/issues/27) to recognise it, which also flagged the `type` versus `mediaType` split. Being an early adopter is not only implementing the draft. It is finding the gap the draft left and pushing it back upstream. ([View Highlight](https://read.readwise.io/read/01kvkrnqcphrcytjvxf5hk82m4)) - Note: H2 + Permanent: real adoption of an open standard = implement the draft AND push the gaps you find back upstream as registrable fixes + reference implementations. - Tags: atom/zettel/z1, atom/literature/h2