# How the platform validates its content Source: https://docs.quake.ai/docs/platform/validation Markdown: https://docs.quake.ai/docs/platform/validation.md > How the Quake AI developer platform keeps documentation, infrastructure templates, and launch manifests accurate: live-platform checks, continuous integration gates, regenerated machine-readable surfaces, and manifest validation. --- # How the platform validates its content This developer platform exists to hand your AI coding assistant, and you, accurate and current data about Quake AI. Validation is the set of checks that keep that data accurate as the documentation, the templates, and the platform itself change. This page explains how we check documentation against the live platform, how we back the comparisons we make to other providers, what runs before a change publishes, how the machine-readable surfaces stay in sync with the pages, and how the launch handoff applies the same checks to a `quake.yaml` manifest. ## How documentation stays accurate against the platform We check documentation against the running platform, not against an internal model of it. When a page documents a Console workflow, a CLI command, or an API response, someone walks that path on the live platform and confirms the page matches what the platform does. Each validated page records the date of its last check in a `last_validated` field. You can read that date by fetching any page as plain markdown at `/docs/{slug}.md`. The date tells you when we last confirmed the page against the running platform, so you can judge how current a given page is before you depend on it. ## How competitor comparisons are validated This documentation compares Quake AI to other providers in the migration and evaluation guides. We back each comparison with a cited source from the provider's own documentation or pricing pages, and we keep those comparisons checkable. - **Every comparison cites a source.** When a page states how another provider handles egress, pricing, or a feature, that statement traces to a source we recorded from the provider, so the claim is attributable rather than asserted from memory. - **We link to the provider's current pages for figures that move.** Prices and rate cards change often, so we point you to the provider's own pricing page rather than printing a number that goes stale. The [Quake AI pricing page](https://www.quake.ai/pricing/) is the canonical source for Quake AI's own rates. - **We re-check the cited sources on a schedule.** A check runs against each source on a recurring cadence. When a source changes, the comparison that depends on it is flagged for review, so the guides track what the providers currently publish. - **Comparisons resolve to the same entities the rest of the site uses.** Each provider and the feature it maps to is a typed entity in the knowledge graph, with the same schema and cross-reference checks every other page gets. A comparison reflects the provider's published information as of the last time we checked its source. Provider pricing and features change on the provider's schedule, so confirm the current numbers against the provider's own pricing and documentation pages before you bring a comparison into a procurement or budgeting decision. ## How AI client integration guides are validated The [AI tools reference](/resources/ai-assisted-development/ai-assisted-development) documents how coding assistants connect to Quake AI documentation and the MCP server. Setup steps cite vendor config file paths, MCP key names, and version gates that change when a client ships a new release. - **Each documented client cites vendor sources.** Config paths and MCP key names trace to URLs we record from the vendor's own documentation, so the setup instructions are attributable rather than asserted from memory. - **Embedded config samples match the vendor's current shape.** JSON and YAML blocks in the reference pages are checked against the expected MCP key and endpoint URL for that client. - **Client membership tracks product changes.** When a client is discontinued or replaced (for example, Cody to Amp), the documentation and knowledge graph record the successor so deprecated instructions do not linger without context. - **Sources are re-checked on a schedule.** The same recurring snapshot cadence that refreshes competitor evidence applies to AI client integration sources. Integration guidance reflects the vendor's published configuration as of the last source check. Confirm the current setup path in the vendor's documentation before you depend on it in a production workflow. ## How infrastructure templates are checked Every template in the infrastructure library passes `tofu validate` in continuous integration before it ships. That check confirms the template parses and configures Quake AI's OpenStack provider correctly against the provider schema. "Validated" has a bounded meaning here. A validated template is syntactically correct and well-formed against the provider schema. It does not mean anyone applied the template against a live account, and it does not guarantee that a specific `tofu apply` in your project succeeds: that outcome depends on your quotas, image availability, network setup, and the values you supply. Treat a retrieved template as a correct starting point, and review the plan before you apply it. The [MCP server explanation](/resources/ai-assisted-development/what-is-the-mcp-server) covers this same distinction for templates an AI assistant retrieves. ## How the machine-readable surfaces stay in sync The platform publishes the same documentation in several machine-readable forms: - Plain markdown for any page at `/docs/{slug}.md` - A single-payload corpus at `llms.txt` and `llms-full.txt` - A typed entity graph at `knowledge-graph.json` that exposes services, concepts, templates, and competitor analogs The build regenerates all of these from the same MDX source on every change. When a page changes, its markdown, its corpus entry, and its graph entities change with it in the same build. The surface your AI tool retrieves matches the page a person reads, because both come from one source. ## Checks that run before a change publishes Continuous integration runs a set of automated checks on every change before it merges. They fall into a few categories: - **Prose and style consistency.** A style checker flags hedging, inconsistent terminology, and voice problems across the content. - **Link integrity.** A redirect and link audit confirms that internal links and legacy URLs resolve to a real destination. - **Knowledge-graph validation.** A schema check confirms that every page's metadata is well-formed and that its cross-references (services, concepts, prerequisites, and related pages) point at entities that exist. - **Evidence registry validation.** Competitor and AI client integration sources are checked against a schema and cross-referenced to knowledge-graph entities on every change. - **AI tools config validation.** MCP and rules config samples in the AI tools reference are parsed and checked against recorded vendor config shapes. - **Template validation.** `tofu validate` runs on every infrastructure template, as described above. - **Type and build checks.** The site type-checks and builds cleanly. A change that fails a required check does not merge, so a published page has passed every gate in this list. ## Launch handoff applies the same checks to your manifest The [launch handoff](/resources/ai-assisted-development/launch) applies this validation approach to the application you want to run. You declare your launch intent in a `quake.yaml` manifest, and the platform validates that manifest before it produces anything. - `validate_launch_manifest` checks the manifest against the schema, resolves flavor aliases against the production flavor catalog, and confirms that each declared service maps to a template in the library. It returns structured errors and warnings. - `prepare_launch` validates the manifest and then returns a handoff packet with the resolved environment, the ordered template plan, and an evidence bundle. When validation fails, the platform returns the errors and produces no packet. The evidence bundle carries named gates, including `manifest-schema`, `iac-template-resolved`, `no-leaked-secrets`, and `health-check`. The agent or control plane that executes the packet records a `pass`, `fail`, `warn`, or `skip` for each gate as it runs build, apply, and health checks. For the full manifest fields and the handoff workflow, see the [`quake.yaml` reference](/resources/ai-assisted-development/quake-yaml) and the [launch handoff overview](/resources/ai-assisted-development/launch). ## What validation does and does not guarantee Validation keeps the documentation, templates, and manifests internally consistent and checked against the platform. It does not replace your own testing. - A page reflects the platform as of its `last_validated` date. Confirm behavior against your own account before you depend on it in production. - A competitor comparison reflects the provider's published information as of the last source check. Confirm current pricing and features against the provider's own pages before a procurement decision. - A validated template parses and configures the provider correctly. Review the plan and adapt the values before you apply it. - A validated manifest is well-formed and resolvable. The build, deploy, and health checks happen when a consumer executes the handoff packet, outside this documentation platform. ## Where to go next - [Quake AI platform](/docs/platform): the platform overview and service map. - [What the MCP server is and why to use it](/resources/ai-assisted-development/what-is-the-mcp-server): how an AI assistant retrieves validated docs and templates. - [Launch handoff](/resources/ai-assisted-development/launch): declare launch intent in `quake.yaml` and download a validated handoff packet. - [Automation templates](/resources/iac-templates): the validated infrastructure library.