GitBook vs Fern

Agent access

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

   weight 2 · round to Fern
   GitBook✓fullprobed8/10

   GitBook publishes an official llms.txt (confirmed live via probe) plus llms-full.txt, a dedicated 'LLM-ready docs' guide, and even an 'agent-score' tool to check how well AI agents can parse docs, alongside MCP servers for published docs enabling agent access. This directly satisfies pointing an agent at llms.txt/agent-oriented docs for any GitBook-hosted site. Missing for 10: independent third-party validation that agents actually consume llms.txt effectively in practice, and docs.md endpoint returned 404 suggesting inconsistent markdown-mirroring coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “See how easily AI agents can reach, parse, and use your documentation.”
   • [claimed-docs] “MCP servers for published docs”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   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
   GitBook~partialcommunity5/10

   GitBook offers a REST API (gitbook-docs-36), a CLI that can list orgs/inspect content/build integrations from the shell (gitbook-docs-28, gitbook-docs-34), and Git Sync for docs-as-code workflows (gitbook-docs-4, gitbook-docs-27) — all of which support scripted/automated use outside the UI. However, there is no explicit documentation of headless/CI-specific usage (e.g., CI pipeline examples, non-interactive auth flows, exit codes) and the CLI's OSS/self-hosted precursor was explicitly deprecated by the vendor per community evidence (gitbook-comm-17), raising doubt about current automation tooling maturity. Missing for 10: explicit CI/headless run documentation, examples of scripted pipelines, and confirmation the current CLI is actively maintained for automation use cases.

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   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
   GitBook✓fullprobed8/10

   GitBook documents an official MCP server ('GitBook MCP server is here. Connect your AI agent') that lets MCP clients like Claude Code, Codex, and Cursor create/configure sites, open change requests, draft content, edit pages, and restructure docs — a clear agent-connectivity capability, not just consuming other MCP servers. Missing for 10: independent/hands-on verification of the MCP server's reliability and no third-party corroboration beyond vendor docs.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   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
   GitBook✓fullclaimed7/10

   GitBook publishes an official CLI (gitbook-docs-28) documented to let users list organizations, inspect spaces/pages, ask questions against docs, and build/publish integrations 'without leaving the shell' (gitbook-docs-34), directly matching an AI-native CLI story alongside its MCP server for agent tooling. missing for 10: independent/hands-on verification of the CLI's current functionality and any AI-native workflow examples beyond first-party docs (the only community CLI comment found refers to the legacy, unrelated open-source book-building CLI, not this one).

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”

   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 GitBook
   GitBook✓fullprobed8/10

   GitBook documents a RESTful public API supporting standard HTTP methods (GET/POST/PATCH/DELETE) with a full API reference, plus a CLI and an MCP server that let agents create/configure sites, open change requests, draft and edit content programmatically — directly enabling AI-native users to drive the product outside the UI. Missing for 10: a discoverable machine-readable OpenAPI spec (probe-3 shows all common OpenAPI paths 404) and independent/hands-on corroboration of the API's robustness beyond vendor docs.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   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
   GitBook—none0/10

   GitBook exposes a general REST API and an MCP server for AI agents, but no evidence describes scoped or least-privilege API credentials/tokens, granular permission scopes, or agent-specific access controls for its API keys — only generic 'authenticated access' for site audiences is mentioned, which is unrelated to credential scoping.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Authenticated access”

   proof ↗⚑ 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
   GitBook—none0/10

   Evidence shows GitBook has a REST API (gitbook-docs-36), a CLI (gitbook-docs-28/34), and an MCP server (gitbook-docs-14/15/33), but there is no mention anywhere of official client SDKs (e.g., JS/Python/Go libraries) for developers to build against. Missing for 10: any official SDK documentation, package registry listings, or language-specific client libraries.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   GitBook—none0/10

   No evidence of webhook subscription capability appears anywhere in the pack; GitBook's API reference mentions only REST methods (GET/POST/PATCH/DELETE) with no mention of webhooks or event subscriptions, and probes for OpenAPI specs failed.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   Fern—none0/10

   No evidence in the pack shows Fern itself offers a webhook subscription mechanism for platform events (e.g., doc publish, build status, reader activity); the evidence only covers SDKs, CLI, docs, MCP servers, and Ask Fern.

   ⚑ flag

Agentic features

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

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook documents an 'AI insights' analytics feature that shows what visitors ask and how AI Assistant answers using site content, plus an AI documentation agent that identifies outdated content and drafts improvements — both are AI-generated insights/suggestions surfaced inside the product. Evidence is vendor-documented only, without independent hands-on corroboration of accuracy or usefulness. missing for 10: independent/community validation of AI insights quality, more detail on suggestion actionability beyond docs pages.

   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”

   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
   GitBook~partialclaimed5/10

   GitBook advertises a background 'GitBook Agent' that autonomously flags outdated content, drafts fixes, and auto-translates docs without user intervention (gitbook-docs-1, gitbook-docs-38, gitbook-docs-41), which is a real form of autonomous background automation. However, there's no evidence of a general-purpose automation/workflow builder (triggers, schedules, custom rules) that AI-native users could configure themselves. Missing for 10: a documented automation/rules engine or scheduler users can configure, independent confirmation these agent behaviors run unattended reliably, and broader automation scope beyond content-freshness/translation.

   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Auto translations make it easy to keep your documentation up-to-date in multiple languages, with minimal manual effort.”
   • [claimed-docs] “Review change requests with GitBook Agent”

   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 drawn
   GitBook✓fullclaimed7/10

   GitBook ships a built-in 'GitBook AI Assistant' that answers reader questions from docs content, and a separate 'GitBook Agent' that can identify outdated content, draft improvements, and review change requests — both are native, first-party AI delegation features distinct from external MCP integrations. Missing for 10: independent/hands-on user reports validating real task delegation and reliability of the assistant/agent beyond vendor docs.

   • [claimed-docs] “AI Assistant”
   • [claimed-docs] “I'm here to help you with the docs.”
   • [claimed-docs] “Add it to your product, website, or docs to give every user accurate, contextual answers.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”

   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 to GitBook
   GitBook✓fullprobed8/10

   GitBook ships an official MCP server that lets AI agents (Claude Code, Codex, Cursor, etc.) create/configure sites, open change requests, draft and edit content, and restructure docs via natural-language instructions, plus a CLI and AI Assistant that can answer questions and act against docs conversationally. This directly matches 'operate via natural-language commands' for an AI-native user. Missing for 10: independent/hands-on verification of MCP command reliability and breadth (all evidence is vendor docs, no community testing of the agent workflow).

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “Agent skills”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   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 GitBook
   GitBook✓fullclaimed7/10

   GitBook explicitly supports OpenAPI specs with interactive playgrounds that 'let your users test endpoints right on the page with interactive blocks,' plus a documented API reference, directly enabling runnable API docs. Missing for 10: independent/hands-on verification of the interactive playground working in practice, and more detail on the range of runnable example types beyond OpenAPI.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”

   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
   GitBook—none0/10

   Probes explicitly show all candidate OpenAPI/spec endpoints (openapi.json, swagger.json, etc.) return 404, and there is no documentation link to download a machine-readable spec of GitBook's own API — the 'Add an OpenAPI specification' docs describe a feature for customers embedding specs in their own docs, not GitBook's own API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Add an OpenAPI specification”

   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
   GitBook—none0/10

   The evidence shows GitBook has a REST API (gitbook-docs-36) and features for versioning documentation content (gitbook-docs-24), but there is no mention of a versioning scheme or deprecation policy for GitBook's own platform API, and probes for a discoverable OpenAPI spec all returned 404s (gitbook-probe-3), giving no indication of documented API stability guarantees.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Version control”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   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
   GitBook✓fullprobed7/10

   GitBook explicitly documents 'MCP servers for published docs' and a general MCP server that AI agents can connect to for querying docs, directly matching the story of published sites exposing an MCP endpoint for search/page content. Missing for 10: no independent/hands-on verification of the published-docs MCP server's search/content-query behavior, and no detail on the exact query capabilities exposed.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   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
   GitBook✓fullprobed8/10

   GitBook has a dedicated 'LLM-ready docs' feature page and references an llms-full.txt variant in docs, and a live probe confirms https://gitbook.com/llms.txt actually returns 200 with real content, corroborating the vendor claim. Missing for 10: direct probe confirmation of the llms-full.txt variant and evidence it's automatically enabled across arbitrary customer-published sites, not just gitbook.com itself.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”

   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 GitBook
   GitBook✓fullprobed7/10

   GitBook explicitly documents an 'LLM-ready docs' feature and the evidence pack itself cites numerous live GitBook docs pages at .md-suffixed URLs (e.g. gitbook-mcp.md, ai-insights.md, customization.md), strongly implying published pages do serve raw markdown when .md is appended; llms.txt is also confirmed live via probe. The one 404 probe (gitbook.com/docs.md) tested a non-page root path rather than an actual content page, so it doesn't concretely contradict the pattern seen elsewhere. Missing for 10: a controlled hands-on test appending .md to an actual customer-published site page (not gitbook.com's own docs) and independent third-party confirmation beyond the vendor's own citations.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   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 drawn
   GitBook✓fullclaimed8/10

   GitBook documents a first-party AI Assistant embeddable on published docs sites that answers reader questions grounded in the site's own content, plus AI insights analytics showing what visitors ask and how the assistant responds using that content. missing for 10: explicit confirmation/example that assistant answers include inline citations/links to source pages, and independent (non-vendor) hands-on validation of citation accuracy.

   • [claimed-docs] “AI Assistant”
   • [claimed-docs] “I'm here to help you with the docs.”
   • [claimed-docs] “Add it to your product, website, or docs to give every user accurate, contextual answers.”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “AI search”

   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
   GitBook✓fullclaimed7/10

   GitBook Agent is documented as identifying missing/outdated content, drafting improvements, and shipping changes via change requests, with a dedicated review workflow (gitbook-agent/review-change-requests-with-gitbook-agent) and MCP/CLI integration letting agents open change requests, draft content, and restructure docs from prompts or Git workflows. However, evidence for explicit PR-triggered or schedule-triggered automation is thin/implied rather than concretely documented, and there's no independent/hands-on corroboration of the agent's output quality. Missing for 10: explicit scheduled-trigger documentation, concrete PR-triggered workflow details, and independent verification of the agent's drafting/review quality.

   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “Agent skills”

   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 to Fern
   GitBook—none0/10

   GitBook's analytics docs mention general 'Analytics & user feedback' and 'AI insights' (which tracks questions asked to the AI Assistant) and an 'Agent Score' for AI accessibility, but none of these describe segmenting or labeling raw site traffic as AI-agent vs. human visitors. No evidence shows a dashboard breakdown of bot/agent traffic vs. human pageviews.

   • [claimed-docs] “Analytics & user feedback”
   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “See how easily AI agents can reach, parse, and use your documentation.”

   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
   GitBook~partialcommunity5/10

   GitBook's pricing/docs pages claim 'Analytics & user feedback' and 'AI insights' that show 'what your visitors are asking and how effectively GitBook Assistant responds,' plus a search feature; one HN reviewer separately praised GitBook's search as 'fast & accurate.' However, page-view analytics accuracy is called into question by a hands-on community report that 'traffic stats are not realistic (counts page loads, off by 2-3x vs Google Analytics), country demographics clearly wrong,' and no evidence documents an explicit reader-feedback widget/mechanism beyond the pricing bullet. Missing for 10: dedicated documentation of a feedback-collection UI, independent corroboration of analytics accuracy, and confirmation the cited stats complaint doesn't still apply to the current platform.

   • [claimed-docs] “Analytics & user feedback”
   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “Searching internal content”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   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 GitBook
   GitBook✓fullclaimed7/10

   GitBook's docs explicitly advertise 'Interactive API playgrounds' as a pricing feature and describe OpenAPI integration that lets users 'test endpoints right on the page with interactive blocks,' directly matching the story. Missing for 10: independent/hands-on third-party confirmation of the playground actually executing live API calls, and more detail on auth/response handling within the playground.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”

   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 Fern
   GitBook~partialclaimed6/10

   GitBook explicitly supports adding an OpenAPI specification to generate API reference pages with interactive playgrounds (gitbook-docs-23, gitbook-docs-5, gitbook-docs-35), and it has Git-sync/version-control features that could keep specs updated (gitbook-docs-27, gitbook-docs-24). However, no evidence explicitly confirms automatic re-sync/regeneration of reference pages when the underlying OpenAPI spec file changes (e.g. webhook-triggered refresh), only general 'flags outdated content' branding (gitbook-docs-1) without specifics tied to OpenAPI. Missing for 10: explicit documentation of automatic spec-change detection/refresh workflow, and independent/hands-on confirmation that the sync actually works reliably.

   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”

   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 GitBook
   GitBook~partialcommunity7/10

   GitBook's docs confirm a block-based visual editor with custom blocks and Markdown/MDX authoring (gitbook-docs-3, gitbook-docs-46), plus a concrete example of a rich block (the 'updates' changelog block with auto RSS) showing the block system is real (gitbook-docs-44). Community reviews independently praise the web editor and Markdown support (gitbook-comm-3, gitbook-comm-5). However, the pack never explicitly names tabs, callouts, code-groups, or step components, so the exact component set the story cites isn't directly confirmed. Missing for 10: explicit documentation/screenshots naming tabs/callouts/code-group/step blocks, and independent hands-on confirmation of those specific components.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “An updates block lets you add a changelog to any page... Any page with an updates block automatically gets an RSS feed”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”

   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
   GitBook✓fullcommunity8/10

   GitBook's visual block-based editor is explicitly designed for non-git users, with real-time collaboration and version control built in, and the same content syncs bidirectionally with Git ('Write in the editor, drive it from your agent, or sync from Git'), keeping one source of truth. Community reviews independently corroborate the web editor experience as 'phenomenal' and suited for non-developers writing docs with version control. Missing for 10: no independent evidence specifically confirming non-technical teammates' edits merge cleanly with git-synced changes without conflicts, and no hands-on account from a non-technical user's perspective.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Invite your team to collaborate”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   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 GitBook
   GitBook✓fullclaimed8/10

   GitBook's docs explicitly document a 'Reusable content' feature for defining reusable snippets/blocks that sync across pages, plus 'Content variants' for variable-driven content reuse, directly matching the story. missing for 10: independent/hands-on community corroboration specifically about snippet/variable syncing (community evidence in the pack covers other features, not this one).

   • [claimed-docs] “Reusable content”
   • [claimed-docs] “Content variants”

   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 drawn
   GitBook—none0/10

   GitBook's AI features (agent, assistant, AI insights) focus on flagging outdated/missing content and answering reader questions, not on linting prose against a style guide before publishing. No evidence of style-guide rules, vale-like linting, or pre-publish content-quality checks tied to a style guide.

   ⚑ 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 to GitBook
   GitBook~partialprobed5/10

   GitBook exposes a REST API (GET/POST/PATCH/DELETE) and an MCP server/CLI that agents can use to create/configure sites, open change requests, draft content, edit pages, and restructure docs, which enables scripted bulk-style operations across many pages/spaces programmatically. However, there's no first-party bulk-operations UI or documented batch endpoints (e.g., bulk update/delete/move across many items in one call), and no independent evidence of bulk workflows being used at scale. missing for 10: dedicated bulk-edit/batch API endpoints, documented bulk UI actions, and independent confirmation of large-scale automation use.

   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   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
   GitBook—none0/10

   GitBook's docs describe autonomous AI behaviors (auto-flagging outdated content, auto-translations, AI insights) and git-based sync triggers, but there is no evidence of a user-configurable rules/automation engine where users define custom event→action triggers (e.g., webhooks, if-this-then-that logic). Missing for 10: any documented rules/trigger builder, webhook or event-condition-action framework, or examples of users defining custom automation logic.

   ⚑ 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
   GitBook~partialclaimed5/10

   GitBook supports versioning of docs via Git sync/version control and review via Change Requests (including AI-agent-authored changes reviewed by 'GitBook Agent'), which maps loosely to versioning/reviewing AI-driven changes, but there is no explicit documentation of an 'automations' concept (e.g., agent workflows) being versioned or rolled back as a distinct object — only content/page-level version control and change-request review are evidenced. Missing for 10: explicit rollback mechanism for automations, evidence of automation objects (not just docs content) under version control, independent confirmation of the review/rollback workflow.

   • [claimed-docs] “Version control”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”

   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 GitBook
   GitBook✓fullclaimed8/10

   GitBook's 'Change requests' feature (gitbook-docs-29) provides a git-like PR workflow for docs with review, comments, approvals, and merge before publishing, and GitBook Agent can review change requests (gitbook-docs-18). missing for 10: independent/hands-on community corroboration specifically of the review-approve-merge workflow (community evidence pack only covers older GitBook versions and unrelated issues).

   • [claimed-docs] “Change requests”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “Invite your team to collaborate”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”

   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 GitBook
   GitBook~partialcommunity4/10

   GitBook advertises 'Site customization', 'Advanced branding options', and a 'block-based visual editor & custom blocks' plus custom domain support, showing some theme/branding controls (gitbook-docs-3, -11, -30, -47). However, none of the evidence explicitly confirms custom CSS/JS injection or embedding of fully custom React/UI components, and a community reviewer explicitly called landing-page customization 'limited' (gitbook-comm-3), directly cutting against a full brand-matching claim. missing for 10: explicit docs on custom CSS/JS support, custom component/embed capability, and independent confirmation that deep branding (beyond logo/colors/domain) is achievable.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Advanced branding options”
   • [claimed-docs] “Site customization”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   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 GitBook
   GitBook✓fullcommunity8/10

   GitBook documents GitHub/GitLab Sync as a core docs-as-code workflow, with version control, change requests, and branch/PR-driven publishing explicitly covered in official docs (gitbook-docs-4, gitbook-docs-24, gitbook-docs-27, gitbook-docs-29, gitbook-docs-46). Community evidence corroborates the platform's version-control and Git-based editing heritage, though some users note GitBook has shifted away from pure open-source/CLI git workflows toward its SaaS platform (gitbook-comm-13, gitbook-comm-17). missing for 10: independent hands-on confirmation that PR merges directly trigger publishing (vs. GitBook's own change-request review flow), and more detail on conflict handling between Git-sync and in-app edits.

   • [claimed-docs] “Sync with GitHub or GitLab”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   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 GitBook
   GitBook✓fullclaimed7/10

   GitBook explicitly lists 'Preview deployments' as a shipped feature alongside GitHub/GitLab sync and a change-request workflow for reviewing docs changes before they go live, matching the PR-preview-before-merge story for docs-as-code teams. Missing for 10: independent/hands-on confirmation that previews are auto-generated per PR with a shareable link, and more detail on how previews tie into the GitHub PR UI itself.

   • [claimed-docs] “Preview deployments”
   • [claimed-docs] “Sync with GitHub or GitLab”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”

   proof ↗⚑ 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
   GitBook—none0/10

   No evidence of CI-integrated link/config validation (e.g., a check that runs in pull requests or build pipelines to catch broken links or invalid config before publish). GitBook's docs-as-code features cover Git sync, change requests, and preview deployments, but nothing describes automated CI validation for links/config prior to publishing.

   ⚑ 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 GitBook
   GitBook~partialprobed6/10

   GitBook exposes a documented REST API, a CLI, and an MCP server that let agents create/configure sites, open change requests, draft/edit content, and restructure docs (gitbook-docs-28,33,34,36), suggesting broad programmatic coverage of core UI actions. However, there's no explicit claim or evidence of full feature parity between API and UI, and the OpenAPI spec/full API surface isn't independently discoverable (gitbook-probe-3 shows 404s on all candidate spec paths). Missing for 10: an explicit parity statement, a complete public OpenAPI reference, and independent/hands-on confirmation that all UI actions (e.g. branding, analytics config, redirects) are API-accessible.

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   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
   GitBook~partialcommunity5/10

   GitBook supports two-way Git Sync with GitHub/GitLab, storing content as Markdown with version control, which gives a real open-format export/exit path (gitbook-docs-27, gitbook-docs-24, gitbook-docs-46). However, there's no documented full-data export (analytics, users, integrations) and community feedback explicitly criticizes GitBook for moving away from open-source/self-hosted use and locking features behind its SaaS ('non open source behavior to only support their monthly service', 'abandoned open source spirit') (gitbook-comm-13, gitbook-comm-15). Missing for 10: a documented one-click full-account export, confirmation that all site/analytics/config data (not just page content) is portable, and resolution of community concerns about SaaS lock-in.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”

   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
   GitBook—none0/10

   No first-party evidence that GitBook publishes its source under an open license; recent community reports explicitly state GitBook moved away from open source and no longer actively develops its once-open CLI, confirming the product is closed-source SaaS today.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ 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
   GitBook—none0/10

   GitBook is documented and confirmed by community evidence as a SaaS-only platform; multiple users explicitly note GitBook 'moved everything to their SaaS with artificial barriers to just using the software' and abandoned its open-source spirit, with the CLI 'no longer under active development.' No vendor documentation anywhere offers a self-hosted deployment option for the core product.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   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
   GitBook—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or geographic storage controls for GitBook content; the pricing/feature list covers editing, sync, and AI features but nothing about regional data storage choices.

   ⚑ 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
   GitBook—none0/10

   No evidence in the pack discusses data retention policies, data deletion controls, export/purge tooling, or privacy/compliance settings for AI-native users; the docs focus on content authoring, MCP/AI assistant features, and publishing, not data governance.

   ⚑ 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
   GitBook—none0/10

   No evidence in the pack addresses telemetry, analytics opt-out, or usage tracking controls for AI-native users; the closest items (Analytics & user feedback, AI insights) describe collecting data, not opting out of it.

   ⚑ 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
   GitBook~partialclaimed6/10

   GitBook's official docs include a dedicated 'Authenticated access' page under Publish > Site Audience, directly matching the gating-content-behind-auth use case, but the evidence pack gives only the page title with no detail on which auth mechanisms (password vs JWT vs SSO) are actually supported or how they're configured, and there's no independent/community corroboration of this specific feature working in practice. Missing for 10: documented specifics on password/JWT/SSO configuration options, plan-tier restrictions, and independent verification that authenticated access works as described.

   • [claimed-docs] “Authenticated access”

   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
   GitBook✓fullclaimed8/10

   GitBook explicitly documents custom domain support ('You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain') and lists 'Use a custom domain' as a pricing feature. This directly satisfies the core ask of serving docs on a custom domain. missing for 10: no explicit documentation or example of a /docs subpath deployment on the main site's domain, and no independent/hands-on confirmation of custom domain setup beyond vendor docs.

   • [claimed-docs] “Use a custom domain”
   • [claimed-docs] “You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain.”

   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 to Fern
   GitBook—none0/10

   GitBook offers Git sync of markdown source content but no documented feature for exporting the full rendered site (theme, navigation, assets) as a static bundle for self-hosting elsewhere; probes for such export endpoints return 404. Community commentary explicitly describes lock-in concerns ('artificial barriers to just using the software... non open source behavior to only support their monthly service', 'abandoned open source spirit') and the CLI being deprecated, reinforcing that no portable static-export path exists.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “GitBook CLI”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   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 GitBook
   GitBook~partialcommunity6/10

   GitBook documents a built-in 'AI search' feature and a dedicated 'Searching internal content' doc, and independent community feedback praises GitBook's search as 'fast & accurate' out of the box. However, no evidence explicitly confirms typo-tolerance or details on relevance-ranking algorithms, so the specific claims in the story are only partially substantiated. Missing for 10: explicit documentation of typo-tolerant/fuzzy matching, technical detail on relevance ranking, and independent hands-on testing of search quality across a full site.

   • [claimed-docs] “AI search”
   • [claimed-docs] “Searching internal content”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   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 to GitBook
   GitBook~partialcommunity6/10

   GitBook docs describe auto-translation features to keep content updated across languages with minimal effort, and site customization docs note the UI can match the language of the content (implying localized navigation elements). However, there's no explicit first-party documentation detailing translated navigation menus/labels specifically, and the only independent corroboration of multi-language support is from a much older version of the product (pre-SaaS book publishing era). Missing for 10: explicit documentation of translated navigation trees/menus, current independent/hands-on verification of multi-language site publishing.

   • [claimed-docs] “Auto translations make it easy to keep your documentation up-to-date in multiple languages, with minimal manual effort.”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “GitBook co-founder: 'We have a lot of non-english books actually... over a thousand in chinese alone. In the upcoming 2.0.0 release, we've f…”

   proof ↗⚑ 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
   GitBook~partialclaimed6/10

   GitBook documents a 'Content variants' feature explicitly for maintaining multiple versions of a site (e.g., per product/API version) and separate 'Version control' docs-as-code capability, which together support the story of versioned docs with reader-facing switching. However, all evidence is vendor documentation with no independent hands-on confirmation of the version-switcher UI/UX or how seamless the reader experience is. Missing for 10: independent/community verification of the version switcher working well in practice, and more detail on how readers navigate between variants.

   • [claimed-docs] “Content variants”
   • [claimed-docs] “Version control”
   • [claimed-docs] “each site is made up of sections — the pages you write and edit live inside a section. Related sections can be organized into groups to shap…”

   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