[ { "productId": "docusaurus", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes show Docusaurus's own site has no llms.txt (404) and no agent-oriented docs.md endpoint (404), and no docs evidence describes shipping llms.txt support for generated sites either.", "evidenceIds": [ "docusaurus-probe-1", "docusaurus-probe-2" ] }, { "productId": "docusaurus", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator for documentation; it has no data/analytics layer over which to generate AI insights or suggestions, making this axis a category error for this type of product.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator; setting up autonomous background automations is not a capability category this product type addresses, and no evidence suggests it offers any agentic/automation runtime.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator with no built-in AI assistant feature; this axis applies to agentic products, not documentation frameworks, which is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docusaurus ships a documented CLI (`npm run build`, `docusaurus serve`) that produces static files non-interactively, which is the basis for running it in CI/CD pipelines (e.g., building docs on every push and deploying to Vercel/Netlify/GitHub Pages), and this is a standard, well-documented workflow for static-site generators. However, there's no first-party CI-specific guide (e.g., GitHub Actions workflow) in the evidence, and community reports describe build performance problems severe enough to time out GitHub Actions runners on larger sites, which undercuts reliability for automation at scale. Missing for 10: explicit CI/automation documentation or example workflow, and independent confirmation of successful large-scale CI builds (contradicted in part by comm-10's report of CI timeouts).", "evidenceIds": [ "docusaurus-docs-13", "docusaurus-docs-22", "docusaurus-docs-38", "docusaurus-docs-37", "docusaurus-probe-4", "docusaurus-comm-10", "docusaurus-comm-17" ] }, { "productId": "docusaurus", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator, not an AI agent or assistant; plugging MCP servers into it so it can 'use their tools' is a category error for this kind of product, and no evidence suggests it has an agentic runtime that consumes MCP tools.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site generator for documentation, not an agent or a platform expected to expose an MCP server; no evidence of an MCP server or agent-connectivity feature exists, and this axis is a category mismatch for this product type.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator operated via CLI commands, config files, and code; natural-language command operation is not a fair axis for this category of product, and no evidence suggests any NL interface exists.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docusaurus ships a well-documented official CLI (create-docusaurus scaffolding, docusaurus start/build/serve, versioning and swizzle commands) confirmed by docs and a probe hit on /docs/cli, all scriptable via npm and usable non-interactively by automation/agents. Missing for 10: no explicit documentation or examples of AI-agent-specific usage/integration, and no independent hands-on confirmation of CLI reliability in automated/agentic pipelines.", "evidenceIds": [ "docusaurus-docs-1", "docusaurus-docs-11", "docusaurus-docs-6", "docusaurus-docs-38", "docusaurus-probe-4" ] }, { "productId": "docusaurus", "storyId": "agentic-public-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docusaurus exposes a documented CLI (build, serve, versioning commands) and a plugin/Node API that let a user or script drive site generation and customization programmatically, which is the closest analog to a public API for this static-site-generator category. However, probes confirm there is no REST/OpenAPI, no llms.txt, and no HTTP-callable interface for AI agents to interact with — only local CLI/build-time automation. Missing for 10: HTTP/REST or OpenAPI-documented API, AI-agent discovery file (llms.txt), and any remote/service-style programmatic interface beyond local CLI/plugin hooks.", "evidenceIds": [ "docusaurus-docs-11", "docusaurus-docs-21", "docusaurus-docs-38", "docusaurus-docs-8", "docusaurus-docs-25", "docusaurus-probe-4", "docusaurus-probe-1", "docusaurus-probe-2", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator with no API/credential system or agent-facing service; scoped API credentialing is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docusaurus documents official developer-facing APIs to build against — a plugin architecture (docs-4, docs-8, docs-25), theme swizzling API (docs-10, docs-27), and a documented CLI (docusaurus-probe-4, docusaurus-docs-11) — which count as 'official SDKs' for extending/building sites. However, there is no AI-native machine-readable SDK surface: llms.txt and docs.md both 404, and no OpenAPI spec exists (docusaurus-probe-1, docusaurus-probe-2, docusaurus-probe-3), so an AI agent cannot discover or consume an official SDK spec automatically. Missing for 10: machine-readable API/SDK manifests (llms.txt, OpenAPI), any AI-specific SDK or agent-facing integration docs, and independent confirmation that the plugin/theme APIs are stable enough to be treated as a true SDK.", "evidenceIds": [ "docusaurus-docs-4", "docusaurus-docs-8", "docusaurus-docs-10", "docusaurus-docs-25", "docusaurus-probe-4", "docusaurus-probe-1", "docusaurus-probe-2", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site generator with no runtime event system; webhooks/subscriptions are outside its category as a build tool for docs sites, not a service with events to subscribe to.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "ai-agent-maintains-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator/framework, not an AI agent platform; it has no concept of an AI agent drafting/updating docs from prompts or schedules, or shipping change requests. This capability is entirely outside its product category, making the axis inapplicable rather than unmet.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "ai-assistant-on-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an embedded AI assistant or Q&A-with-citations feature; Docusaurus documentation covers search (Algolia DocSearch), MDX, plugins, versioning, i18n, etc., but nothing about an AI chat/assistant answering reader questions with citations into content.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "ai-traffic-analytics", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator, not an analytics platform; distinguishing AI-agent vs human traffic is an analytics/observability capability entirely outside its scope. This is a category error, not a missing feature.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docusaurus's evidence shows only generic MDX/React embedding, versioning, i18n, and search features—no built-in interactive API reference or runnable-example tooling (e.g., OpenAPI/Swagger integration) is documented, and probes for openapi.json/swagger.json all return 404. While MDX could theoretically host custom interactive widgets, there's no evidence of a first-party or documented capability for this specific story.", "evidenceIds": [ "docusaurus-docs-3", "docusaurus-docs-31", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a documentation site generator, not an API service, but it could plausibly expose a machine-readable spec of its own CLI/config or plugin API; probes explicitly show no OpenAPI/swagger spec exists at any expected path, and no docs mention publishing one.", "evidenceIds": [ "docusaurus-probe-3", "docusaurus-probe-1", "docusaurus-probe-2" ] }, { "productId": "docusaurus", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator for documentation, not a data-driven application or agentic service with 'production data' to sandbox against; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The pack shows Docusaurus has a 'document versioning' feature for content (docs-6, docs-19, docs-23), but that is unrelated to the story's ask about the framework's own APIs (plugin API, config schema, npm package) being semantically versioned with a documented deprecation policy. No evidence of a changelog, semver policy, or deprecation notices for Docusaurus's own APIs is present; the only related note is that v2 was a 'total rewrite' from v1 (docusaurus-docs-16), which suggests breaking changes rather than a managed deprecation path.", "evidenceIds": [ "docusaurus-docs-16", "docusaurus-docs-6", "docusaurus-docs-19" ] }, { "productId": "docusaurus", "storyId": "authenticated-docs-access", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator; the evidence pack contains no mention of built-in authentication, password protection, JWT, or SSO gating features. Since Docusaurus builds static HTML files meant to be publicly served (docs-2, docs-13), auth-gating is a plausible but unaddressed capability for a docs publishing tool, making this 'none' rather than 'na'.", "evidenceIds": [ "docusaurus-docs-2", "docusaurus-docs-13", "docusaurus-docs-22" ] }, { "productId": "docusaurus", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docusaurus is a static site generator with a CLI for building/serving sites, but there is no evidence of any bulk operation capability across many content items (e.g., bulk editing, batch content transformation, mass metadata updates) beyond a single site build/version command; probes for machine-readable APIs (llms.txt, docs.md, openapi) all returned 404, showing no programmatic bulk-automation surface. Missing for 10: any documented bulk-edit/batch-processing feature, API or CLI subcommand for operating across many items at once, and evidence of AI-native automation tooling.", "evidenceIds": [ "docusaurus-docs-11", "docusaurus-docs-6", "docusaurus-probe-1", "docusaurus-probe-2", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator for documentation; it has no event/rule-trigger automation system for AI-native workflows — this axis is a category error for this type of product, not a missing feature.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator with no workflow/job orchestration capability; scheduling recurring jobs is outside its product category and not a fair axis for this tool.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static documentation site generator, not an automation platform; it has no concept of 'automations' to version, review, or roll back (document versioning is unrelated to automation workflows). This is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "ci-broken-link-checks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention broken-link checking, config validation, or CI integration/build-failure behavior for invalid content; only build/serve/deploy CLI commands are documented. This is a fair axis for a docs-as-code SSG (Docusaurus does have onBrokenLinks options in reality, but nothing in the evidence pack supports it).", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "content-linting-style", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any built-in or first-party linting/style-guide checking feature for content; Docusaurus docs cover MDX authoring, versioning, i18n, search, deployment, but nothing about automated prose/style linting before publish.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "custom-domain-subpath", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docusaurus docs confirm it builds static files deployable to common static hosts (Vercel, GitHub Pages, Netlify, etc.) and provides a `docusaurus serve` command, which implicitly supports custom domains via those hosts. However, the evidence pack never explicitly documents the `baseUrl` config for subpath deployment or custom-domain setup instructions (e.g., CNAME files), leaving the core of the story only inferred rather than directly evidenced. Missing for 10: explicit docs on baseUrl/subpath configuration, explicit custom-domain setup guidance, and independent confirmation of successful custom-domain/subpath deployments.", "evidenceIds": [ "docusaurus-docs-37", "docusaurus-docs-38", "docusaurus-docs-13", "docusaurus-docs-22" ] }, { "productId": "docusaurus", "storyId": "docs-analytics", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator; evidence shows search (Algolia DocSearch) support but nothing about built-in analytics dashboards, page-view tracking, search-term analytics, or reader feedback collection. No evidence of any such capability exists in the pack.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "docs-mcp-for-readers", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence Docusaurus generates or exposes an MCP server for published docs sites; search is via Algolia DocSearch, not an agent-queryable MCP endpoint, and probes for llms.txt/docs.md/openapi all 404.", "evidenceIds": [ "docusaurus-docs-5", "docusaurus-docs-20", "docusaurus-probe-1", "docusaurus-probe-2", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "docs-versioning", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docusaurus has built-in, well-documented versioning support (versioning CLI to snapshot docs directory into a version, version dropdown for readers to switch) and dedicated docs on this exact workflow, plus i18n for localization. No independent hands-on corroboration specifically for the versioning UX is present, and no evidence of a version-switcher dropdown being explicitly named, so missing for 10: independent/community confirmation of the version-switch UI in practice, edge-case coverage for large numbers of versions.", "evidenceIds": [ "docusaurus-docs-6", "docusaurus-docs-19", "docusaurus-docs-23", "docusaurus-docs-24" ] }, { "productId": "docusaurus", "storyId": "git-sync-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docusaurus is fundamentally a static-site generator that builds from Markdown/MDX files stored in your own repo, and its docs plugin explicitly reads content from a `docs` directory that you version-control (versioning CLI operates on `docs` directory content), with localization also handled 'via git' or other translation managers. It deploys to static hosts like GitHub Pages, Netlify, Vercel that are commonly wired to git push/PR/merge triggers, and community users confirm using it for markdown-based docs-as-code workflows (migrating docs, contributing via git). Missing for 10: no explicit documentation of PR-preview builds, branch-based deploy previews, or CI/CD pipeline configuration specifics.", "evidenceIds": [ "docusaurus-docs-2", "docusaurus-docs-8", "docusaurus-docs-18", "docusaurus-docs-23", "docusaurus-docs-37", "docusaurus-comm-13", "docusaurus-comm-20" ] }, { "productId": "docusaurus", "storyId": "instant-search-quality", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docusaurus does not ship its own out-of-the-box search index; it relies on integrating third-party Algolia DocSearch, which requires a separate application/setup and free-tier approval, and there's a migration note suggesting the infra has changed over time. Typo-tolerant, relevance-ranked search is achieved via Algolia (once configured), not built-in by default. missing for 10: evidence of a zero-config/built-in local search out of the box, independent confirmation of Algolia's typo-tolerance/ranking quality in practice, and details on setup friction or fallback for sites not approved for free DocSearch.", "evidenceIds": [ "docusaurus-docs-5", "docusaurus-docs-14", "docusaurus-docs-20", "docusaurus-docs-28", "docusaurus-docs-35" ] }, { "productId": "docusaurus", "storyId": "interactive-api-playground", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site/documentation generator supporting MDX, React embeds, versioning, i18n, and search, but nothing in the evidence pack shows a built-in interactive API playground/try-it-out console for making real API calls; probes for OpenAPI support also failed (404s). Developers could theoretically embed a custom React component for this via MDX, but no evidence shows an out-of-the-box or officially supported playground feature.", "evidenceIds": [ "docusaurus-docs-3", "docusaurus-docs-31", "docusaurus-probe-3" ] }, { "productId": "docusaurus", "storyId": "llms-txt-generated", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence Docusaurus core ships automatic llms.txt or full-content markdown variant generation; direct probes of the Docusaurus own site show 404 for both llms.txt and docs.md, and no docs mention this feature.", "evidenceIds": [ "docusaurus-probe-1", "docusaurus-probe-2" ] }, { "productId": "docusaurus", "storyId": "localization-i18n", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docusaurus has built-in i18n support explicitly designed for translating docs and navigation, with support for git/Crowdin translation workflows and RTL locales, plus versioning to keep translated docs in sync with releases. Missing for 10: independent hands-on verification of translated navigation specifically (community evidence focuses on other features, not i18n workflows).", "evidenceIds": [ "docusaurus-docs-7", "docusaurus-docs-18", "docusaurus-docs-24", "docusaurus-docs-34", "docusaurus-docs-39" ] }, { "productId": "docusaurus", "storyId": "md-mirror-endpoints", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus builds static HTML from Markdown/MDX but there is no evidence of a per-page clean-markdown endpoint (e.g. .md suffix) or llms.txt-style output; direct probes confirm llms.txt and docs.md both 404, indicating this capability is not shipped.", "evidenceIds": [ "docusaurus-probe-1", "docusaurus-probe-2", "docusaurus-docs-2" ] }, { "productId": "docusaurus", "storyId": "mdx-components-authoring", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docusaurus docs confirm built-in MDX/JSX support letting writers embed and import React components directly in Markdown without hand-writing HTML (docusaurus-docs-3, docusaurus-docs-17, docusaurus-docs-31, docusaurus-docs-32), and community users confirm using Markdown+React together happily (docusaurus-comm-13, docusaurus-comm-20). However, the evidence never explicitly names or documents the specific built-in rich components the story calls out (Tabs, admonitions/callouts, code-block groups, Steps) — it only shows general MDX/component-embedding capability. missing for 10: explicit docs citing built-in Tabs/Admonition/CodeBlock-group/Steps components, and hands-on confirmation that writers use them without custom code.", "evidenceIds": [ "docusaurus-docs-3", "docusaurus-docs-17", "docusaurus-docs-31", "docusaurus-docs-32", "docusaurus-comm-13", "docusaurus-comm-20" ] }, { "productId": "docusaurus", "storyId": "openapi-reference-generation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions OpenAPI spec import, API reference page generation, or spec-sync capability; Docusaurus core is described as a Markdown/MDX static-site generator with docs/blog/pages plugins, not an OpenAPI-driven doc generator. The OpenAPI probe explicitly found no such endpoints/support.", "evidenceIds": [ "docusaurus-probe-3", "docusaurus-docs-8", "docusaurus-docs-40" ] }, { "productId": "docusaurus", "storyId": "openness-api-parity", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site-generator/CLI framework with no distinct product UI and separate API surface to compare — configuration and content creation already happen entirely through code, Markdown/MDX files, and CLI commands, so the UI-vs-API parity question is a category mismatch for this kind of tool.", "evidenceIds": [ "docusaurus-docs-1", "docusaurus-docs-11", "docusaurus-docs-4", "docusaurus-probe-4" ] }, { "productId": "docusaurus", "storyId": "openness-full-export", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docusaurus content is authored as plain Markdown/MDX files stored in the user's own git repo and compiled to static HTML, meaning there is no proprietary data store to 'export from' — the source of truth is already an open, portable format the user fully owns, reinforced by MIT licensing and git/Crowdin-based translation workflows. missing for 10: no explicit vendor documentation framing this as a 'data export/exit' guarantee, and no independent report confirming users successfully migrated away with zero data loss (only anecdotal mentions of switching to other SSGs).", "evidenceIds": [ "docusaurus-docs-2", "docusaurus-docs-17", "docusaurus-docs-13", "docusaurus-docs-22", "docusaurus-docs-18", "docusaurus-docs-34", "docusaurus-comm-16", "docusaurus-comm-12" ] }, { "productId": "docusaurus", "storyId": "openness-open-license", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Community evidence confirms Docusaurus is open source and MIT licensed, with users noting they can read, fork, and contribute to the source code (docusaurus-comm-16, docusaurus-comm-1). No evidence contradicts open licensing. missing for 10: first-party documentation or GitHub repo citation explicitly stating the MIT license, and no direct link to the source repository in the evidence pack.", "evidenceIds": [ "docusaurus-comm-16", "docusaurus-comm-1" ] }, { "productId": "docusaurus", "storyId": "openness-self-host", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docusaurus is a static-site generator that builds fully self-hostable static HTML output via `npm run build`, deployable to any static host (Vercel, Netlify, GitHub Pages, or self-managed servers) with no vendor lock-in, and is MIT licensed so it can be forked/self-maintained indefinitely. Community evidence corroborates real-world self-hosting and even forking concerns being addressed by its open license. Missing for 10: no first-party Docker/container self-hosting guide or independent benchmark of a fully self-hosted deployment pipeline.", "evidenceIds": [ "docusaurus-docs-13", "docusaurus-docs-22", "docusaurus-docs-37", "docusaurus-docs-38", "docusaurus-comm-16", "docusaurus-docs-2" ] }, { "productId": "docusaurus", "storyId": "preview-deployments", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site generator; PR preview deployments are provided by hosting platforms (Netlify, Vercel, GitHub Actions) rather than by Docusaurus itself, so this CI/hosting-workflow axis is a category error for the tool. Evidence only covers local dev server and static build/deploy to third-party hosts, not a PR-preview feature owned by Docusaurus.", "evidenceIds": [ "docusaurus-docs-11", "docusaurus-docs-37", "docusaurus-docs-13" ] }, { "productId": "docusaurus", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static-site generator you self-host; there is no vendor-managed data storage or hosted service component to which a region/residency choice could apply — users deploy build output wherever they choose (Vercel, GitHub Pages, Netlify, etc.), which is a deployment choice, not a data-residency feature.", "evidenceIds": [ "docusaurus-docs-37", "docusaurus-docs-13" ] }, { "productId": "docusaurus", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator; it has no data-collection/AI-training relationship with its users' content, so an AI-training opt-out control is a category error for this product type.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator that builds local files from user-owned content; it has no hosted data-processing service that would collect or retain user data, so 'data retention and deletion' controls are a category error for this product type.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of telemetry, analytics collection, or an opt-out mechanism for Docusaurus's CLI or build process; while such a capability is plausible for a CLI-driven static site generator, there is no documentation or community evidence confirming it exists.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "reusable-content-snippets", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docusaurus's MDX support lets writers define partial files and import them as reusable components across pages (docs-3, docs-31), which is the documented mechanism for reusable snippets, but the evidence pack never explicitly mentions a dedicated 'variables' or site-wide constants feature (e.g. customFields) or admonition-style snippet reuse guidance. missing for 10: explicit docs on site-wide variables/customFields, dedicated partials/snippets guide, independent hands-on confirmation that content stays in sync across pages.", "evidenceIds": [ "docusaurus-docs-3", "docusaurus-docs-31", "docusaurus-docs-17" ] }, { "productId": "docusaurus", "storyId": "review-change-requests", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a static site generator with no built-in review/approval/merge workflow of its own; such collaboration workflows are handled entirely by the git hosting platform (e.g. GitHub PRs), which is outside Docusaurus's product category. This axis is a category error for a static site generator itself.", "evidenceIds": [] }, { "productId": "docusaurus", "storyId": "static-export-portability", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docusaurus builds static HTML files via `npm run build` into a `build` directory, which can be hosted on any static host (Vercel, GitHub Pages, Netlify, Render, Surge) or served locally via `docusaurus serve`, confirming no vendor lock-in. Community comments corroborate real-world deployment and migration flexibility. Missing for 10: no independent hands-on verification of exporting/re-hosting a site across multiple providers beyond docs claims.", "evidenceIds": [ "docusaurus-docs-2", "docusaurus-docs-13", "docusaurus-docs-22", "docusaurus-docs-37", "docusaurus-docs-38" ] }, { "productId": "docusaurus", "storyId": "theming-brand-customization", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docusaurus provides multiple documented layers of theming/branding: custom CSS import via classic theme (docusaurus-docs-9/26/41), full React component customization and MDX embedding (docusaurus-docs-4/31/33), and swizzling to override/replace built-in theme components entirely (docusaurus-docs-10/27), plus a plugin architecture for deeper extension (docusaurus-docs-8/40). Community testimonials corroborate real-world use of React/TypeScript/CSS customization (docusaurus-comm-13/20). Missing for 10: independent hands-on verification specifically of brand-level theming (fonts/logo/full rebrand) rather than general customization mentions.", "evidenceIds": [ "docusaurus-docs-9", "docusaurus-docs-26", "docusaurus-docs-10", "docusaurus-docs-27", "docusaurus-docs-4", "docusaurus-docs-31", "docusaurus-docs-33", "docusaurus-docs-8", "docusaurus-comm-13", "docusaurus-comm-20" ] }, { "productId": "docusaurus", "storyId": "wysiwyg-web-editor", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Docusaurus is a git-based, MDX/React static site generator with no visual web editor for non-technical users — all editing happens via markdown files and git workflows; no evidence of a WYSIWYG editor or non-git content sync.", "evidenceIds": [] }, { "productId": "fern", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-6", "fern-docs-7", "fern-docs-37", "fern-docs-17", "fern-docs-18", "fern-probe-1", "fern-probe-2" ] }, { "productId": "fern", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29", "fern-docs-3" ] }, { "productId": "fern", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29", "fern-docs-45" ] }, { "productId": "fern", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29", "fern-docs-42", "fern-docs-45" ] }, { "productId": "fern", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-33", "fern-docs-34", "fern-docs-35", "fern-docs-8", "fern-docs-25", "fern-probe-5" ] }, { "productId": "fern", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Fern is a documentation/SDK platform whose AI features consist of hosting/generating MCP servers for others (Claude Code, Cursor, Windsurf) to consume — the evidence consistently shows Fern as the MCP *server* provider, not a product that itself plugs in external MCP servers to gain new tools. There is no evidence of Fern acting as an MCP client consuming third-party servers, and this axis (being extended by MCP servers) is not a fit for a docs/SDK platform's product role.", "evidenceIds": [ "fern-docs-4", "fern-docs-5", "fern-docs-24", "fern-probe-4" ] }, { "productId": "fern", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-4", "fern-docs-5", "fern-docs-24", "fern-docs-38", "fern-probe-4" ] }, { "productId": "fern", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29", "fern-docs-42", "fern-docs-45", "fern-docs-3", "fern-docs-34" ] }, { "productId": "fern", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-1", "fern-docs-34", "fern-docs-35", "fern-probe-5" ] }, { "productId": "fern", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-probe-3", "fern-docs-34", "fern-docs-1", "fern-docs-33" ] }, { "productId": "fern", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-gh-1", "fern-docs-21", "fern-docs-32", "fern-docs-36", "fern-docs-46", "fern-comm-2" ] }, { "productId": "fern", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "ai-agent-maintains-docs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29", "fern-docs-45", "fern-docs-42" ] }, { "productId": "fern", "storyId": "ai-assistant-on-docs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-3", "fern-docs-43" ] }, { "productId": "fern", "storyId": "ai-traffic-analytics", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-18", "fern-docs-44" ] }, { "productId": "fern", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-22", "fern-docs-9", "fern-docs-32", "fern-gh-1" ] }, { "productId": "fern", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-22", "fern-probe-3", "fern-docs-46" ] }, { "productId": "fern", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Fern is an SDK generator and documentation platform, not a data/service product with a runtime environment where sandbox vs. production data would apply; there's no notion of 'production data' being touched by test operations in this product's category.", "evidenceIds": [] }, { "productId": "fern", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-13", "fern-docs-28", "fern-docs-40" ] }, { "productId": "fern", "storyId": "authenticated-docs-access", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-19", "fern-docs-20" ] }, { "productId": "fern", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-34", "fern-docs-32", "fern-docs-8", "fern-docs-25" ] }, { "productId": "fern", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-45", "fern-docs-29" ] }, { "productId": "fern", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Fern Agent can reportedly be put 'on a schedule' to automatically review reader feedback, unanswered Ask Fern questions, or analytics and open pull requests when warranted — a genuine recurring-workflow automation. However, this is described only in brief changelog entries with no detail on scheduling granularity, cron-like configuration, or reliability, and no independent/hands-on confirmation exists. Missing for 10: documented scheduling configuration options, broader recurring-job use cases beyond docs-review automation, and third-party corroboration.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29" ] }, { "productId": "fern", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-29" ] }, { "productId": "fern", "storyId": "ci-broken-link-checks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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).", "evidenceIds": [ "fern-docs-1" ] }, { "productId": "fern", "storyId": "content-linting-style", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-1" ] }, { "productId": "fern", "storyId": "custom-domain-subpath", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-15", "fern-docs-27", "fern-docs-41" ] }, { "productId": "fern", "storyId": "docs-analytics", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-18", "fern-docs-25", "fern-docs-44" ] }, { "productId": "fern", "storyId": "docs-mcp-for-readers", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-4", "fern-docs-24", "fern-probe-4" ] }, { "productId": "fern", "storyId": "docs-versioning", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-13", "fern-docs-28", "fern-docs-40" ] }, { "productId": "fern", "storyId": "git-sync-workflow", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-1", "fern-docs-29", "fern-docs-8", "fern-docs-2" ] }, { "productId": "fern", "storyId": "instant-search-quality", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-10", "fern-docs-3", "fern-docs-18", "fern-docs-44" ] }, { "productId": "fern", "storyId": "interactive-api-playground", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "llms-txt-generated", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "fern-docs-7", "fern-docs-37", "fern-docs-6", "fern-docs-18", "fern-probe-1", "fern-probe-2" ] }, { "productId": "fern", "storyId": "localization-i18n", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "md-mirror-endpoints", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-6", "fern-docs-7", "fern-probe-1", "fern-probe-2" ] }, { "productId": "fern", "storyId": "mdx-components-authoring", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-22", "fern-docs-1", "fern-docs-14" ] }, { "productId": "fern", "storyId": "openapi-reference-generation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-22", "fern-docs-33", "fern-docs-46", "fern-docs-9", "fern-docs-1" ] }, { "productId": "fern", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-1", "fern-docs-34", "fern-docs-2", "fern-probe-5" ] }, { "productId": "fern", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-22", "fern-docs-33", "fern-docs-46", "fern-comm-2" ] }, { "productId": "fern", "storyId": "openness-open-license", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-gh-1", "fern-comm-2" ] }, { "productId": "fern", "storyId": "openness-self-host", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-11", "fern-docs-31", "fern-comm-2", "fern-gh-1" ] }, { "productId": "fern", "storyId": "preview-deployments", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-14", "fern-docs-26", "fern-docs-39" ] }, { "productId": "fern", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Fern is a documentation/SDK-generation platform, not an AI model provider or chat product that trains on user data; there is no data-usage-for-training relationship to opt out of, making this axis a category error for this product type.", "evidenceIds": [] }, { "productId": "fern", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "reusable-content-snippets", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "review-change-requests", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-8", "fern-docs-25", "fern-docs-2", "fern-docs-29" ] }, { "productId": "fern", "storyId": "static-export-portability", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "fern-docs-11", "fern-docs-31" ] }, { "productId": "fern", "storyId": "theming-brand-customization", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "fern", "storyId": "wysiwyg-web-editor", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "fern-docs-2" ] }, { "productId": "gitbook", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-probe-1", "gitbook-docs-32", "gitbook-docs-45", "gitbook-docs-40", "gitbook-docs-15", "gitbook-probe-2" ] }, { "productId": "gitbook", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-21", "gitbook-docs-37", "gitbook-docs-38", "gitbook-docs-1" ] }, { "productId": "gitbook", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-1", "gitbook-docs-38", "gitbook-docs-41", "gitbook-docs-18" ] }, { "productId": "gitbook", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-16", "gitbook-docs-31", "gitbook-docs-39", "gitbook-docs-38", "gitbook-docs-18", "gitbook-docs-37" ] }, { "productId": "gitbook", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-28", "gitbook-docs-34", "gitbook-docs-27", "gitbook-docs-36", "gitbook-comm-17" ] }, { "productId": "gitbook", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence documents GitBook publishing its own MCP server so external AI agents (Claude Code, Cursor, etc.) can call GitBook's tools (gitbook-docs-14, gitbook-docs-15, gitbook-docs-33, gitbook-probe-4) — this is GitBook acting as an MCP server, not as an MCP client consuming external servers' tools. There is no evidence that GitBook's own AI Assistant or Agent can be configured to plug in and call third-party MCP servers.", "evidenceIds": [ "gitbook-docs-14", "gitbook-docs-15", "gitbook-docs-33", "gitbook-probe-4" ] }, { "productId": "gitbook", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-14", "gitbook-docs-15", "gitbook-docs-33", "gitbook-probe-4" ] }, { "productId": "gitbook", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "gitbook-docs-14", "gitbook-docs-15", "gitbook-docs-33", "gitbook-docs-34", "gitbook-docs-17", "gitbook-probe-4" ] }, { "productId": "gitbook", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "gitbook-docs-28", "gitbook-docs-34", "gitbook-docs-33" ] }, { "productId": "gitbook", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-docs-36", "gitbook-docs-28", "gitbook-docs-34", "gitbook-docs-14", "gitbook-docs-33", "gitbook-probe-4", "gitbook-probe-3" ] }, { "productId": "gitbook", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-36", "gitbook-docs-33", "gitbook-docs-19" ] }, { "productId": "gitbook", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-36", "gitbook-docs-28", "gitbook-docs-34" ] }, { "productId": "gitbook", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [ "gitbook-docs-36", "gitbook-probe-3" ] }, { "productId": "gitbook", "storyId": "ai-agent-maintains-docs", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-38", "gitbook-docs-18", "gitbook-docs-29", "gitbook-docs-33", "gitbook-docs-45", "gitbook-docs-17" ] }, { "productId": "gitbook", "storyId": "ai-assistant-on-docs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-16", "gitbook-docs-31", "gitbook-docs-39", "gitbook-docs-37", "gitbook-docs-9" ] }, { "productId": "gitbook", "storyId": "ai-traffic-analytics", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-12", "gitbook-docs-21", "gitbook-docs-37", "gitbook-docs-40" ] }, { "productId": "gitbook", "storyId": "api-interactive-docs", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-5", "gitbook-docs-23", "gitbook-docs-35", "gitbook-docs-36" ] }, { "productId": "gitbook", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-probe-3", "gitbook-docs-36", "gitbook-docs-23" ] }, { "productId": "gitbook", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "GitBook is a documentation platform, not a system with production data/transactions that would require a sandbox vs. production distinction for testing; this axis is a category error for its product type.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-36", "gitbook-docs-24", "gitbook-probe-3" ] }, { "productId": "gitbook", "storyId": "authenticated-docs-access", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-19" ] }, { "productId": "gitbook", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-33", "gitbook-docs-34", "gitbook-docs-36", "gitbook-docs-28", "gitbook-probe-4" ] }, { "productId": "gitbook", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "GitBook is a documentation platform; scheduling recurring jobs/workflows is not a category-relevant capability for this product type, and no evidence suggests any scheduler/cron/automation-trigger feature exists.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "gitbook-docs-24", "gitbook-docs-27", "gitbook-docs-29", "gitbook-docs-18", "gitbook-docs-46" ] }, { "productId": "gitbook", "storyId": "ci-broken-link-checks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "content-linting-style", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "custom-domain-subpath", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-docs-10", "gitbook-docs-43" ] }, { "productId": "gitbook", "storyId": "docs-analytics", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "gitbook-docs-12", "gitbook-docs-21", "gitbook-docs-37", "gitbook-docs-25", "gitbook-comm-3", "gitbook-comm-4" ] }, { "productId": "gitbook", "storyId": "docs-mcp-for-readers", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-14", "gitbook-docs-15", "gitbook-docs-33", "gitbook-probe-4" ] }, { "productId": "gitbook", "storyId": "docs-versioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-20", "gitbook-docs-24", "gitbook-docs-42" ] }, { "productId": "gitbook", "storyId": "git-sync-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-docs-4", "gitbook-docs-24", "gitbook-docs-27", "gitbook-docs-29", "gitbook-docs-46", "gitbook-comm-13", "gitbook-comm-17" ] }, { "productId": "gitbook", "storyId": "instant-search-quality", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-9", "gitbook-docs-25", "gitbook-comm-4" ] }, { "productId": "gitbook", "storyId": "interactive-api-playground", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-5", "gitbook-docs-23", "gitbook-docs-35" ] }, { "productId": "gitbook", "storyId": "llms-txt-generated", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-docs-32", "gitbook-docs-45", "gitbook-probe-1" ] }, { "productId": "gitbook", "storyId": "localization-i18n", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-41", "gitbook-docs-47", "gitbook-comm-7" ] }, { "productId": "gitbook", "storyId": "md-mirror-endpoints", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-32", "gitbook-docs-33", "gitbook-docs-45", "gitbook-probe-1", "gitbook-probe-2" ] }, { "productId": "gitbook", "storyId": "mdx-components-authoring", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-3", "gitbook-docs-46", "gitbook-docs-44", "gitbook-comm-3", "gitbook-comm-5" ] }, { "productId": "gitbook", "storyId": "openapi-reference-generation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-23", "gitbook-docs-5", "gitbook-docs-35", "gitbook-docs-27", "gitbook-docs-24", "gitbook-docs-1" ] }, { "productId": "gitbook", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-28", "gitbook-docs-33", "gitbook-docs-34", "gitbook-docs-36", "gitbook-probe-3" ] }, { "productId": "gitbook", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-27", "gitbook-docs-24", "gitbook-docs-46", "gitbook-comm-13", "gitbook-comm-15" ] }, { "productId": "gitbook", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-comm-13", "gitbook-comm-15", "gitbook-comm-17" ] }, { "productId": "gitbook", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "gitbook-comm-13", "gitbook-comm-15", "gitbook-comm-17" ] }, { "productId": "gitbook", "storyId": "preview-deployments", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-6", "gitbook-docs-4", "gitbook-docs-27", "gitbook-docs-29" ] }, { "productId": "gitbook", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses opting out of AI training data usage, data privacy controls for model training, or any privacy policy statements about training exclusion; GitBook's AI features focus on LLM-readiness and search rather than data usage controls. missing for 10: any privacy policy or settings documentation on opting out of AI training, contractual/DPA language about training data use, or third-party confirmation of such a control.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "gitbook", "storyId": "reusable-content-snippets", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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).", "evidenceIds": [ "gitbook-docs-26", "gitbook-docs-20" ] }, { "productId": "gitbook", "storyId": "review-change-requests", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "gitbook-docs-29", "gitbook-docs-18", "gitbook-docs-8", "gitbook-docs-46" ] }, { "productId": "gitbook", "storyId": "static-export-portability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-27", "gitbook-docs-28", "gitbook-comm-13", "gitbook-comm-15", "gitbook-comm-17", "gitbook-probe-2", "gitbook-probe-3" ] }, { "productId": "gitbook", "storyId": "theming-brand-customization", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-3", "gitbook-docs-11", "gitbook-docs-30", "gitbook-docs-47", "gitbook-comm-3" ] }, { "productId": "gitbook", "storyId": "wysiwyg-web-editor", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "gitbook-docs-3", "gitbook-docs-8", "gitbook-docs-29", "gitbook-docs-46", "gitbook-docs-45", "gitbook-docs-27", "gitbook-comm-5", "gitbook-comm-3" ] }, { "productId": "mintlify", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mintlify auto-generates llms.txt/llms-full.txt, markdown exports, and skill.md files for agent consumption, and this is independently confirmed by a live probe returning a working llms.txt at mintlify.com. This directly enables an AI agent to be pointed at agent-oriented docs formats. Missing for 10: independent third-party verification that llms-full.txt/skill.md render correctly across customer sites (only vendor's own site probed).", "evidenceIds": [ "mintlify-docs-6", "mintlify-docs-9", "mintlify-docs-10", "mintlify-docs-24", "mintlify-probe-1" ] }, { "productId": "mintlify", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify provides an analytics dashboard covering documentation traffic, assistant conversations, search queries, and reader feedback, plus an AI assistant/agent that can answer questions and act on content, which offers some data-driven insight into how docs are used. However, this is more operational analytics than deep AI-generated 'insights and suggestions' proactively surfaced from user data (e.g., no evidence of trend analysis, content gap detection, or recommendation generation from analytics). missing for 10: proactive AI-generated recommendations/insights derived from analytics data, independent validation of 'advanced insights' (mentioned only in pricing tier name), and concrete examples of suggestions generated from user behavior data.", "evidenceIds": [ "mintlify-docs-19", "mintlify-docs-61", "mintlify-docs-3", "mintlify-docs-13" ] }, { "productId": "mintlify", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify's Automations feature explicitly supports running the documentation agent autonomously on a schedule, on repo pushes, or on connected integration events, with pre-built automations requiring no manual setup — a clear background-agentic capability. This is corroborated by the agent docs (research/plan/write/PR) and blog updates describing redesigned automations for quicker setup. Missing for 10: independent/hands-on verification of automation reliability and no detail on failure handling or monitoring of autonomous runs.", "evidenceIds": [ "mintlify-docs-5", "mintlify-docs-4", "mintlify-docs-57", "mintlify-docs-41" ] }, { "productId": "mintlify", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify ships multiple built-in AI assistants users can delegate tasks to: the docs-site chat assistant that answers questions and cites sources, the editor's built-in AI agent that edits pages, reorganizes navigation, updates config, and searches the repo, and a broader 'agent' that researches/plans/writes docs and opens PRs autonomously (including on a schedule via automations). This is corroborated across first-party docs describing distinct but overlapping delegate-to-AI workflows. Missing for 10: independent/hands-on verification of assistant task delegation quality and reliability beyond vendor docs.", "evidenceIds": [ "mintlify-docs-2", "mintlify-docs-3", "mintlify-docs-4", "mintlify-docs-5", "mintlify-docs-13", "mintlify-docs-26" ] }, { "productId": "mintlify", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify offers a CLI for local preview/build-error checking and a REST API to trigger deployments, export analytics, and manage docs programmatically, plus automations that run the agent on schedule/push/integration events — all usable in CI-like automation. However, there's no documented headless CI recipe (e.g., GitHub Actions example, CI-specific flags, or exit-code based validation) and the CLI docs emphasize local preview rather than CI. missing for 10: explicit CI/headless workflow examples (e.g. GitHub Actions integration), documented non-interactive CLI flags for build validation, independent confirmation of CLI use in automated pipelines.", "evidenceIds": [ "mintlify-docs-11", "mintlify-docs-21", "mintlify-docs-5", "mintlify-probe-5", "mintlify-docs-48", "mintlify-docs-49" ] }, { "productId": "mintlify", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All MCP-related evidence describes Mintlify exposing its own MCP servers (search, admin, index) for external AI tools like Claude/Cursor/ChatGPT to consume — the opposite direction of this story. There is no evidence that Mintlify's own agents (editor agent, docs-writing agent, automations) can be extended by plugging in third-party MCP servers so they gain new tools.", "evidenceIds": [ "mintlify-docs-7", "mintlify-docs-8", "mintlify-docs-22", "mintlify-docs-43", "mintlify-docs-44", "mintlify-docs-47", "mintlify-docs-13", "mintlify-docs-4" ] }, { "productId": "mintlify", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify documents multiple official MCP servers (search MCP, admin/write MCP, and Index MCP) that let agents like Claude, Cursor, and ChatGPT connect, search, and even edit content, confirmed by both docs and a probe verifying the page exists. missing for 10: independent hands-on confirmation that the MCP server works reliably in practice beyond vendor docs.", "evidenceIds": [ "mintlify-docs-7", "mintlify-docs-8", "mintlify-docs-22", "mintlify-docs-43", "mintlify-docs-44", "mintlify-docs-47", "mintlify-probe-4" ] }, { "productId": "mintlify", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify supports natural-language operation extensively: chat assistant for readers, editor's built-in AI agent that edits pages/navigation/settings via commands, Slack agent responding to @mentions, and MCP servers letting external AI tools (Claude, Cursor, ChatGPT) issue natural-language commands to search or edit docs. missing for 10: independent hands-on verification of the natural-language command experience (evidence is entirely vendor docs) and no third-party review confirming reliability of agent-driven edits.", "evidenceIds": [ "mintlify-docs-13", "mintlify-docs-26", "mintlify-docs-8", "mintlify-docs-52", "mintlify-docs-53", "mintlify-docs-4", "mintlify-probe-4" ] }, { "productId": "mintlify", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify ships an official CLI (mintlify-docs-11/29, confirmed by probe mintlify-probe-5) used to preview docs locally, test changes in real time, and catch build errors before deployment — a core dev/agentic workflow tool. Missing for 10: no independent/hands-on corroboration of CLI usage or evidence of AI-specific CLI subcommands tailored for agent workflows beyond standard doc preview.", "evidenceIds": [ "mintlify-docs-11", "mintlify-docs-29", "mintlify-probe-5" ] }, { "productId": "mintlify", "storyId": "agentic-public-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Mintlify documents a REST API for triggering deployments, embedding the assistant, exporting analytics, and managing docs programmatically, plus llms.txt-listed endpoints for deployment/preview management, CLI, and MCP servers for agent-driven interaction. However, a live probe found no discoverable OpenAPI/swagger spec at standard locations, and there's no independent/hands-on corroboration of the API's completeness or reliability. Missing for 10: publicly verifiable OpenAPI/schema discovery, independent developer confirmation of API usage.", "evidenceIds": [ "mintlify-docs-21", "mintlify-docs-48", "mintlify-docs-49", "mintlify-probe-3" ] }, { "productId": "mintlify", "storyId": "agentic-scoped-keys", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Mintlify does offer some role-based separation (a read-only search/index MCP server vs. a separate write-access admin MCP for editing content and settings), which hints at scoped access levels, but there is no documented mechanism for issuing fine-grained, least-privilege API keys or credentials scoped per agent/task. A hands-on account explicitly contradicts the least-privilege idea: onboarding via the GitHub app forced full access to all repositories with 'no way to get around that,' the opposite of scoped credentialing. Missing for 10: documented scoped API-key/token creation flow, per-agent permission granularity, and confirmation that write-access MCP/API keys can be limited rather than all-or-nothing.", "evidenceIds": [ "mintlify-docs-7", "mintlify-docs-8", "mintlify-docs-22", "mintlify-comm-4" ] }, { "productId": "mintlify", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mintlify documents a REST API (mintlify-docs-21) and CLI, but there is no evidence of official client SDKs (e.g., Python/JS/Go libraries) for developers to build against, and probes for an OpenAPI spec for Mintlify's own API returned 404s (mintlify-probe-3), suggesting no such SDK tooling exists.", "evidenceIds": [ "mintlify-docs-21", "mintlify-probe-3" ] }, { "productId": "mintlify", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of webhook subscription capability; Mintlify offers automations triggered by repo pushes/integration events and a REST API to trigger deployments, but nothing about outbound webhooks for subscribing to events.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "ai-agent-maintains-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mintlify's docs describe a dedicated agent that researches, plans, and writes documentation and opens pull requests for review (mintlify-docs-4), automations that trigger this agent on a schedule, on repo pushes, or on integration events (mintlify-docs-5, mintlify-docs-57), a Slack-based agent that reads thread context and opens PRs from a prompt (mintlify-docs-52, mintlify-docs-53), and an editor built-in agent that edits pages/nav/settings with review-and-merge PR workflows (mintlify-docs-13, mintlify-docs-25/26). This covers prompt-, PR-, and schedule-triggered drafting/updating shipped as change requests (PRs). Missing for 10: independent/hands-on verification of the agent's PR quality or reliability beyond vendor docs.", "evidenceIds": [ "mintlify-docs-4", "mintlify-docs-5", "mintlify-docs-13", "mintlify-docs-25", "mintlify-docs-52", "mintlify-docs-53", "mintlify-docs-57" ] }, { "productId": "mintlify", "storyId": "ai-assistant-on-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mintlify's docs describe a first-party embedded AI assistant that answers reader questions with citations and code examples (mintlify-docs-2, mintlify-docs-3), and analytics track assistant conversations (mintlify-docs-19), showing this is a real, monitored feature rather than a stub. Missing for 10: independent/hands-on third-party verification of citation accuracy in a live customer deployment (community evidence covers other topics, not assistant quality).", "evidenceIds": [ "mintlify-docs-2", "mintlify-docs-3", "mintlify-docs-19" ] }, { "productId": "mintlify", "storyId": "ai-traffic-analytics", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mintlify's analytics docs describe traffic, assistant conversations, search queries, engagement, and reader feedback metrics, but none of the evidence mentions segmenting or distinguishing AI-agent/bot traffic from human readers. No dashboard feature, API field, or blog mention addresses agent-vs-human attribution.", "evidenceIds": [ "mintlify-docs-19", "mintlify-docs-37", "mintlify-docs-21" ] }, { "productId": "mintlify", "storyId": "api-interactive-docs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify generates interactive API reference pages with request builders/API playground directly from OpenAPI specs, explicitly described as 'Interactive for developers. Structured for agents,' matching the AI-native runnable-example story. Missing for 10: independent/hands-on verification of the playground's interactivity and no direct evidence of live 'run' execution against real endpoints beyond docs claims.", "evidenceIds": [ "mintlify-docs-14", "mintlify-docs-50", "mintlify-docs-51", "mintlify-docs-32" ] }, { "productId": "mintlify", "storyId": "api-machine-spec", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mintlify explicitly supports generating API documentation from OpenAPI spec files (mintlify-docs-14), implying OpenAPI is a first-class, machine-readable input to the platform, and it also offers a REST API (mintlify-docs-21) and markdown exports (mintlify-docs-9/23) for AI consumption. However, there is no direct evidence that a hosted Mintlify docs site exposes the underlying OpenAPI file for download, and a probe of Mintlify's own site found no openapi.json/swagger.json at any standard path (mintlify-probe-3), suggesting the spec isn't uniformly published as a downloadable artifact. Missing for 10: confirmation that generated docs sites serve the raw OpenAPI/spec file at a discoverable URL, and that Mintlify's own product API has a published machine-readable spec.", "evidenceIds": [ "mintlify-docs-14", "mintlify-docs-21", "mintlify-probe-3" ] }, { "productId": "mintlify", "storyId": "api-sandbox", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify provides local CLI previews and per-PR preview deployment URLs that let users (including AI agents) test documentation changes before they reach the live/production site, which functions as a de facto sandbox for content changes without touching production. However, this is scoped to docs preview/staging rather than an explicit 'sandbox environment' with isolated test data, and there's no independent corroboration of this workflow. Missing for 10: a dedicated sandbox/test environment concept distinct from PR previews, explicit handling of test vs production data, and independent/hands-on validation of the preview-before-prod workflow.", "evidenceIds": [ "mintlify-docs-11", "mintlify-docs-17", "mintlify-docs-12", "mintlify-docs-25" ] }, { "productId": "mintlify", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains extensive documentation on Mintlify's own API (REST API for deployments, MCP servers, CLI, etc.) but no mention of API versioning schemes or a documented deprecation policy for Mintlify's own APIs/products. Probe evidence even shows the OpenAPI spec for Mintlify's own API returns 404, and there's no reference to version history or deprecation timelines anywhere in the pack.", "evidenceIds": [ "mintlify-docs-21", "mintlify-probe-3" ] }, { "productId": "mintlify", "storyId": "authenticated-docs-access", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mintlify's pricing page explicitly lists 'Authentication' as a Full-platform feature and 'SSO, SCIM & RBAC' as Enterprise-tier features, confirming gated/authenticated docs support at different tiers. However, the evidence pack contains no dedicated documentation page detailing how to configure password protection, JWT-based gating, or SSO setup mechanics, nor independent confirmation of how it works in practice. Missing for 10: a docs page describing JWT/password auth configuration, setup steps, and independent/hands-on verification of gated access working as described.", "evidenceIds": [ "mintlify-docs-60", "mintlify-docs-61" ] }, { "productId": "mintlify", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "The editor's built-in agent can 'search across your entire repository' and edit pages, reorganize navigation, and update docs.json (mintlify-docs-13/26), and automations can run the agent on schedule or across repo events (mintlify-docs-5), plus a REST API for programmatic management (mintlify-docs-21) — together implying some capacity to act across many docs items at once. However, there is no explicit documentation of a dedicated bulk-operation feature (e.g., batch rename, bulk metadata update, mass content transform) or evidence of it handling large-scale multi-item jobs reliably. Missing for 10: explicit bulk-edit/batch-processing documentation, evidence of scale/performance across many items, and independent confirmation of successful large bulk operations.", "evidenceIds": [ "mintlify-docs-13", "mintlify-docs-26", "mintlify-docs-5", "mintlify-docs-21" ] }, { "productId": "mintlify", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify's automations feature lets the agent run on a schedule, on repository pushes, or on connected integration events, which is a form of event-triggered automation, and the redesigned automations are described as pre-built for common use cases rather than a fully custom rule-definition system. This covers the 'trigger on events' part but not clearly the 'define rules/conditions' flexibility an AI-native user might want. Missing for 10: evidence of custom rule/condition authoring beyond selecting pre-built automation types, broader event-source coverage, and independent/hands-on confirmation of automation reliability.", "evidenceIds": [ "mintlify-docs-5", "mintlify-docs-57", "mintlify-docs-58" ] }, { "productId": "mintlify", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mintlify automations let the agent run 'on a schedule, on repository pushes, or on connected integration events' to maintain content, which is a form of recurring scheduled job — but this is limited to documentation-maintenance workflows, not a general-purpose scheduling/workflow engine for arbitrary AI-native tasks. missing for 10: evidence of configurable cron-like scheduling UI/API, arbitrary custom workflow definitions beyond doc maintenance, and independent/hands-on confirmation that scheduled automations work reliably.", "evidenceIds": [ "mintlify-docs-5", "mintlify-docs-41", "mintlify-docs-57" ] }, { "productId": "mintlify", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Automations run the agent and open PRs (mintlify-docs-4, mintlify-docs-5), which are versioned via git and reviewable through preview deployments and the editor before merge (mintlify-docs-12, mintlify-docs-17, mintlify-docs-25). Rollback capability exists but is documented only as an Enterprise-tier 'instant rollback' for deployments generally, not specifically for automation configurations (mintlify-docs-56, mintlify-docs-61). missing for 10: automation-specific version history/diffing UI, rollback availability for non-Enterprise plans, and independent evidence that rollback works for automation runs specifically.", "evidenceIds": [ "mintlify-docs-4", "mintlify-docs-5", "mintlify-docs-12", "mintlify-docs-17", "mintlify-docs-25", "mintlify-docs-56", "mintlify-docs-61" ] }, { "productId": "mintlify", "storyId": "ci-broken-link-checks", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The CLI docs mention that it lets you 'catch build errors before deploying to production' and PR preview deployments let reviewers see changes before merge, which implies some validation, but there's no explicit mention of automated CI pipeline integration, broken-link checking, or docs.json/config validation as a distinct CI step. missing for 10: explicit CI/CD integration docs (e.g., GitHub Actions), documented broken-link checker, and config schema validation output.", "evidenceIds": [ "mintlify-docs-11", "mintlify-docs-17", "mintlify-docs-16" ] }, { "productId": "mintlify", "storyId": "content-linting-style", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows CLI catches build errors and broken links, and editor/agent features, but nothing about linting content against a style guide (e.g., prose/style rules, terminology, tone checks) before publishing.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "custom-domain-subpath", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mintlify's docs explicitly support hosting at a custom domain, subdomain, or subpath with DNS/TLS handled, and this custom domain capability is also listed as a core Pro-tier feature on pricing. Missing for 10: independent/hands-on confirmation of subpath routing behavior beyond first-party docs.", "evidenceIds": [ "mintlify-docs-15", "mintlify-docs-33", "mintlify-docs-60" ] }, { "productId": "mintlify", "storyId": "docs-analytics", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify's analytics dashboard explicitly covers traffic (page views), assistant conversations, search queries, engagement, and reader feedback, directly matching the story; Enterprise tier adds 'Advanced insights.' missing for 10: no independent/hands-on corroboration of the analytics dashboard's usability or accuracy, and no detail on how feedback is captured or segmented by page.", "evidenceIds": [ "mintlify-docs-19", "mintlify-docs-37", "mintlify-docs-61" ] }, { "productId": "mintlify", "storyId": "docs-mcp-for-readers", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify explicitly documents a hosted Index/Search MCP server that exposes each published docs site for AI agents to search and retrieve content, and this is listed as a pricing-tier feature, confirming it's a real, shipped per-site capability rather than a roadmap item. Missing for 10: independent/hands-on verification that the MCP server works as described on a live customer site, and clarity on default-on vs opt-in status.", "evidenceIds": [ "mintlify-docs-7", "mintlify-docs-22", "mintlify-docs-43", "mintlify-docs-47", "mintlify-docs-60" ] }, { "productId": "mintlify", "storyId": "docs-versioning", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only hint of version support is a mention that Mintlify's in-product search can be filtered by 'product and version,' implying some notion of versioned content exists, but there is no documentation of creating multiple documentation versions, a version switcher UI, or how readers navigate between versions on the site. missing for 10: explicit docs on defining/publishing multiple versions, a reader-facing version switcher, and any hands-on confirmation that this works as described.", "evidenceIds": [ "mintlify-docs-20", "mintlify-docs-28", "mintlify-docs-38" ] }, { "productId": "mintlify", "storyId": "git-sync-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify is explicitly git-based: docs live in a repo, CLI enables local preview before commits, PR preview deployments let reviewers see changes before merge, and the editor supports reviewing/merging PRs directly. This is core to Mintlify's docs-as-code model. Missing for 10: independent/hands-on confirmation of the git workflow (only vendor docs), and no detail on branch-based environment mapping beyond PR previews.", "evidenceIds": [ "mintlify-docs-1", "mintlify-docs-11", "mintlify-docs-12", "mintlify-docs-17", "mintlify-docs-25" ] }, { "productId": "mintlify", "storyId": "instant-search-quality", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify docs confirm a built-in in-product search bar with relevance ranking (boost multipliers, chunk relevance scores) and configurable filters/result limits, indicating search ships out of the box and is tunable for relevance. However, there's no explicit documentation or evidence of typo-tolerance or fuzzy-matching, nor independent benchmarks of search speed/quality across a full site. Missing for 10: explicit typo-tolerance/fuzzy search claims, performance/speed evidence, and independent hands-on validation of search quality.", "evidenceIds": [ "mintlify-docs-20", "mintlify-docs-28", "mintlify-docs-38" ] }, { "productId": "mintlify", "storyId": "interactive-api-playground", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify docs explicitly describe generating interactive API documentation from OpenAPI specs with request builders and an 'API playground' feature listed as a platform capability, and use-case docs explicitly mention an 'API playground where users' can try calls. Missing for 10: independent/hands-on verification that real live API calls succeed against actual servers, and more detail on auth/credential handling within the playground.", "evidenceIds": [ "mintlify-docs-14", "mintlify-docs-50", "mintlify-docs-51", "mintlify-docs-60", "mintlify-docs-32" ] }, { "productId": "mintlify", "storyId": "llms-txt-generated", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mintlify docs explicitly state it auto-generates llms.txt and llms-full.txt for published sites, structured as a file hierarchy so agents can traverse without loading the whole index, and this is independently confirmed by a live probe returning HTTP 200 at mintlify.com/llms.txt. missing for 10: no probe confirmation of the llms-full.txt variant specifically (only llms.txt was probed).", "evidenceIds": [ "mintlify-docs-6", "mintlify-docs-59", "mintlify-probe-1" ] }, { "productId": "mintlify", "storyId": "localization-i18n", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Mintlify's docs.json config, CLI, editor, deployment, analytics, search, and AI features extensively, but there is no mention anywhere of multi-language/localization support, translated navigation, or i18n content structures.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "md-mirror-endpoints", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify explicitly documents that appending `.md` to any page's URL returns a clean Markdown version for AI/LLM consumption, positioned as a first-class agent-facing feature alongside llms.txt and skill.md. The 404 probe was against the marketing site's root docs.md, not an actual customer documentation page URL with .md appended, so it doesn't concretely contradict the documented per-page behavior. Missing for 10: independent hands-on verification on a live customer docs site confirming the .md suffix works as described.", "evidenceIds": [ "mintlify-docs-9", "mintlify-docs-23", "mintlify-docs-45", "mintlify-docs-6", "mintlify-probe-1" ] }, { "productId": "mintlify", "storyId": "mdx-components-authoring", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Mintlify's editor, CLI, docs.json config, OpenAPI generation, and AI agent features, but nowhere mentions MDX component authoring or built-in rich components like tabs, callouts, code groups, or steps used without custom HTML. Missing for 10: any documentation of MDX component library, callout/tab/code-group syntax examples, or component authoring guides.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "openapi-reference-generation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify docs explicitly describe generating interactive API reference pages from OpenAPI spec files with automatic endpoint pages, request builders, and navigation, and marketing/use-case docs state pages are \"updated every time it changes\" from the spec you maintain. This directly matches the story of spec-driven, sync-on-change API reference generation. Missing for 10: independent/hands-on verification of automatic re-sync behavior beyond vendor docs, and detail on how sync is triggered (webhook vs CLI vs CI).", "evidenceIds": [ "mintlify-docs-14", "mintlify-docs-50", "mintlify-docs-51" ] }, { "productId": "mintlify", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mintlify offers a REST API for deployments, analytics, and assistant embedding, plus an admin MCP server giving AI tools write access to edit pages, update settings, and open PRs — covering much of what the UI/editor does. However, the OpenAPI spec for the API itself is not discoverable (probe returned 404 on all candidate paths), and some editor-only capabilities (e.g., in-editor commenting/suggestions, live preview UI) aren't clearly exposed as discrete API operations, leaving parity unproven for the full UI feature set. missing for 10: published/discoverable OpenAPI spec for the REST API, explicit API-level parity documentation for editor-only actions like commenting/navigation reorg, independent verification that all UI actions map to API/MCP calls.", "evidenceIds": [ "mintlify-docs-8", "mintlify-docs-21", "mintlify-docs-13", "mintlify-docs-26", "mintlify-probe-3", "mintlify-probe-4" ] }, { "productId": "mintlify", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs content is authored in Markdown/MDX and lives in the user's own Git repo, and Mintlify explicitly supports exporting clean Markdown per page ([mintlify-docs-9],[mintlify-docs-23]) plus a self-host option ([mintlify-docs-18]), all reducing lock-in for the core documentation content. However, evidence only covers migrating *to* Mintlify from other platforms ([mintlify-docs-54]), not exporting non-content data (analytics, assistant conversation logs, settings) or a documented 'leave' path, and Mintlify is confirmed not open-source with proprietary backend features ([mintlify-comm-1]). Missing for 10: full data export (analytics/assistant history/config) in open formats, documented process for migrating away from Mintlify, and independent confirmation of no lock-in beyond content markdown.", "evidenceIds": [ "mintlify-docs-9", "mintlify-docs-23", "mintlify-docs-18", "mintlify-docs-54", "mintlify-comm-1" ] }, { "productId": "mintlify", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No vendor documentation claims Mintlify's source is available under an open license; community evidence explicitly states the opposite — 'Mintlify is not open source: the license restricts the backend enterprise features to source-available only' and it is 'pure SaaS.' There is no CLI, repo, or license evidence supporting open-source access to Mintlify's own source code.", "evidenceIds": [ "mintlify-comm-1", "mintlify-comm-3" ] }, { "productId": "mintlify", "storyId": "openness-self-host", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Vendor docs explicitly describe running Mintlify in your own cloud/on-prem (AWS or any Kubernetes platform) as a supported deployment mode, which would satisfy self-hosting the core product. However, independent community reports directly contradict this framing, describing Mintlify as 'pure SaaS' unsuitable for regulated environments and noting the product is not open source (only source-available for enterprise backend features), suggesting genuine self-hosting is either unavailable, gated, or not as advertised for most users. Missing for 10: clear evidence self-hosting is broadly available (not enterprise-sales-gated), independent confirmation of a successful self-hosted deployment, and resolution of the open-source/source-available licensing tension.", "evidenceIds": [ "mintlify-docs-18", "mintlify-docs-36", "mintlify-comm-1", "mintlify-comm-3" ] }, { "productId": "mintlify", "storyId": "preview-deployments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mintlify explicitly documents per-PR preview deployments with unique preview URLs so reviewers can view doc changes before merging (mintlify-docs-17, -35, -49), plus editor-based preview-then-merge workflow (mintlify-docs-12/25) and CLI local preview (mintlify-docs-11/29). Missing for 10: independent/hands-on confirmation of the preview-URL workflow in practice and detail on how previews integrate with GitHub PR checks/comments.", "evidenceIds": [ "mintlify-docs-17", "mintlify-docs-35", "mintlify-docs-49", "mintlify-docs-12", "mintlify-docs-25", "mintlify-docs-11" ] }, { "productId": "mintlify", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of data residency/region selection controls; self-hosting on own cloud (mintlify-docs-18/36) offers infrastructure control but is not a documented data-residency/region-choice feature, and enterprise security items don't mention residency options.", "evidenceIds": [ "mintlify-docs-18", "mintlify-docs-61" ] }, { "productId": "mintlify", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses opting out of AI training data usage, data privacy controls, or a training-data policy; evidence instead covers documentation/AI feature functionality and unrelated security incidents. Missing for 10: any documented privacy policy, opt-out mechanism, or contractual terms about AI training data use.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item addresses data retention policies, deletion controls, or data lifecycle management for user/customer data; security-related community complaints (token storage, GitHub permissions) touch security concerns but not retention/deletion controls specifically. This axis clearly applies to a SaaS documentation platform handling customer content, so absence of evidence yields 'none'.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item mentions telemetry opt-out or usage-tracking controls; analytics dashboard is documented but only as a feature to view traffic/engagement, not as something users can disable. Community items raise general privacy/security concerns (e.g., token storage, monitoring gaps) but don't address a telemetry opt-out mechanism specifically.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "reusable-content-snippets", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention reusable snippets, reusable components, or variables/placeholders for keeping repeated content in sync across pages; docs.json covers global site config, not content-level snippets/variables. Absence of evidence for this applicable authoring capability yields none.", "evidenceIds": [] }, { "productId": "mintlify", "storyId": "review-change-requests", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify's editor and Git-based workflow support PR-style review: preview URLs per pull request, comments/suggestions from the AI agent, and approve-and-merge from within the editor before publishing (mintlify-docs-12, mintlify-docs-17, mintlify-docs-25, mintlify-docs-26). This covers comments, preview/approval, and merge steps gating publication. missing for 10: independent/hands-on confirmation of the review UI in practice, and explicit documentation of multi-reviewer approval gating (e.g., required approvers) beyond generic PR/merge mechanics.", "evidenceIds": [ "mintlify-docs-12", "mintlify-docs-17", "mintlify-docs-25", "mintlify-docs-26", "mintlify-docs-13" ] }, { "productId": "mintlify", "storyId": "static-export-portability", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mintlify offers self-hosting on your own cloud/Kubernetes and per-page Markdown export, which mitigate some lock-in, but there is no documented feature to export the entire site as a portable static bundle usable on arbitrary hosting outside Mintlify's runtime. Community commentary also flags Mintlify as proprietary/SaaS-locked (not open-source, backend not portable). Missing for 10: a documented 'export static site' or 'build to static HTML' command, confirmation that self-host doesn't require Mintlify's proprietary backend, and independent verification of portability.", "evidenceIds": [ "mintlify-docs-18", "mintlify-docs-36", "mintlify-docs-9", "mintlify-docs-23", "mintlify-comm-1", "mintlify-comm-2", "mintlify-comm-3" ] }, { "productId": "mintlify", "storyId": "theming-brand-customization", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "docs.json is documented as the central config controlling 'visual branding, navigation structure' etc., which supports theme/font/layout customization, but the evidence pack never mentions custom CSS/JS injection or embedding custom React/UI components for deeper brand control. Missing for 10: explicit documentation of custom CSS/JS support, custom component embedding, and independent confirmation that deep branding beyond docs.json settings is possible.", "evidenceIds": [ "mintlify-docs-16", "mintlify-docs-27", "mintlify-docs-15" ] }, { "productId": "mintlify", "storyId": "wysiwyg-web-editor", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mintlify's web editor lets teammates edit pages, preview changes, and open/merge pull requests without touching git directly, with changes flowing into the same repo-backed source of truth (docs.json, git repo) used by developers via CLI/git workflow. Docs explicitly describe editing, previewing, commenting, and merging PRs from within the editor UI. Missing for 10: no independent/hands-on account confirming non-technical teammates successfully use it without any git knowledge, and no detail on permission/collaboration controls for non-technical users.", "evidenceIds": [ "mintlify-docs-1", "mintlify-docs-12", "mintlify-docs-13", "mintlify-docs-25", "mintlify-docs-26", "mintlify-docs-60" ] }, { "productId": "readme", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "ReadMe hosts a verified llms.txt at docs.readme.com/llms.txt (probe confirms HTTP 200) plus per-page .md access, dedicated llms.txt-style docs for customizing/writing/workflows/ai sections, an Agent-Friendly Docs scoring feature (ai-discoverability), and an official MCP server giving agents live access to API specs and docs. missing for 10: independent/hands-on third-party confirmation that an external agent successfully consumes the llms.txt content end-to-end (only first-party docs and one probe corroborate this).", "evidenceIds": [ "readme-probe-1", "readme-docs-65", "readme-docs-31", "readme-docs-64", "readme-docs-39", "readme-docs-44", "readme-docs-49", "readme-probe-2" ] }, { "productId": "readme", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe offers AI-generated insights within the product itself: the AI Linter/Docs Audit checks content against natural-language rules, the AI Agent and Inline AI can draft/rewrite/enhance content, and Ask AI surfaces answers from docs; API/MCP Metrics also surface usage insights though these are analytics dashboards rather than AI-generated suggestions. However, evidence is entirely vendor documentation with no independent/hands-on validation of the AI suggestions' quality or accuracy. missing for 10: independent/hands-on evidence of AI insight quality, examples of AI-generated suggestions in practice, and confirmation that analytics (metrics) include AI-driven interpretation rather than raw charts.", "evidenceIds": [ "readme-docs-6", "readme-docs-7", "readme-docs-18", "readme-docs-19", "readme-docs-49", "readme-docs-51", "readme-docs-52", "readme-docs-28", "readme-docs-9" ] }, { "productId": "readme", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The GitHub AI Writer feature watches pull requests in the background and autonomously proposes documentation updates when code changes affect docs (readme-docs-8), which is the only evidence of a background automation. However, this is a single fixed integration (not a general automation framework), still requires human review/approval before changes go live (readme-docs-12/27), and there's no evidence of user-configurable autonomous background jobs, schedules, or triggers beyond this one PR-watching feature.\n\nmissing for 10: general-purpose automation/workflow builder, evidence of fully unattended (no-approval) execution, multiple autonomous background triggers beyond PR-watching, independent confirmation of autonomy in practice.", "evidenceIds": [ "readme-docs-8", "readme-docs-12", "readme-docs-27" ] }, { "productId": "readme", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe ships an in-product 'Agent' documentation assistant that creates, edits, and enhances content across Guides, API References, and Custom Pages, plus inline AI editing via natural-language prompts — a genuine built-in AI assistant users can delegate documentation tasks to. However, this is scoped to docs authoring/editing tasks, not general task delegation, and there's no independent/hands-on corroboration of the Agent's reliability or scope beyond vendor docs. missing for 10: independent or hands-on verification of the Agent's capabilities and limits, evidence of broader task delegation beyond content editing, and any community feedback on the Agent feature specifically.", "evidenceIds": [ "readme-docs-18", "readme-docs-19" ] }, { "productId": "readme", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe ships an official CLI (rdme) and a documented REST API for controlling docs programmatically, both of which support headless/CI automation (e.g., syncing OpenAPI specs in pipelines). However, the evidence pack lacks explicit CI/CD workflow examples, headless-mode documentation, or community confirmation of CI usage. Missing for 10: explicit CI pipeline examples/docs, headless-mode guarantees, and independent confirmation of automated CLI/API use in production pipelines.", "evidenceIds": [ "readme-probe-3", "readme-docs-87", "readme-docs-44" ] }, { "productId": "readme", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All MCP-related evidence describes ReadMe publishing its own MCP server so external AI coding assistants (Cursor, Claude Code, VS Code Copilot) can call ReadMe's API/docs tools (readme-docs-3, readme-docs-34, readme-probe-2) — this is the server role, the opposite of what the story asks. There is no evidence that ReadMe's own AI features (Ask AI, AI Agent, GitHub AI Writer) can connect to and consume external MCP servers as a client.", "evidenceIds": [ "readme-docs-3", "readme-docs-34", "readme-probe-2", "readme-docs-18" ] }, { "productId": "readme", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe documents an official, project-specific MCP server that gives AI coding assistants (Cursor, Claude Code, VS Code Copilot) a live connection to API specs/docs, backed by dedicated MCP metrics/analytics and confirmed live via probe. missing for 10: independent/hands-on third-party verification that the MCP connection works as described beyond first-party docs.", "evidenceIds": [ "readme-docs-3", "readme-docs-34", "readme-docs-9", "readme-docs-30", "readme-docs-78", "readme-probe-2" ] }, { "productId": "readme", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe's Agent and Inline AI let users edit and enhance docs content via plain-language prompts, and the Linter lets you define documentation rules in natural language, showing genuine NL-driven operation of core content-editing workflows. However, this is scoped to content editing rather than full product operation (e.g., configuring project settings, analytics, or publishing via NL commands), and there's no independent/hands-on corroboration beyond first-party docs. Missing for 10: evidence of NL control over broader product functions (settings, analytics, admin tasks) and independent verification of the Agent/Inline AI working as described.", "evidenceIds": [ "readme-docs-18", "readme-docs-19", "readme-docs-6" ] }, { "productId": "readme", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "ReadMe does maintain an official CLI (rdme) per the GitHub probe, confirming the capability exists, but the evidence pack contains no first-party documentation detailing the CLI's commands, AI-native workflow support, or independent corroboration of its use. missing for 10: detailed CLI docs/feature list, AI-native workflow examples, independent/hands-on usage confirmation.", "evidenceIds": [ "readme-probe-3" ] }, { "productId": "readme", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "ReadMe documents a full public API ('Control your docs programmatically with the ReadMe API') plus a companion developer-metrics API and an open-source CLI (rdme) that wraps it, giving AI-native users a documented, scriptable interface to drive the product. missing for 10: independent/hands-on confirmation that the API works as documented and more detail on API reference completeness beyond the one-line docs mention.", "evidenceIds": [ "readme-docs-87", "readme-docs-92", "readme-probe-3", "readme-probe-1" ] }, { "productId": "readme", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While ReadMe exposes an MCP server and a general ReadMe API, the evidence pack contains no mention of issuing scoped or least-privilege API credentials specifically for AI agents (e.g., agent-specific API keys, permission scopes, or token restrictions) — only general API key injection for docs personalization and generic API access control.", "evidenceIds": [] }, { "productId": "readme", "storyId": "agentic-sdks", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "ReadMe documents a public REST API and an official CLI (rdme) that developers can build against programmatically, but there is no evidence of dedicated official client SDKs in multiple languages (e.g., Python, Node, Go) for integrating with the ReadMe platform itself — 'Pick a language' refers to code-sample generation for the API reference of the docs being hosted, not an SDK for ReadMe. Missing for 10: explicit official multi-language SDKs, independent/hands-on validation of SDK quality, and clear API-vs-SDK distinction.", "evidenceIds": [ "readme-docs-87", "readme-probe-3", "readme-docs-2" ] }, { "productId": "readme", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "ReadMe is an API documentation/hub platform; webhooks-as-a-subscription-mechanism for events is not part of its product category (it offers MCP servers, API references, and docs tooling, not an event/webhook subscription system). No evidence pack items address webhook subscriptions, so this axis is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "readme", "storyId": "ai-agent-maintains-docs", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "ReadMe documents an AI Agent that drafts/edits content from natural-language prompts (readme-docs-18, readme-docs-19), a GitHub AI Writer that watches PRs and proposes doc updates when code changes (readme-docs-8, readme-docs-53), and a Reviews/branches workflow where changes are held until approved (readme-docs-12, readme-docs-27, readme-docs-45, readme-docs-70) — functioning like change requests. However there is no evidence of a schedule-triggered agent run, and it's unclear whether GitHub AI Writer output surfaces as an actual GitHub pull request versus an internal ReadMe branch/review. Missing for 10: schedule-based trigger evidence, and explicit confirmation that agent output is submitted as a GitHub PR/change request rather than only an internal review branch.", "evidenceIds": [ "readme-docs-18", "readme-docs-19", "readme-docs-8", "readme-docs-53", "readme-docs-12", "readme-docs-27", "readme-docs-45", "readme-docs-70", "readme-docs-44" ] }, { "productId": "readme", "storyId": "ai-assistant-on-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe's 'Ask AI' feature is documented as giving readers instant answers from published documentation directly inside the hub, matching the core story of an embedded assistant answering questions from docs content, but the evidence never confirms it surfaces explicit citations/links into specific content, and there's no independent or hands-on verification of this behavior. missing for 10: explicit documentation or proof that Ask AI cites/links specific source pages, independent/community confirmation of citation quality.", "evidenceIds": [ "readme-docs-4" ] }, { "productId": "readme", "storyId": "ai-traffic-analytics", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe's MCP Metrics page explicitly tracks calls made by AI agents/clients to a project's MCP server (calls, latency, failures, per-tool breakdown), which functions as dedicated AI-agent-traffic analytics distinct from human page-view metrics. However, this only covers MCP tool-call traffic, not a unified dashboard that tags/distinguishes AI crawlers or AI agent readers from human visitors across regular docs page views and API Metrics. Missing for 10: evidence of AI-vs-human classification within general docs pageview/API Metrics (not just MCP), and any UI showing side-by-side human vs agent traffic breakdown.", "evidenceIds": [ "readme-docs-9", "readme-docs-30", "readme-docs-36", "readme-docs-78", "readme-docs-28", "readme-docs-73" ] }, { "productId": "readme", "storyId": "api-interactive-docs", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "ReadMe's docs explicitly describe an interactive API reference where developers can make test calls and see real responses without writing code, backed by OpenAPI upload/management for generating that reference, and community feedback corroborates strong API reference/Swagger support versus alternatives. missing for 10: independent hands-on validation specifically of the 'runnable examples' UX (only vendor docs cited) and no direct AI-native user testimonial trying the runnable examples.", "evidenceIds": [ "readme-docs-1", "readme-docs-23", "readme-comm-7" ] }, { "productId": "readme", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence documents ReadMe's ability to upload/manage an OpenAPI spec to generate docs (readme-docs-23) and export docs/PDF files (readme-docs-13/29), but there is no evidence of a feature letting a user download the underlying OpenAPI spec (JSON/YAML) as a machine-readable artifact. Missing for 10: any documented spec-download endpoint, export-as-OpenAPI option, or explicit machine-readable API spec retrieval capability.", "evidenceIds": [ "readme-docs-23", "readme-docs-13", "readme-docs-29" ] }, { "productId": "readme", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "ReadMe's API Reference lets users make live test calls against real APIs (readme-docs-1, readme-docs-15), but no evidence describes a distinct sandbox/staging environment isolated from production data — the docs explicitly describe 'real responses,' implying production calls rather than a sandboxed test environment.", "evidenceIds": [ "readme-docs-1", "readme-docs-15" ] }, { "productId": "readme", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows ReadMe offers a 'Versions' feature for customers' own API docs (readme-docs-17, 48, 69) and exposes its own ReadMe API for programmatic control (readme-docs-87), but there is no documentation of a versioning scheme or deprecation policy for ReadMe's own API/product that an AI-native consumer could rely on.", "evidenceIds": [ "readme-docs-17", "readme-docs-48", "readme-docs-69", "readme-docs-87" ] }, { "productId": "readme", "storyId": "authenticated-docs-access", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers SSO only for internal Teammates sign-in (readme-docs-84) and admin permission control (readme-docs-63), but nothing describes gating published customer-facing docs behind password, JWT, or SSO authentication for readers/customers. missing for 10: reader-facing password protection, JWT-based authenticated docs, SSO gating for external customers viewing docs.", "evidenceIds": [ "readme-docs-84", "readme-docs-63" ] }, { "productId": "readme", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "ReadMe offers a Docs Audit that runs Linter rules across every page in one pass (readme-docs-7, readme-docs-25, readme-docs-52) and an rdme CLI plus ReadMe API for programmatic control (readme-docs-87, readme-probe-3), which enable some bulk-style operations across many docs/pages. However there's no direct evidence of bulk operations across arbitrary 'items' (e.g., batch endpoint edits, bulk publish/delete, bulk API reference updates) beyond the audit/linter and CLI/API scripting potential. missing for 10: explicit bulk edit/publish/delete UI or API examples, documented batch size/limits, independent hands-on confirmation of bulk workflows succeeding at scale.", "evidenceIds": [ "readme-docs-7", "readme-docs-25", "readme-docs-52", "readme-docs-87", "readme-probe-3" ] }, { "productId": "readme", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "ReadMe offers linting rules, GitHub sync, and AI writer proposals, but these are triggered by manual runs or PR events for documentation maintenance, not a general-purpose 'define rules that trigger arbitrary actions on events' automation engine for AI-native users. No evidence of a rules/automation/webhook engine letting users define custom event-triggered actions. missing for 10: an event-trigger/automation rules engine, webhook or conditional action framework, evidence of user-defined triggers beyond docs linting/sync.", "evidenceIds": [ "readme-docs-6", "readme-docs-7", "readme-docs-8", "readme-docs-26" ] }, { "productId": "readme", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "ReadMe is a documentation/API-hub platform, not a workflow/job-scheduling or automation-orchestration product; scheduling recurring jobs or workflows is outside its product category and not evidenced anywhere in the pack.", "evidenceIds": [] }, { "productId": "readme", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "ReadMe supports versioning of docs content (readme-docs-17), review workflows with AI Linter/teammate approval (readme-docs-12, readme-docs-27), and bi-directional git sync (readme-docs-26) which implicitly enables rollback via git history for AI-driven changes like the GitHub AI Writer's proposed updates (readme-docs-8). However, none of this is framed specifically around 'automations' as a distinct object with version/review/rollback controls — it's inferred from general docs versioning and git integration rather than a dedicated automation-management feature. Missing for 10: an explicit rollback mechanism/UI for AI Agent or automation actions, direct evidence connecting review/versions to 'automations' specifically, and independent corroboration of this workflow in practice.", "evidenceIds": [ "readme-docs-17", "readme-docs-12", "readme-docs-27", "readme-docs-26", "readme-docs-8" ] }, { "productId": "readme", "storyId": "ci-broken-link-checks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "ReadMe's docs mention Docs Audit/Linter for style/broken-link checks and Reviews as a manual approval gate, and bi-directional sync with Git, but there is no evidence of a CI pipeline check (e.g., rdme CLI command or GitHub Action) that validates links/config and blocks a publish/merge automatically before the site goes live. missing for 10: evidence of an automated CI/CD integration (CLI command or GitHub Action) that runs link/config validation and fails the build pre-publish, and any confirmation that Docs Audit/Linter can be invoked as a CI gate rather than a manual dashboard action.", "evidenceIds": [ "readme-docs-7", "readme-docs-25", "readme-docs-27", "readme-docs-45", "readme-probe-3" ] }, { "productId": "readme", "storyId": "content-linting-style", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "ReadMe's Linter lets writers define natural-language style rules (e.g., 'Use active voice') that check every page, and Docs Audit runs those rules across the whole site to flag outdated content, broken links, and style inconsistencies before publishing; Reviews also let content be checked with the AI Linter before going live. missing for 10: independent/hands-on evidence of linting accuracy, no detail on pre-publish blocking/gating enforcement, and no third-party corroboration of the feature working in practice.", "evidenceIds": [ "readme-docs-6", "readme-docs-7", "readme-docs-25", "readme-docs-51", "readme-docs-52", "readme-docs-12" ] }, { "productId": "readme", "storyId": "custom-domain-subpath", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe's docs explicitly cover custom domain setup with CNAME, apex vs subdomain, and SSL certificates, framed as making docs 'polished and professional' on a company domain, which directly matches the custom-domain part of the story; the /docs subpath scenario is implicitly covered via apex/subdomain configuration options. Missing for 10: explicit first-party or independent confirmation of serving docs specifically as a path-based /docs subpath (vs subdomain) on the main domain.", "evidenceIds": [ "readme-docs-22", "readme-docs-41", "readme-docs-72" ] }, { "productId": "readme", "storyId": "docs-analytics", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "ReadMe documents Docs/API Metrics Charts and a Developer Metrics API that show 'how people use your docs and how developers use your API' (page views/usage), and Suggest in GitHub lets readers flag typos or share feedback, giving DevRel leads usage and feedback signals. However, there is no explicit documentation of search-term tracking/analytics, and no independent or hands-on evidence validating the depth or accuracy of these analytics dashboards. Missing for 10: explicit search-query/search-term analytics, quantified reader feedback/ratings dashboard, independent corroboration of the metrics feature's usefulness.", "evidenceIds": [ "readme-docs-28", "readme-docs-73", "readme-docs-92", "readme-docs-5", "readme-docs-20", "readme-docs-47" ] }, { "productId": "readme", "storyId": "docs-mcp-for-readers", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe documents a per-project MCP server that gives AI agents/coding assistants a live connection to the API spec and docs, with dedicated analytics tracking every tool call made by AI clients, matching the story of an exposed queryable MCP server. missing for 10: no independent/hands-on confirmation of query quality or third-party agent testing, and no detail on search-specific tool schemas beyond general spec/doc access.", "evidenceIds": [ "readme-docs-3", "readme-docs-34", "readme-docs-77", "readme-docs-9", "readme-docs-30", "readme-docs-36", "readme-probe-2" ] }, { "productId": "readme", "storyId": "docs-versioning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "ReadMe's docs explicitly state that maintaining multiple versions of documentation is a supported, important feature (readme-docs-17), confirming per-product/API version publishing capability. However, the evidence pack contains no detail on the actual version-switcher UI or reader-facing mechanism for switching versions from the site, nor any independent/community confirmation of this workflow. Missing for 10: documentation or screenshots of the reader-facing version switcher, confirmation of how versions map to distinct URLs/hubs, and independent corroboration that readers can toggle versions seamlessly.", "evidenceIds": [ "readme-docs-17" ] }, { "productId": "readme", "storyId": "git-sync-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe supports bi-directional GitHub/GitLab/Bitbucket sync, git-based workflows with Markdown/OpenAPI in-repo, pull requests as the review step, and branch-based review before publishing (readme-docs-26, readme-docs-44, readme-docs-45, readme-docs-46, readme-docs-67, readme-docs-70, readme-docs-68). This directly matches docs-as-code with branches/PRs/merges driving publishing. missing for 10: independent/hands-on confirmation of the git-sync workflow in practice (community evidence is thin/tangential) and more detail on merge conflict handling.", "evidenceIds": [ "readme-docs-26", "readme-docs-44", "readme-docs-45", "readme-docs-46", "readme-docs-67", "readme-docs-68", "readme-docs-70" ] }, { "productId": "readme", "storyId": "instant-search-quality", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Ask AI (AI-generated answers from docs) and MCP/agent discoverability features, but contains no mention of a traditional full-text search index, typo-tolerance, or relevance ranking for the docs site itself. Search-discovery via a classic search bar is a plausible axis for a docs platform, but no evidence confirms it delivers fast, typo-tolerant, relevance-ranked search out of the box.", "evidenceIds": [ "readme-docs-4", "readme-docs-35", "readme-docs-10" ] }, { "productId": "readme", "storyId": "interactive-api-playground", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "ReadMe's docs explicitly describe an interactive API reference where developers can make real test calls and see actual responses without writing code, and independent community feedback corroborates ReadMe's strong Swagger/OpenAPI-based reference experience. Missing for 10: independent hands-on confirmation specifically of the try-it-out call execution (vs. general praise) and details on auth/key injection during live calls.", "evidenceIds": [ "readme-docs-1", "readme-docs-23", "readme-comm-7" ] }, { "productId": "readme", "storyId": "llms-txt-generated", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A direct probe confirms docs.readme.com serves a live llms.txt (HTTP 200) that also documents a full-content variant via appending .md to any page URL — matching the story's ask exactly. This is reinforced by ReadMe's own docs being organized under numerous /llms.txt paths (e.g. customizing-docs/llms.txt, workflows/llms.txt, ai/llms.txt) and a dedicated 'AI Discoverability' feature (readme-docs-10/31/65) that scores published docs against an 'Agent-Friendly Docs spec,' indicating llms.txt generation is a first-class, cross-project capability rather than a one-off. Missing for 10: explicit first-party confirmation that llms.txt is auto-generated for arbitrary customer-published hubs (not just docs.readme.com itself), and independent/community corroboration of this specific feature.", "evidenceIds": [ "readme-probe-1", "readme-docs-10", "readme-docs-31", "readme-docs-65", "readme-docs-33", "readme-docs-39" ] }, { "productId": "readme", "storyId": "localization-i18n", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of multi-language documentation publishing, translated navigation, or i18n/localization features; 'Pick a language' (readme-docs-2) refers to code-sample language selection, not content localization. Versioning docs (readme-docs-17, readme-docs-48) address content versions, not language translation.", "evidenceIds": [] }, { "productId": "readme", "storyId": "md-mirror-endpoints", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "A direct probe of ReadMe's own docs site confirms the .md URL pattern works ('Append .md to any documentation page URL to...'), and ReadMe's AI-discoverability feature explicitly scores published customer pages against an 'Agent-Friendly Docs spec,' indicating this is a platform-wide capability, not just ReadMe's own site. Missing for 10: independent confirmation on a customer-hosted docs hub (not just docs.readme.com), third-party corroboration of the .md behavior across arbitrary published projects.", "evidenceIds": [ "readme-probe-1", "readme-docs-10", "readme-docs-31", "readme-docs-65", "readme-docs-79" ] }, { "productId": "readme", "storyId": "mdx-components-authoring", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "ReadMe documents Markdown/MDX authoring with JSX syntax support (readme-docs-42, 81) and slash-command Mermaid diagrams (readme-docs-60), plus reusable Markdown blocks (readme-docs-24, 43), which supports building rich pages without raw HTML. However, the evidence never explicitly names built-in components like tabs, callouts, code groups, or step lists — only MDX/JSX generically and diagrams. Missing for 10: explicit documentation of tabs/callout/code-group/step components, and independent/hands-on confirmation of their availability.", "evidenceIds": [ "readme-docs-42", "readme-docs-81", "readme-docs-60", "readme-docs-24", "readme-docs-43", "readme-docs-88" ] }, { "productId": "readme", "storyId": "openapi-reference-generation", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "ReadMe explicitly supports transforming an OpenAPI spec into interactive API reference docs (readme-docs-23), documents accepted OpenAPI versions/file types (readme-docs-32), and offers Git-based workflows to manage API definitions in source control with docs updating from spec changes (readme-docs-44, readme-docs-68). Independent community feedback also notes ReadMe's strong Swagger/OpenAPI support relative to alternatives (readme-comm-7). Missing for 10: no first-party or independent evidence detailing automatic re-sync behavior when the spec file is updated post-publish (e.g., webhook/CI-triggered re-ingestion) or hands-on confirmation of staying in sync over time.", "evidenceIds": [ "readme-docs-23", "readme-docs-32", "readme-docs-44", "readme-docs-68", "readme-comm-7" ] }, { "productId": "readme", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe documents a full ReadMe API for programmatic control (readme-docs-87) plus an official CLI (rdme, readme-probe-3) and bi-directional GitHub/GitLab sync (readme-docs-26/46), suggesting most content, versioning, and docs management actions can be done via API/CLI/Git instead of the UI. However, the evidence doesn't confirm parity for every UI feature (e.g., Reviews approval workflows, Linter/Docs Audit runs, custom CSS/domain setup, Analytics/metrics views) being fully scriptable via the API, and no independent confirmation of full UI/API parity exists. missing for 10: explicit API/CLI equivalents for Reviews, Linter/Docs Audit, Analytics dashboards, and custom domain/CSS configuration, plus independent verification of full parity.", "evidenceIds": [ "readme-docs-87", "readme-probe-3", "readme-docs-26", "readme-docs-46", "readme-docs-44", "readme-docs-68" ] }, { "productId": "readme", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "ReadMe supports exporting docs files or PDF from the Branch menu, giving some data portability, but this is limited to documentation content and PDF/file export, not a full open-format export of all underlying data (API metrics, analytics, custom pages, versions, reusable content blocks) in machine-readable open formats like JSON/Markdown source. missing for 10: evidence of exporting all account/project data (metrics, settings, versions) in open formats, confirmation of underlying file format (e.g., raw Markdown vs proprietary), and independent/hands-on confirmation of a full data export and migration path away from ReadMe.", "evidenceIds": [ "readme-docs-13", "readme-docs-29" ] }, { "productId": "readme", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "ReadMe is a closed, proprietary SaaS documentation platform; there is no evidence of its core product source being released under an open license (only a CLI tool 'rdme' is open-source, not the product itself). No evidence supports an open-license source availability for the platform.", "evidenceIds": [] }, { "productId": "readme", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "ReadMe is a SaaS-only hosted documentation platform; there is no evidence of a self-hostable core product, Docker image, or on-prem deployment option. Community evidence even shows a user switching to open-source Docusaurus specifically to avoid ReadMe's hosted costs, and a request for an open-source-friendly plan went unmet, further indicating no self-hosting path exists.", "evidenceIds": [ "readme-comm-1", "readme-comm-6" ] }, { "productId": "readme", "storyId": "preview-deployments", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence describes per-PR shareable preview deployments of docs; ReadMe's docs-as-code features cover bi-directional sync, Reviews (AI Linter/teammate approval), and branch-based exports, but nothing indicates an automatic preview URL generated for each pull request before merge.", "evidenceIds": [] }, { "productId": "readme", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, regional storage selection, or data location controls for ReadMe; the docs cover editing, MCP, analytics, and customization but never data-residency options.", "evidenceIds": [] }, { "productId": "readme", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data opt-out or any data-privacy controls related to AI model training; ReadMe's docs cover documentation/AI-assistant features but not this privacy posture.", "evidenceIds": [] }, { "productId": "readme", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers documentation authoring, MCP server setup, AI writing tools, and content export/versioning, but nothing addresses data retention policies or user-controlled deletion of stored data (e.g., MCP call logs, Ask AI query history, or account data). Analytics features like MCP Metrics explicitly record every AI tool call, but no docs describe retention windows or deletion controls for that data.", "evidenceIds": [ "readme-docs-9", "readme-docs-30", "readme-docs-36", "readme-docs-38" ] }, { "productId": "readme", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry or usage-tracking opt-out settings for ReadMe; nothing describes data collection controls or privacy toggles. Missing for 10: any documentation of telemetry practices, an opt-out mechanism, or privacy settings related to usage tracking.", "evidenceIds": [] }, { "productId": "readme", "storyId": "reusable-content-snippets", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe's Reusable Content feature lets admins create Markdown blocks reused across multiple pages, with edits automatically propagating to every instance ('Edit once, update everywhere'), directly matching the snippet-sync story; variables are less explicitly documented separately. missing for 10: dedicated documentation/example of a distinct 'variables' feature (vs. reusable Markdown blocks) and independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "readme-docs-16", "readme-docs-24" ] }, { "productId": "readme", "storyId": "review-change-requests", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "ReadMe's Reviews feature explicitly supports pre-publish approval workflows — teammates can check changes for issues or get approval before they go live, and the branch-based model (Branch menu) implies a merge-into-main step. However, the evidence never explicitly mentions inline comments/discussion threads, only 'approval' and 'AI Linter' checks, and there's no dedicated documentation of the merge action itself. Missing for 10: explicit comment/discussion functionality within reviews, and clear documentation of the merge step that finalizes publishing.", "evidenceIds": [ "readme-docs-12", "readme-docs-27", "readme-docs-26", "readme-docs-13" ] }, { "productId": "readme", "storyId": "static-export-portability", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "ReadMe docs mention exporting files or a PDF from the Branch menu, which shows some content-export capability, but there is no evidence of exporting the entire docs site as a deployable static bundle (with API reference, navigation, styling, etc.) that can be self-hosted elsewhere — the product is fundamentally a hosted SaaS platform. missing for 10: full static-site export/bundle, documentation of self-hosting elsewhere, independent confirmation that exported files constitute a complete replica of the hosted site.", "evidenceIds": [ "readme-docs-13", "readme-docs-29" ] }, { "productId": "readme", "storyId": "theming-brand-customization", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "ReadMe's docs explicitly cover theme presets with brand color/typography tuning, custom CSS (variables or raw rules), custom JavaScript and include tags, custom domain/SSL, and MDX support for custom components, directly matching the DevRel branding customization story. A community testimonial (Heap Analytics) also corroborates the visual customization experience in practice. Missing for 10: independent/hands-on verification of deep custom-JS/component work beyond vendor docs, and no evidence of a fully custom component framework beyond MDX.", "evidenceIds": [ "readme-docs-14", "readme-docs-21", "readme-docs-39", "readme-docs-40", "readme-docs-41", "readme-docs-42", "readme-docs-90", "readme-comm-2" ] }, { "productId": "readme", "storyId": "wysiwyg-web-editor", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "ReadMe provides a visual web editor (Guides/API Reference pages, inline AI editing) alongside bi-directional Git sync, so non-technical teammates can edit in the hub without touching git while changes sync to the same underlying source via branches/reviews. Suggest in GitHub and Reviews further support non-engineer contribution flows feeding into one source of truth. Missing for 10: independent/hands-on evidence (beyond vendor docs) confirming non-technical teammates specifically use the visual editor smoothly, and no explicit description of a WYSIWYG editor UI distinct from Markdown/MDX editing.", "evidenceIds": [ "readme-docs-11", "readme-docs-26", "readme-docs-46", "readme-docs-45", "readme-docs-27", "readme-docs-12", "readme-docs-5", "readme-docs-19", "readme-docs-18" ] } ]