ReadMe vs Fern

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   ReadMe✓fullprobed9/10

   ReadMe hosts a verified llms.txt at docs.readme.com/llms.txt (probe confirms HTTP 200) plus per-page .md access, dedicated llms.txt-style docs for customizing/writing/workflows/ai sections, an Agent-Friendly Docs scoring feature (ai-discoverability), and an official MCP server giving agents live access to API specs and docs. missing for 10: independent/hands-on third-party confirmation that an external agent successfully consumes the llms.txt content end-to-end (only first-party docs and one probe corroborate this).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Get your API documentation live in three steps: create a project, upload your API definition, and write your first guide.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Draft, edit, and research documentation from the AI chat panel.”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

   Fern✓fullprobed9/10

   Fern documents and probes confirm automatic llms.txt generation, clean Markdown pages via .md suffix, agent directives, and this is independently verified by a live probe returning HTTP 200 with agent instructions at /llms.txt. Fern also hosts an MCP server and analytics for llms.txt usage. Missing for 10: independent third-party (non-Fern-docs) confirmation of agent consumption in the wild beyond the one probe.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “To override the default, set a custom directive using the `agents` key in `docs.yml`”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Fern
   ReadMe~partialprobed6/10

   ReadMe ships an official CLI (rdme) and a documented REST API for controlling docs programmatically, both of which support headless/CI automation (e.g., syncing OpenAPI specs in pipelines). However, the evidence pack lacks explicit CI/CD workflow examples, headless-mode documentation, or community confirmation of CI usage. Missing for 10: explicit CI pipeline examples/docs, headless-mode guarantees, and independent confirmation of automated CLI/API use in production pipelines.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

   Fern✓fullprobed7/10

   Fern's CLI is explicitly designed for automation: every command outputs JSON for piping/scripting, and it's distributed via installers (Homebrew, npm, curl) enabling CI installation and headless use for validating, generating SDKs, and publishing docs. Fern Agent can also run on a schedule to open PRs automatically, further supporting headless/CI workflows. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions snippet), no independent/community confirmation of headless CI usage.

   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   ReadMe✓fullprobed8/10

   ReadMe documents an official, project-specific MCP server that gives AI coding assistants (Cursor, Claude Code, VS Code Copilot) a live connection to API specs/docs, backed by dedicated MCP metrics/analytics and confirmed live via probe. missing for 10: independent/hands-on third-party verification that the MCP connection works as described beyond first-party docs.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “MCP Metrics”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

   Fern✓fullprobed8/10

   Fern is a documentation/SDK platform, not an agent itself, so this axis clearly applies; Fern documents an official, automatically generated MCP server for every docs site (and a private org-wide MCP server) that coding agents like Claude Code, Cursor, and Windsurf can register with to query docs, CLI syntax, and site data. Missing for 10: independent/hands-on verification beyond first-party docs and probes confirming the MCP endpoint is live and functional.

   • [claimed-docs] “Fern automatically generates and hosts a production-ready Model Context Protocol (MCP) server for every documentation site with Ask Fern ena…”
   • [claimed-docs] “Register it with your coding agent to look up `docs.yml` syntax, components, and CLI commands while you build, and to read your sites, deplo…”
   • [claimed-docs] “The server connects AI clients like Claude Code, Cursor, and Windsurf to your documentation as an external data source, so your readers can …”
   • [claimed-docs] “Fern hosts a private Model Context Protocol (MCP) server for your organization, with full context on Fern’s documentation and configuration”
   • [probe] “official MCP server documented at https://buildwithfern.com/learn/docs/ai-features/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Fern
   ReadMe~partialprobed5/10

   ReadMe does maintain an official CLI (rdme) per the GitHub probe, confirming the capability exists, but the evidence pack contains no first-party documentation detailing the CLI's commands, AI-native workflow support, or independent corroboration of its use. missing for 10: detailed CLI docs/feature list, AI-native workflow examples, independent/hands-on usage confirmation.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Fern✓fullprobed9/10

   Fern ships an official CLI (fern-docs-1) distributed via signed binaries on Homebrew, npm, pnpm, Scoop, and curl (fern-docs-35), with AI-native design explicitly called out: every command outputs JSON so coding agents can pipe calls (fern-docs-34), and probe confirms official CLI docs exist (fern-probe-5). Missing for 10: independent/hands-on community verification of CLI's agentic JSON behavior beyond vendor docs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to ReadMe
   ReadMe✓fullprobed8/10

   ReadMe documents a full public API ('Control your docs programmatically with the ReadMe API') plus a companion developer-metrics API and an open-source CLI (rdme) that wraps it, giving AI-native users a documented, scriptable interface to drive the product. missing for 10: independent/hands-on confirmation that the API works as documented and more detail on API reference completeness beyond the one-line docs mention.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”

   proof ↗⚑ flag

   Fern~partialprobed6/10

   A probe confirms Fern publishes a public OpenAPI spec at buildwithfern.com/openapi.json, and the CLI is documented to emit JSON so 'coding agents can pipe one call into the next,' giving AI-native users a programmatic path to drive the product. However, there's no explicit first-party 'API reference' page for Fern's own platform API (only the raw spec) and no independent confirmation of usage. Missing for 10: a dedicated documented API reference page, independent/community corroboration of driving Fern via its API, and clearer distinction between Fern's own platform API vs. customer-generated SDKs.

   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   ReadMe—none0/10

   While ReadMe exposes an MCP server and a general ReadMe API, the evidence pack contains no mention of issuing scoped or least-privilege API credentials specifically for AI agents (e.g., agent-specific API keys, permission scopes, or token restrictions) — only general API key injection for docs personalization and generic API access control.

   ⚑ flag

   Fern—none0/10

   Fern is a docs/SDK generation platform; no evidence describes issuing scoped or least-privilege API credentials/keys for an agent — only visitor authentication (JWT/SSO) and password-protected docs are mentioned, which are for human readers, not agent credential scoping.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Fern
   ReadMe~partialprobed3/10

   ReadMe documents a public REST API and an official CLI (rdme) that developers can build against programmatically, but there is no evidence of dedicated official client SDKs in multiple languages (e.g., Python, Node, Go) for integrating with the ReadMe platform itself — 'Pick a language' refers to code-sample generation for the API reference of the docs being hosted, not an SDK for ReadMe. Missing for 10: explicit official multi-language SDKs, independent/hands-on validation of SDK quality, and clear API-vs-SDK distinction.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Pick a language”

   proof ↗⚑ flag

   Fern✓fullcommunity8/10

   Fern is explicitly a SDK generator platform producing type-safe, idiomatic client libraries in 9+ languages (TypeScript, Python, Java, Go, Ruby, PHP, C#) from a single API spec, with pagination helpers and other SDK-native features, positioning it squarely for AI-native developers to build against generated official SDKs; community corroboration (HN) confirms it delivers end-to-end SDK generation. missing for 10: independent hands-on verification of SDK quality/reliability across all languages, and clearer evidence of long-term maintenance/versioning guarantees for generated SDKs.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [claimed-docs] “Generate client libraries in multiple languages.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “Pagination helpers. Cursor-based and offset-based pagination are first-class.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   ReadMe~partialclaimed6/10

   ReadMe offers AI-generated insights within the product itself: the AI Linter/Docs Audit checks content against natural-language rules, the AI Agent and Inline AI can draft/rewrite/enhance content, and Ask AI surfaces answers from docs; API/MCP Metrics also surface usage insights though these are analytics dashboards rather than AI-generated suggestions. However, evidence is entirely vendor documentation with no independent/hands-on validation of the AI suggestions' quality or accuracy. missing for 10: independent/hands-on evidence of AI insight quality, examples of AI-generated suggestions in practice, and confirmation that analytics (metrics) include AI-driven interpretation rather than raw charts.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “Draft, edit, and research documentation from the AI chat panel.”
   • [claimed-docs] “An AI-powered tool for checking page content against your own style guide.”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern Agent automations can review reader feedback, unanswered Ask Fern questions, search queries, and analytics, then report findings and open a PR with suggested doc changes — a form of AI-generated insight/suggestion from in-product usage data. However this is scoped narrowly to documentation analytics/feedback rather than general 'my data' insights, and there's no independent corroboration beyond first-party docs. Missing for 10: broader data-source insight generation beyond docs analytics, independent/hands-on verification of Fern Agent's insight quality, and evidence of proactive dashboards or analytics summarization beyond the changelog mention.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Fern
   ReadMe~partialclaimed4/10

   The GitHub AI Writer feature watches pull requests in the background and autonomously proposes documentation updates when code changes affect docs (readme-docs-8), which is the only evidence of a background automation. However, this is a single fixed integration (not a general automation framework), still requires human review/approval before changes go live (readme-docs-12/27), and there's no evidence of user-configurable autonomous background jobs, schedules, or triggers beyond this one PR-watching feature. missing for 10: general-purpose automation/workflow builder, evidence of fully unattended (no-approval) execution, multiple autonomous background triggers beyond PR-watching, independent confirmation of autonomy in practice.

   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern Agent can be scheduled to autonomously review reader feedback, unanswered questions, search queries, or analytics, report findings, and open a PR when appropriate — a genuine background automation. However, this is scoped narrowly to documentation-maintenance tasks rather than general-purpose autonomous automations, and detail on scheduling configuration, reliability, or failure handling is thin. Missing for 10: broader automation scope beyond docs upkeep, independent/hands-on verification of the scheduled agent working reliably, and more detail on configuring/monitoring these background runs.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Fern
   ReadMe~partialclaimed6/10

   ReadMe ships an in-product 'Agent' documentation assistant that creates, edits, and enhances content across Guides, API References, and Custom Pages, plus inline AI editing via natural-language prompts — a genuine built-in AI assistant users can delegate documentation tasks to. However, this is scoped to docs authoring/editing tasks, not general task delegation, and there's no independent/hands-on corroboration of the Agent's reliability or scope beyond vendor docs. missing for 10: independent or hands-on verification of the Agent's capabilities and limits, evidence of broader task delegation beyond content editing, and any community feedback on the Agent feature specifically.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”

   proof ↗⚑ flag

   Fern✓fullclaimed7/10

   Fern ships a built-in 'Fern Agent' that users can prompt or schedule to review reader feedback, unanswered questions, or analytics, then autonomously open a pull request with the requested changes — a genuine in-product AI assistant task-delegation feature (fern-docs-8, fern-docs-25, fern-docs-29, fern-docs-42, fern-docs-45). It can also be triggered via Slack for ad hoc tasks (fern-docs-45), going beyond simple Q&A like Ask Fern. Missing for 10: independent/hands-on verification of Fern Agent's reliability, and more detail on the scope of tasks it can safely handle beyond docs edits.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   ReadMe~partialclaimed6/10

   ReadMe's Agent and Inline AI let users edit and enhance docs content via plain-language prompts, and the Linter lets you define documentation rules in natural language, showing genuine NL-driven operation of core content-editing workflows. However, this is scoped to content editing rather than full product operation (e.g., configuring project settings, analytics, or publishing via NL commands), and there's no independent/hands-on corroboration beyond first-party docs. Missing for 10: evidence of NL control over broader product functions (settings, analytics, admin tasks) and independent verification of the Agent/Inline AI working as described.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern Agent lets users describe desired documentation changes in natural language (e.g., via Slack or scheduled prompts) and it reads the repo, makes edits, and opens a PR, and Ask Fern answers NL questions over docs; the CLI also emits JSON for agent piping. However, this NL-command capability is scoped mainly to docs content/maintenance, not core product operations like SDK/OpenAPI generation or CLI config, and there is no independent/hands-on evidence confirming reliability. Missing for 10: broader NL control over SDK generation and CLI workflows, independent/hands-on verification of Fern Agent's accuracy, and evidence of NL commands driving core product configuration rather than just docs edits.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make test calls and see real responses without writing code, backed by OpenAPI upload/management for generating that reference, and community feedback corroborates strong API reference/Swagger support versus alternatives. missing for 10: independent hands-on validation specifically of the 'runnable examples' UX (only vendor docs cited) and no direct AI-native user testimonial trying the runnable examples.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Fern~partialclaimed5/10

   Fern generates full API reference documentation from OpenAPI specs (including GraphQL type pages) and produces SDKs in multiple languages with code snippets, which is the foundation for an interactive reference. However, the evidence never explicitly documents a 'try it now' / runnable request console or live execution feature within the API reference itself. missing for 10: explicit documentation of an interactive 'try it' console or live request execution, hands-on/independent confirmation of runnable examples.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Fern
   ReadMe—none0/10

   Evidence documents ReadMe's ability to upload/manage an OpenAPI spec to generate docs (readme-docs-23) and export docs/PDF files (readme-docs-13/29), but there is no evidence of a feature letting a user download the underlying OpenAPI spec (JSON/YAML) as a machine-readable artifact. Missing for 10: any documented spec-download endpoint, export-as-OpenAPI option, or explicit machine-readable API spec retrieval capability.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Fern✓fullprobed8/10

   Fern generates API references from OpenAPI specs (fern-docs-22) and the product's own site exposes a live, machine-readable openapi.json confirmed via probe (fern-probe-3), demonstrating the platform both consumes and can serve OpenAPI specs. Missing for 10: no explicit first-party doc describing a built-in 'download/export spec' button for end-customers' generated docs sites, and no independent third-party confirmation of that export UX beyond the self-probe.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   ReadMe—none0/10

   Evidence shows ReadMe offers a 'Versions' feature for customers' own API docs (readme-docs-17, 48, 69) and exposes its own ReadMe API for programmatic control (readme-docs-87), but there is no documentation of a versioning scheme or deprecation policy for ReadMe's own API/product that an AI-native consumer could rely on.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use cases.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”

   proof ↗⚑ flag

   Fern—none0/10

   Fern documents a 'Versions' feature that lets customers add version dropdowns to their own docs/API references, but there is no evidence of Fern's own APIs, CLI, or SDK generator having a documented deprecation policy or semantic versioning guarantees that an AI-native user could rely on. missing for 10: evidence of Fern's own API/CLI versioning scheme, changelog of breaking-change policy, explicit deprecation timeline documentation.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

   proof ↗⚑ flag

Agent access

1. ai-native userMy published docs site exposes its own MCP server that my users' agents can query for search and page content

   weight 3 · round to Fern
   ReadMe✓fullprobed8/10

   ReadMe documents a per-project MCP server that gives AI agents/coding assistants a live connection to the API spec and docs, with dedicated analytics tracking every tool call made by AI clients, matching the story of an exposed queryable MCP server. missing for 10: no independent/hands-on confirmation of query quality or third-party agent testing, and no detail on search-specific tool schemas beyond general spec/doc access.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [claimed-docs] “MCP”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

   Fern✓fullprobed9/10

   Fern documents that every documentation site with Ask Fern enabled gets an automatically generated, production-ready MCP server that connects AI clients (Claude Code, Cursor, Windsurf) to the docs as an external data source for search and page content, letting readers' agents get instant answers within their dev environment. This is corroborated by a dedicated docs page and probe confirming the feature is documented. Missing for 10: independent (non-vendor) hands-on verification that the MCP server works end-to-end in practice.

   • [claimed-docs] “Fern automatically generates and hosts a production-ready Model Context Protocol (MCP) server for every documentation site with Ask Fern ena…”
   • [claimed-docs] “The server connects AI clients like Claude Code, Cursor, and Windsurf to your documentation as an external data source, so your readers can …”
   • [probe] “official MCP server documented at https://buildwithfern.com/learn/docs/ai-features/mcp-server”

   proof ↗⚑ flag

Agent output

1. ai-native userMy published docs site automatically serves llms.txt (and a full-content variant) so agents can index it

   weight 3 · round to Fern
   ReadMe✓fullprobed8/10

   A direct probe confirms docs.readme.com serves a live llms.txt (HTTP 200) that also documents a full-content variant via appending .md to any page URL — matching the story's ask exactly. This is reinforced by ReadMe's own docs being organized under numerous /llms.txt paths (e.g. customizing-docs/llms.txt, workflows/llms.txt, ai/llms.txt) and a dedicated 'AI Discoverability' feature (readme-docs-10/31/65) that scores published docs against an 'Agent-Friendly Docs spec,' indicating llms.txt generation is a first-class, cross-project capability rather than a one-off. Missing for 10: explicit first-party confirmation that llms.txt is auto-generated for arbitrary customer-published hubs (not just docs.readme.com itself), and independent/community corroboration of this specific feature.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Inject your users' API keys, server variables, and more!”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”

   proof ↗⚑ flag

   Fern✓fullprobed9/10

   Fern documents automatic generation and maintenance of llms.txt (fern-docs-7/37), plus serving clean Markdown variants of pages via .md/.mdx suffix (fern-docs-6), and this is independently confirmed by a live probe returning HTTP 200 with correct llms.txt content and agent instructions (fern-probe-1). Analytics even track llms.txt usage by LLM provider (fern-docs-18). Missing for 10: independent third-party corroboration beyond the single probe, and the docs-md probe for a specific page returned 404 (fern-probe-2), suggesting some inconsistency in full-content variant availability across all pages.

   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   proof ↗⚑ flag

2. ai-native userEvery published page serves clean markdown at its URL (e.g. appending .md) so agents skip the HTML

   weight 3 · round to ReadMe
   ReadMe✓fullprobed7/10

   A direct probe of ReadMe's own docs site confirms the .md URL pattern works ('Append .md to any documentation page URL to...'), and ReadMe's AI-discoverability feature explicitly scores published customer pages against an 'Agent-Friendly Docs spec,' indicating this is a platform-wide capability, not just ReadMe's own site. Missing for 10: independent confirmation on a customer-hosted docs hub (not just docs.readme.com), third-party corroboration of the .md behavior across arbitrary published projects.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Your docs, now agent-ready”

   proof ↗⚑ flag

   Fern!disputedcontradicted5/10

   Fern's docs explicitly claim every documentation page serves clean Markdown by appending `.md` to the URL (fern-docs-6) and the llms.txt probe confirms this pattern is advertised (fern-probe-1), but a hands-on probe against an actual Fern-hosted page (buildwithfern.com/learn.md) returned HTTP 404 instead of Markdown (fern-probe-2), directly contradicting the universal claim. missing for 10: a successful probe on an actual content page returning clean Markdown, and clarification on which paths the `.md` suffix reliably works for.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   proof ↗⚑ flag

Assistant

1. ai-native userAn embedded AI assistant on my docs site answers reader questions with citations into my content

   weight 2 · round to Fern
   ReadMe~partialclaimed6/10

   ReadMe's 'Ask AI' feature is documented as giving readers instant answers from published documentation directly inside the hub, matching the core story of an embedded assistant answering questions from docs content, but the evidence never confirms it surfaces explicit citations/links into specific content, and there's no independent or hands-on verification of this behavior. missing for 10: explicit documentation or proof that Ask AI cites/links specific source pages, independent/community confirmation of citation quality.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Ask Fern is a first-party embedded AI assistant that indexes documentation and answers reader questions with citations linking to source pages, directly matching the story. Missing for 10: independent/hands-on third-party corroboration of citation accuracy and no community validation of the feature's real-world quality.

   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “You can now replace the default Ask Fern disclaimer (“Responses are generated using AI and may contain mistakes.”) with your own wording.”

   proof ↗⚑ flag

Writer agent

1. ai-native userA platform AI agent drafts, updates, and reviews my docs — from a prompt, a PR, or a schedule — and ships its work as change requests

   weight 2 · round to Fern
   ReadMe~partialclaimed7/10

   ReadMe documents an AI Agent that drafts/edits content from natural-language prompts (readme-docs-18, readme-docs-19), a GitHub AI Writer that watches PRs and proposes doc updates when code changes (readme-docs-8, readme-docs-53), and a Reviews/branches workflow where changes are held until approved (readme-docs-12, readme-docs-27, readme-docs-45, readme-docs-70) — functioning like change requests. However there is no evidence of a schedule-triggered agent run, and it's unclear whether GitHub AI Writer output surfaces as an actual GitHub pull request versus an internal ReadMe branch/review. Missing for 10: schedule-based trigger evidence, and explicit confirmation that agent output is submitted as a GitHub PR/change request rather than only an internal review branch.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Proposes documentation updates when pull requests change your codebase.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Fern Agent explicitly reads the docs repo, makes described changes, can be triggered from a prompt, Slack, reader feedback/analytics review, or a schedule, and opens pull requests as its output — directly matching the story's prompt/PR/schedule → change-request workflow. missing for 10: independent/hands-on verification of Fern Agent's PR quality and no evidence of it reviewing/updating docs triggered directly from an incoming PR (only prompt, feedback, and schedule triggers are documented).

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”

   proof ↗⚑ flag

Analytics

1. ai-native userMy docs analytics distinguish AI-agent traffic from human traffic so I can see who — or what — is actually reading

   weight 2 · round drawn
   ReadMe~partialclaimed6/10

   ReadMe's MCP Metrics page explicitly tracks calls made by AI agents/clients to a project's MCP server (calls, latency, failures, per-tool breakdown), which functions as dedicated AI-agent-traffic analytics distinct from human page-view metrics. However, this only covers MCP tool-call traffic, not a unified dashboard that tags/distinguishes AI crawlers or AI agent readers from human visitors across regular docs page views and API Metrics. Missing for 10: evidence of AI-vs-human classification within general docs pageview/API Metrics (not just MCP), and any UI showing side-by-side human vs agent traffic breakdown.

   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [claimed-docs] “MCP Metrics”
   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “API & Docs Metrics Charts”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern's llms.txt analytics tab explicitly reports 'Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)' distinguishing AI-agent consumption from generic web traffic, and this is tracked separately in the Web Analytics tab. However, this only covers llms.txt-based AI fetches, not a full breakdown distinguishing AI-agent vs human traffic across all documentation pages/formats (e.g., .md fetches, MCP server queries). Missing for 10: unified analytics dashboard showing AI-agent vs human split across all traffic sources (not just llms.txt), independent/hands-on verification of the analytics accuracy, and any breakdown of MCP-server query traffic as distinct from human pageviews.

   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   proof ↗⚑ flag

2. devrel leadI see page views, search terms, and reader feedback so I know which docs work and which fail

   weight 2 · round drawn
   ReadMe~partialclaimed5/10

   ReadMe documents Docs/API Metrics Charts and a Developer Metrics API that show 'how people use your docs and how developers use your API' (page views/usage), and Suggest in GitHub lets readers flag typos or share feedback, giving DevRel leads usage and feedback signals. However, there is no explicit documentation of search-term tracking/analytics, and no independent or hands-on evidence validating the depth or accuracy of these analytics dashboards. Missing for 10: explicit search-query/search-term analytics, quantified reader feedback/ratings dashboard, independent corroboration of the metrics feature's usefulness.

   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “API & Docs Metrics Charts”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “Anyone consuming your public documentation (developers, partners, etc.). They can use Suggest in GitHub to flag typos or share user feedback…”
   • [claimed-docs] “Suggesting changes from GitHub allows anyone reading your document”

   proof ↗⚑ flag

   Fern~partialclaimed5/10

   Fern's docs mention automations that can 'review your reader feedback, unanswered Ask Fern questions, search queries, or analytics' (fern-docs-8/25) and a Web Analytics/llms.txt usage tab tracking traffic by LLM provider (fern-docs-18/44), implying some page-view, search, and feedback signals exist. However there's no dedicated analytics dashboard walkthrough showing page views, search-term breakdowns, or reader feedback UI in one coherent place — missing for 10: a first-party analytics dashboard doc/screenshot showing page views, search term reports, and reader feedback aggregation, and independent/hands-on confirmation that these metrics are usable by a DevRel lead.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   proof ↗⚑ flag

Playground

1. developerReaders can try real API calls from an interactive playground embedded in the reference docs

   weight 2 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make real test calls and see actual responses without writing code, and independent community feedback corroborates ReadMe's strong Swagger/OpenAPI-based reference experience. Missing for 10: independent hands-on confirmation specifically of the try-it-out call execution (vs. general praise) and details on auth/key injection during live calls.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Fern—none0/10

   The evidence pack covers Fern's SDK generation, docs platform, AI/MCP features, CLI, and preview/versioning tools, but contains no mention of an interactive 'try it' playground for executing real API calls within the reference docs. Although this is a plausible feature for an API documentation platform, none of the docs, changelog entries, or community posts describe it.

   ⚑ flag

Spec driven

1. developerMy API reference pages are generated from an OpenAPI spec and stay in sync when the spec changes

   weight 3 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe explicitly supports transforming an OpenAPI spec into interactive API reference docs (readme-docs-23), documents accepted OpenAPI versions/file types (readme-docs-32), and offers Git-based workflows to manage API definitions in source control with docs updating from spec changes (readme-docs-44, readme-docs-68). Independent community feedback also notes ReadMe's strong Swagger/OpenAPI support relative to alternatives (readme-comm-7). Missing for 10: no first-party or independent evidence detailing automatic re-sync behavior when the spec file is updated post-publish (e.g., webhook/CI-triggered re-ingestion) or hands-on confirmation of staying in sync over time.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “Check which OpenAPI versions and file types ReadMe accepts, and what your definition gives your API Refe”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Fern✓fullclaimed7/10

   Fern's docs explicitly state it generates API Reference documentation from an OpenAPI specification (fern-docs-22, fern-docs-46), and the CLI supports validating and republishing docs from the spec (fern-docs-1, fern-docs-33), with generated GraphQL type pages reflecting schema changes (fern-docs-9), confirming spec-driven generation. missing for 10: explicit description of automatic re-sync/CI pipeline when the OpenAPI spec changes, and independent/hands-on confirmation that reference pages update without manual regeneration steps.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

Authoring

1. technical writerI author pages in Markdown/MDX with rich components — tabs, callouts, code groups, steps — without writing custom HTML

   weight 3 · round to Fern
   ReadMe~partialclaimed5/10

   ReadMe documents Markdown/MDX authoring with JSX syntax support (readme-docs-42, 81) and slash-command Mermaid diagrams (readme-docs-60), plus reusable Markdown blocks (readme-docs-24, 43), which supports building rich pages without raw HTML. However, the evidence never explicitly names built-in components like tabs, callouts, code groups, or step lists — only MDX/JSX generically and diagrams. Missing for 10: explicit documentation of tabs/callout/code-group/step components, and independent/hands-on confirmation of their availability.

   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “MDX”
   • [claimed-docs] “Add flowcharts, sequence diagrams, and other Mermaid diagrams to your docs with a slash command, written as text rather than images.”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”
   • [claimed-docs] “Create reusable blocks of Markdown content to use repeatedly across your pr”
   • [claimed-docs] “Write long-form tutorials, walkthroughs, and explanations that sit beside your API Reference, in Markdown with MDX support.”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern explicitly supports authoring pages in Markdown and generating API references from OpenAPI, which covers the base authoring workflow, but the evidence pack lacks direct documentation of specific rich components like tabs, callouts, code groups, and steps that a technical writer would use without custom HTML. missing for 10: explicit docs/examples of tabs, callouts, code-group, and step components in MDX, and independent/hands-on confirmation that these render without custom HTML.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload. Offline access is available after the first online run.”

   proof ↗⚑ flag

2. technical writerNon-technical teammates can edit docs in a visual web editor without touching git, and their changes flow into the same source of truth

   weight 2 · round drawn
   ReadMe✓fullclaimed8/10

   ReadMe provides a visual web editor (Guides/API Reference pages, inline AI editing) alongside bi-directional Git sync, so non-technical teammates can edit in the hub without touching git while changes sync to the same underlying source via branches/reviews. Suggest in GitHub and Reviews further support non-engineer contribution flows feeding into one source of truth. Missing for 10: independent/hands-on evidence (beyond vendor docs) confirming non-technical teammates specifically use the visual editor smoothly, and no explicit description of a WYSIWYG editor UI distinct from Markdown/MDX editing.

   • [claimed-docs] “Write in your preferred environment whether that's ReadMe or your local development setup.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Fern Editor is explicitly documented as a visual, no-code, no-Git editing interface for non-technical roles (content writers, PMs, marketers), and edits presumably sync back into the same docs source (git) that developers use. missing for 10: independent/hands-on confirmation that Editor changes actually commit into the same git source of truth without conflicts, and more detail on the sync/versioning workflow.

   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   proof ↗⚑ flag

Content reuse

1. technical writerReusable snippets and variables keep repeated content in sync across pages

   weight 1 · round to ReadMe
   ReadMe✓fullclaimed8/10

   ReadMe's Reusable Content feature lets admins create Markdown blocks reused across multiple pages, with edits automatically propagating to every instance ('Edit once, update everywhere'), directly matching the snippet-sync story; variables are less explicitly documented separately. missing for 10: dedicated documentation/example of a distinct 'variables' feature (vs. reusable Markdown blocks) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Edit once, update everywhere”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”

   proof ↗⚑ flag

   Fern—none0/10

   No evidence in the pack mentions reusable content snippets, includes, or variable substitution for keeping repeated content in sync across pages; Fern's documented features cover Markdown authoring, versions, OpenAPI-based reference generation, and AI features but nothing about reusable snippets/variables.

   ⚑ flag

Quality

1. technical writerAutomated checks lint my content against a style guide and flag issues before they publish

   weight 2 · round to ReadMe
   ReadMe✓fullclaimed7/10

   ReadMe's Linter lets writers define natural-language style rules (e.g., 'Use active voice') that check every page, and Docs Audit runs those rules across the whole site to flag outdated content, broken links, and style inconsistencies before publishing; Reviews also let content be checked with the AI Linter before going live. missing for 10: independent/hands-on evidence of linting accuracy, no detail on pre-publish blocking/gating enforcement, and no third-party corroboration of the feature working in practice.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “An AI-powered tool for checking page content against your own style guide.”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”

   proof ↗⚑ flag

   Fern—none0/10

   No evidence of any style-guide linting, vale/textlint-style content checks, or pre-publish content quality gates in Fern's docs or CLI; validation features mentioned (fern-docs-1) refer to API definition validation, not prose/style linting. Missing for 10: any mention of prose style-guide rules, linting integration, or automated content-quality checks before publish.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   ReadMe~partialprobed4/10

   ReadMe offers a Docs Audit that runs Linter rules across every page in one pass (readme-docs-7, readme-docs-25, readme-docs-52) and an rdme CLI plus ReadMe API for programmatic control (readme-docs-87, readme-probe-3), which enable some bulk-style operations across many docs/pages. However there's no direct evidence of bulk operations across arbitrary 'items' (e.g., batch endpoint edits, bulk publish/delete, bulk API reference updates) beyond the audit/linter and CLI/API scripting potential. missing for 10: explicit bulk edit/publish/delete UI or API examples, documented batch size/limits, independent hands-on confirmation of bulk workflows succeeding at scale.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Fern~partialclaimed4/10

   Fern's CLI is scriptable and machine-readable (every command outputs JSON so it can be piped/chained, fern-docs-34) and generates SDKs in 9 languages from a single spec in one operation (fern-docs-32), and the scheduled Fern Agent can review large sets of reader feedback, unanswered questions, and search queries in a single automated pass (fern-docs-8/25). However, there is no explicit documentation of a bulk/batch API or CLI mode for operating across many discrete items (e.g., mass-editing pages, bulk API endpoint updates) — missing for 10: explicit bulk-edit/batch API commands, evidence of scale limits, and independent confirmation that agents can reliably chain many operations at once.

   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Fern
   ReadMe—none0/10

   ReadMe offers linting rules, GitHub sync, and AI writer proposals, but these are triggered by manual runs or PR events for documentation maintenance, not a general-purpose 'define rules that trigger arbitrary actions on events' automation engine for AI-native users. No evidence of a rules/automation/webhook engine letting users define custom event-triggered actions. missing for 10: an event-trigger/automation rules engine, webhook or conditional action framework, evidence of user-defined triggers beyond docs linting/sync.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”

   proof ↗⚑ flag

   Fern~partialclaimed5/10

   Fern documents 'Fern Agent' automations that can run on a schedule or be triggered by Slack discussions to review reader feedback/questions and open PRs when a described change is needed, which is a form of event-triggered automation (fern-docs-8, fern-docs-25, fern-docs-45). However, this is limited to Fern's own docs-maintenance domain (feedback, search queries, Slack) rather than a general rule engine for arbitrary events/actions. Missing for 10: a configurable rules/trigger system spanning arbitrary event sources (webhooks, API calls, custom conditions) and arbitrary actions beyond PR creation, plus independent confirmation of reliability.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   ReadMe~partialclaimed5/10

   ReadMe supports versioning of docs content (readme-docs-17), review workflows with AI Linter/teammate approval (readme-docs-12, readme-docs-27), and bi-directional git sync (readme-docs-26) which implicitly enables rollback via git history for AI-driven changes like the GitHub AI Writer's proposed updates (readme-docs-8). However, none of this is framed specifically around 'automations' as a distinct object with version/review/rollback controls — it's inferred from general docs versioning and git integration rather than a dedicated automation-management feature. Missing for 10: an explicit rollback mechanism/UI for AI Agent or automation actions, direct evidence connecting review/versions to 'automations' specifically, and independent corroboration of this workflow in practice.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”

   proof ↗⚑ flag

   Fern~partialclaimed5/10

   Fern Agent automations operate by reading the docs site's source repo and opening a pull request when changes are needed, which inherently gives git-based versioning and human review before merge (fern-docs-8/25/29). However, there's no dedicated automation-specific version history, audit log, or explicit one-click rollback/undo feature documented beyond relying on standard git revert via PRs. Missing for 10: explicit rollback/undo UI for automations, automation run history/audit trail, and any review workflow beyond generic PR review.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   proof ↗⚑ flag

Review

1. technical writerTeammates propose changes that go through review — comments, approvals, and a merge step — before they publish

   weight 2 · round to ReadMe
   ReadMe~partialclaimed6/10

   ReadMe's Reviews feature explicitly supports pre-publish approval workflows — teammates can check changes for issues or get approval before they go live, and the branch-based model (Branch menu) implies a merge-into-main step. However, the evidence never explicitly mentions inline comments/discussion threads, only 'approval' and 'AI Linter' checks, and there's no dedicated documentation of the merge action itself. Missing for 10: explicit comment/discussion functionality within reviews, and clear documentation of the merge step that finalizes publishing.

   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”

   proof ↗⚑ flag

   Fern~partialclaimed4/10

   Fern's docs are stored as code, and the Fern Agent automation explicitly 'opens a pull request when the prompt asks for a change,' implying a git-based review/merge gate before publishing (fern-docs-8/25). However, there's no direct documentation of an in-product commenting or approval workflow, and Fern Editor is described as letting non-technical writers publish updates 'without code, markdown, or Git' (fern-docs-2), which bypasses any PR-based review step. Missing for 10: explicit description of inline comments/approvals, confirmation that Editor changes also go through a review/merge gate, and independent evidence of a working review pipeline.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   proof ↗⚑ flag

Theming

1. devrel leadI customize themes, fonts, and layout — down to custom CSS/JS or my own components — so the docs match my brand

   weight 2 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly cover theme presets with brand color/typography tuning, custom CSS (variables or raw rules), custom JavaScript and include tags, custom domain/SSL, and MDX support for custom components, directly matching the DevRel branding customization story. A community testimonial (Heap Analytics) also corroborates the visual customization experience in practice. Missing for 10: independent/hands-on verification of deep custom-JS/component work beyond vendor docs, and no evidence of a fully custom component framework beyond MDX.

   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules.”
   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules. The most flexible is to use CSS variables.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Apply your own CSS, JavaScript, and include tags to your hub, with the plan requirements and toggles for each.”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “Use Font Awesome 7 Regular and Duotone icons in your docs, including how to hide a decorative icon from screen readers.”
   • [community] “Heap Analytics moved docs to ReadMe.io: 'The ReadMe team is really responsive and helpful, the documentation is beautiful and the interface …”

   proof ↗⚑ flag

   Fern—none0/10

   The evidence pack contains no mention of theme, font, layout, custom CSS/JS, or custom component capabilities for Fern docs — only custom domains, versions, preview, and AI features are documented. As a documentation platform, this axis clearly applies, but there is no evidence Fern supports deep visual/brand customization beyond domain routing.

   ⚑ flag

Git workflow

1. developerMy docs live in my own git repository — branches, pull requests, and merges drive what gets published

   weight 3 · round to ReadMe
   ReadMe✓fullclaimed8/10

   ReadMe supports bi-directional GitHub/GitLab/Bitbucket sync, git-based workflows with Markdown/OpenAPI in-repo, pull requests as the review step, and branch-based review before publishing (readme-docs-26, readme-docs-44, readme-docs-45, readme-docs-46, readme-docs-67, readme-docs-70, readme-docs-68). This directly matches docs-as-code with branches/PRs/merges driving publishing. missing for 10: independent/hands-on confirmation of the git-sync workflow in practice (community evidence is thin/tangential) and more detail on merge conflict handling.

   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Sync with GitHub”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”

   proof ↗⚑ flag

   Fern~partialclaimed6/10

   Fern's CLI-driven workflow (init, validate, preview, publish) and Fern Agent explicitly 'reads your docs site's source repository and makes the changes you describe,' plus automations that 'open a pull request when the prompt asks for a change,' point to a git-backed, PR-driven docs pipeline. However, the evidence never explicitly documents a CI/CD-style trigger where merging a branch/PR automatically republishes docs, and Fern Editor is marketed as a non-git alternative for content editors, which cuts against a pure docs-as-code narrative. Missing for 10: explicit documentation of branch-based preview/staging tied to PRs, and a described merge-to-publish pipeline (e.g., GitHub Action or webhook) rather than manual CLI publish or Agent-initiated PRs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   proof ↗⚑ flag

2. developerEvery docs pull request gets a shareable preview deployment before it merges

   weight 2 · round to Fern
   ReadMe—none0/10

   No evidence describes per-PR shareable preview deployments of docs; ReadMe's docs-as-code features cover bi-directional sync, Reviews (AI Linter/teammate approval), and branch-based exports, but nothing indicates an automatic preview URL generated for each pull request before merge.

   ⚑ flag

   Fern~partialclaimed4/10

   Fern documents a local preview server with hot reload (fern-docs-14/26/39) but there is no evidence of automatic, shareable preview deployment URLs generated per pull request (e.g., a bot comment with a live link tied to CI/CD on PR open). This is a local-only workflow rather than a hosted PR-preview link. missing for 10: PR-triggered hosted preview deployment, shareable preview URL per PR, CI/CD integration or bot comment posting preview links, independent confirmation of PR-preview behavior.

   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload. Offline access is available after the first online run.”
   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload.”
   • [claimed-docs] “Fern offers two ways to preview documentation changes”

   proof ↗⚑ flag

Quality gates

1. developerCI validation catches broken links and invalid configuration before the site publishes

   weight 2 · round drawn
   ReadMe—none0/10

   ReadMe's docs mention Docs Audit/Linter for style/broken-link checks and Reviews as a manual approval gate, and bi-directional sync with Git, but there is no evidence of a CI pipeline check (e.g., rdme CLI command or GitHub Action) that validates links/config and blocks a publish/merge automatically before the site goes live. missing for 10: evidence of an automated CI/CD integration (CLI command or GitHub Action) that runs link/config validation and fails the build pre-publish, and any confirmation that Docs Audit/Linter can be invoked as a CI gate rather than a manual dashboard action.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Fern—none0/10

   The CLI reference mentions validating API definitions, but there is no evidence of a CI/CD integration that catches broken links or invalid configuration before publishing (e.g., no GitHub Action, pre-publish link checker, or CI validation step documented).

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to ReadMe
   ReadMe~partialprobed6/10

   ReadMe documents a full ReadMe API for programmatic control (readme-docs-87) plus an official CLI (rdme, readme-probe-3) and bi-directional GitHub/GitLab sync (readme-docs-26/46), suggesting most content, versioning, and docs management actions can be done via API/CLI/Git instead of the UI. However, the evidence doesn't confirm parity for every UI feature (e.g., Reviews approval workflows, Linter/Docs Audit runs, custom CSS/domain setup, Analytics/metrics views) being fully scriptable via the API, and no independent confirmation of full UI/API parity exists. missing for 10: explicit API/CLI equivalents for Reviews, Linter/Docs Audit, Analytics dashboards, and custom domain/CSS configuration, plus independent verification of full parity.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”

   proof ↗⚑ flag

   Fern~partialprobed5/10

   Fern's CLI covers core workflows also available in the UI — initializing, validating, previewing, and publishing docs/SDKs (fern-docs-1) — and every CLI command outputs JSON for agent piping (fern-docs-34), suggesting good API/CLI parity for build workflows. However, several UI-only capabilities (Fern Editor's no-code content editing for non-technical writers, Ask Fern configuration, analytics dashboards, version/domain management) have no documented API/CLI equivalent in the evidence. Missing for 10: documented API/CLI parity for Fern Editor no-code edits, analytics access, and admin/config actions performed via the web UI.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   ReadMe~partialclaimed5/10

   ReadMe supports exporting docs files or PDF from the Branch menu, giving some data portability, but this is limited to documentation content and PDF/file export, not a full open-format export of all underlying data (API metrics, analytics, custom pages, versions, reusable content blocks) in machine-readable open formats like JSON/Markdown source. missing for 10: evidence of exporting all account/project data (metrics, settings, versions) in open formats, confirmation of underlying file format (e.g., raw Markdown vs proprietary), and independent/hands-on confirmation of a full data export and migration path away from ReadMe.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Fern~partialcommunity5/10

   Fern's content model is built on open formats (Markdown pages, OpenAPI specs for API references, YAML docs.yml config) and the CLI validates/previews/publishes from your own source repo, implying content isn't locked in a proprietary format (fern-docs-22, fern-docs-33, fern-docs-46). However, there is no explicit 'export all your data' feature, no documented bulk-export/backup tool, and the optional 'Fern Definition' language is noted by a community reviewer as an added proprietary layer that doesn't map 1:1 to OpenAPI (fern-comm-2). Missing for 10: an explicit data-export/backup capability, confirmation that Fern Definition and Ask Fern indices/analytics can be exported, and independent evidence of migrating off Fern without friction.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Fern
   ReadMe—none0/10

   ReadMe is a closed, proprietary SaaS documentation platform; there is no evidence of its core product source being released under an open license (only a CLI tool 'rdme' is open-source, not the product itself). No evidence supports an open-license source availability for the platform.

   ⚑ flag

   Fern✓fullcommunity7/10

   Fern's source is publicly hosted on GitHub (fern-api/fern), and independent community commentary explicitly confirms it is open-source (though commercially licensed/not free), satisfying the ability to read the source. Missing for 10: explicit license file/name (e.g., MIT/Apache) confirmation and first-party docs stating the license terms.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Fern
   ReadMe—none0/10

   ReadMe is a SaaS-only hosted documentation platform; there is no evidence of a self-hostable core product, Docker image, or on-prem deployment option. Community evidence even shows a user switching to open-source Docusaurus specifically to avoid ReadMe's hosted costs, and a request for an open-source-friendly plan went unmet, further indicating no self-hosting path exists.

   • [community] “Wish there was a plan for opensource projects, which allowed me to use customized landing page etc.”
   • [community] “Blog post titled 'From Readme to Docusaurus: How an Intern Saved Us $1.2k', describing a switch away from ReadMe.com to the open-source Docu…”

   proof ↗⚑ flag

   Fern~partialcommunity5/10

   Fern's docs confirm a self-hosted container option for serving documentation (env var resolution 'on each request' in self-hosted deployments) and community commentary notes Fern is open-source, supporting self-hosting of the core product. However, there is no first-party deployment guide, infrastructure requirements, licensing terms, or independent hands-on confirmation of running the full SDK-generation/docs platform outside Fern's hosted service. Missing for 10: explicit self-hosting setup documentation, infra/licensing details, and independent verification of a full self-hosted deployment.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   ReadMe—none0/10

   No evidence in the pack addresses data residency, regional storage selection, or data location controls for ReadMe; the docs cover editing, MCP, analytics, and customization but never data-residency options.

   ⚑ flag

   Fern—none0/10

   Fern is a docs/SDK platform for API providers; data residency/region choice is a plausible axis for a hosted SaaS documentation platform, but no evidence pack item mentions region selection, data residency, or storage location options. Self-hosting is mentioned but not framed as a residency control.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   ReadMe—none0/10

   The evidence pack covers documentation authoring, MCP server setup, AI writing tools, and content export/versioning, but nothing addresses data retention policies or user-controlled deletion of stored data (e.g., MCP call logs, Ask AI query history, or account data). Analytics features like MCP Metrics explicitly record every AI tool call, but no docs describe retention windows or deletion controls for that data.

   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [claimed-docs] “Export your docs using our built-in features, tooling, and our API.”

   proof ↗⚑ flag

   Fern—none0/10

   Fern is a docs/SDK generation platform; no evidence pack item discusses data retention policies, deletion controls, or user data lifecycle management for content, analytics, or Ask Fern query logs. This axis plausibly applies (any SaaS handling user/reader data could document retention/deletion controls) but no such documentation is present.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   ReadMe—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out settings for ReadMe; nothing describes data collection controls or privacy toggles. Missing for 10: any documentation of telemetry practices, an opt-out mechanism, or privacy settings related to usage tracking.

   ⚑ flag

   Fern—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Fern's CLI, docs platform, or SDKs; this is a fair privacy-posture question for a dev-tool/platform but no documentation or community source confirms or denies telemetry opt-out.

   ⚑ flag

Access control

1. devrel leadI gate some or all docs behind authentication — password, JWT, or SSO — for customers-only content

   weight 1 · round to Fern
   ReadMe—none0/10

   Evidence covers SSO only for internal Teammates sign-in (readme-docs-84) and admin permission control (readme-docs-63), but nothing describes gating published customer-facing docs behind password, JWT, or SSO authentication for readers/customers. missing for 10: reader-facing password protection, JWT-based authenticated docs, SSO gating for external customers viewing docs.

   • [claimed-docs] “Connect your identity provider and let Teammates sign in with SSO”
   • [claimed-docs] “Control who can access admin controls and edit content.”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Fern's pricing page explicitly lists password-protected docs and visitor authentication with JWT/SSO as features, directly matching the story's requirement for gating docs behind authentication for customers-only content. Missing for 10: no independent/hands-on corroboration or detailed docs page describing configuration steps for these auth methods beyond the pricing page mention.

   • [claimed-docs] “Password-protected docs”
   • [claimed-docs] “Visitor authentication (JWT, SSO)”

   proof ↗⚑ flag

Domains

1. devrel leadI serve docs on my own custom domain or as a /docs subpath of my main site

   weight 2 · round drawn
   ReadMe✓fullclaimed8/10

   ReadMe's docs explicitly cover custom domain setup with CNAME, apex vs subdomain, and SSL certificates, framed as making docs 'polished and professional' on a company domain, which directly matches the custom-domain part of the story; the /docs subpath scenario is implicitly covered via apex/subdomain configuration options. Missing for 10: explicit first-party or independent confirmation of serving docs specifically as a path-based /docs subpath (vs subdomain) on the main domain.

   • [claimed-docs] “Hosting docs on your company domain is an important part of making your docs polished and professional. You can setup a custom domain from *…”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Custom Domain & SSL”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Fern's docs explicitly document configuring custom domains as a subdomain (docs.mydomain.com), subpath (mydomain.com/docs), or root domain (mydomain.com), directly matching the story's requirements. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on DNS/setup complexity or edge cases.

   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain: `docs.mydomain.com`, Subpath: `mydomain.com/docs`, Root domain: `mydo…”
   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain... Subpath... Root domain”
   • [claimed-docs] “You can configure any of the following custom domain types”

   proof ↗⚑ flag

Portability

1. developerExport my entire docs site as a static bundle and host it anywhere, so my content is never locked in

   weight 2 · round drawn
   ReadMe~partialclaimed3/10

   ReadMe docs mention exporting files or a PDF from the Branch menu, which shows some content-export capability, but there is no evidence of exporting the entire docs site as a deployable static bundle (with API reference, navigation, styling, etc.) that can be self-hosted elsewhere — the product is fundamentally a hosted SaaS platform. missing for 10: full static-site export/bundle, documentation of self-hosting elsewhere, independent confirmation that exported files constitute a complete replica of the hosted site.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Fern~partialclaimed3/10

   Evidence only mentions a 'self-hosted container' that can serve pages with per-request environment variable resolution, implying some self-hosting flexibility, but there is no documentation of exporting the docs site as a plain static HTML/asset bundle deployable to arbitrary static hosts (e.g., S3, Netlify) without Fern's runtime. Missing for 10: an explicit static-export/build-to-static-files feature, confirmation that the exported bundle has no dependency on Fern's hosted infrastructure or container, and independent verification of successful self-hosting outside Fern's ecosystem.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”

   proof ↗⚑ flag

Search

1. developerReaders get fast, typo-tolerant, relevance-ranked search over the whole docs site out of the box

   weight 3 · round to Fern
   ReadMe—none0/10

   The evidence pack describes Ask AI (AI-generated answers from docs) and MCP/agent discoverability features, but contains no mention of a traditional full-text search index, typo-tolerance, or relevance ranking for the docs site itself. Search-discovery via a classic search bar is a plausible axis for a docs platform, but no evidence confirms it delivers fast, typo-tolerant, relevance-ranked search out of the box.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”
   • [claimed-docs] “Ask AI gives your users instant answers from your published documentat”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”

   proof ↗⚑ flag

   Fern~partialclaimed4/10

   Fern's docs mention a 'search queries' analytics feature and a `search-metadata` frontmatter for customizing search grouping/filtering, implying a built-in site search exists, and Ask Fern provides an AI Q&A alternative with citations. However, there is no explicit claim about typo-tolerance, relevance ranking, or full-site coverage of the search feature itself. Missing for 10: explicit documentation of the underlying search engine's typo-tolerance, ranking algorithm, and independent/hands-on verification of search quality.

   • [claimed-docs] “You can now attach your own key-value metadata to a page with the `search-metadata` frontmatter object... so a custom search integration can…”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   proof ↗⚑ flag

Localization

1. technical writerI publish my docs in multiple languages with translated navigation and content

   weight 1 · round drawn
   ReadMe—none0/10

   No evidence of multi-language documentation publishing, translated navigation, or i18n/localization features; 'Pick a language' (readme-docs-2) refers to code-sample language selection, not content localization. Versioning docs (readme-docs-17, readme-docs-48) address content versions, not language translation.

   ⚑ flag

   Fern—none0/10

   The evidence covers versioning (dropdown for multiple releases), custom domains, previews, and SDK/CLI generation, but there is no mention anywhere of localization, translated navigation, multi-language content, or i18n support for docs sites. missing for 10: any mention of localization/i18n, translated navigation menus, language switcher, or multi-locale content management.

   ⚑ flag

Versioning

1. developerI publish versioned documentation per product or API version, and readers switch versions from the site

   weight 3 · round to Fern
   ReadMe~partialclaimed5/10

   ReadMe's docs explicitly state that maintaining multiple versions of documentation is a supported, important feature (readme-docs-17), confirming per-product/API version publishing capability. However, the evidence pack contains no detail on the actual version-switcher UI or reader-facing mechanism for switching versions from the site, nor any independent/community confirmation of this workflow. Missing for 10: documentation or screenshots of the reader-facing version switcher, confirmation of how versions map to distinct URLs/hubs, and independent corroboration that readers can toggle versions seamlessly.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”

   proof ↗⚑ flag

   Fern✓fullclaimed8/10

   Fern explicitly documents a Versions feature that adds a dropdown selector letting readers switch between multiple releases of the same docs/API content, with each version able to have its own pages, tabs, and API references. This directly matches the story's core need for per-product/version documentation with reader-facing version switching. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on version-specific URL structure or SEO handling.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

   proof ↗⚑ flag