Built-in schemas

docmeta bundles seven schemas. You reference any of them by id, with no file to write, no URL to host, and no network call at validation time. This page is the registry: what each one constrains, whether it requires anything, and which are applied when you pass no flags at all.

Run docmeta schemas to print the same list from the version you have installed.

The registry

Id	Constrains	Requires	On by default	Details
google:okf:0.1	type, title, description, resource, tags, timestamp	type	Yes	OKF schema
passo-uno:seven-action:1.0	action	nothing	Yes	Taxonomy schemas
diataxis:diataxis:1.0	type	type	No	Taxonomy schemas
tgdp:templates:1.0	type	type	No	Taxonomy schemas
docusaurus:docs:3.10	25 Docusaurus docs fields	nothing	No	Docusaurus schemas
docusaurus:blog:3.10	20 Docusaurus blog fields	nothing	No	Docusaurus schemas
docusaurus:pages:3.10	9 Docusaurus pages fields	nothing	No	Docusaurus schemas

All seven use Draft 2020-12, allow additional properties, and are built-in references, so a typo in an id is reported as an unknown built-in rather than a missing file.

Two kinds of built-in

The Requires column above is the distinction that matters when you pick one.

Editorial schemas describe what a page is. google:okf:0.1 and the two type vocabularies demand their key, because adopting them is a claim that every page carries that classification, which makes an unclassified page a gap rather than an abstention. Turning one on for the first time reports every page that has not caught up yet.

Platform schemas describe what your site generator accepts. The three docusaurus:* schemas require nothing at all, because Docusaurus itself marks no front matter field as mandatory. They check the shape of the fields a page does carry, so switching one on cannot fail a page that was already building.

The two kinds mostly claim different keys, so they compose. One run can hold a page to your generator’s contract and to your own standard, attributing each failure to the schema that raised it:

docmeta validate docs/ -s docusaurus:docs:3.10 -s diataxis:diataxis:1.0

One overlap to know about: `tags`

Stacking a Docusaurus schema with google:okf:0.1 is the exception. Both define tags, and their definitions disagree: OKF allows a list of strings only, while Docusaurus also allows a tag object. Every schema in a set applies in full, so a page using the object form fails OKF:

✗ docs/install.md
    /tags/0  must be string  (line 6)  [google:okf:0.1]

If your docs set uses object tags, pair the Docusaurus schema with a vocabulary (diataxis:diataxis:1.0 or tgdp:templates:1.0, which claim only type) rather than with OKF, or use the string form. title and description also appear in both, and those definitions agree.

`diataxis` and `tgdp` are alternatives, not a pair

Both claim type. Stacking them is legal but narrows the accepted values to the intersection of the two vocabularies, which is rarely what anyone wants. Pick one. See which ones compose.

What runs when you pass no flags

Only two of the seven are in the default set:

google:okf:0.1 + passo-uno:seven-action:1.0

Everything else is opt-in. Seven-Action is safe to carry by default precisely because it requires nothing — it rules that an action, if present, is legitimate, without insisting on one. The default set sits at the bottom of the precedence chain and applies only when no --schema flag, no in-file $schema, and no config rule matched.

Turn one on

Three ways, in precedence order — the first one that matches wins, and each replaces the set rather than adding to it.

Command line

Repeat -s to build a set. This overrides everything else for the whole run:

docmeta validate docs/ -s docusaurus:docs:3.10 -s google:okf:0.1

Config file

Set a default for the repo, and override it per directory. This is the right place for the Docusaurus schemas, since a Docusaurus site has three content roots with three different contracts:

docmeta.config.yaml

schemas:
  - google:okf:0.1
overrides:
  - files: "docs/**"
    schemas:
      - docusaurus:docs:3.10
      - diataxis:diataxis:1.0
  - files: "blog/**"
    schemas:
      - docusaurus:blog:3.10
  - files: "src/pages/**"
    schemas:
      - docusaurus:pages:3.10

In the document

A document can name its own schema, which beats any config rule:

---
$schema: diataxis:diataxis:1.0
type: how-to
---

$schema also takes a list, and docmeta strips the key before validating, so it never trips a schema that forbids unknown properties.

Version ids

A built-in id is vendor:name:version. The version segment tracks the upstream standard, not docmeta’s own release number:

• google:okf:0.1 is OKF v0.1.
• docusaurus:docs:3.10 is the front matter contract of Docusaurus 3.10.

Ids are stable. A new upstream version arrives as a new id rather than a change to an existing one, so upgrading docmeta never silently retightens a check you already passed. Pin the id you validated against and move it deliberately.

If none of these fit

The built-ins are a shortcut, not a ceiling. A docs set with its own field names or its own vocabulary needs its own schema — a .json file you reference by path, or a URL you host for several repos to share. Copying the closest built-in and editing it is usually faster than starting from nothing.

Author a schemaWrite a JSON Schema of your own, from a one-field example up to a full standard.

Schema resolution referenceThe precedence chain, the three reference kinds, and the supported dialects.

Built-in OKF schemaEvery field in google:okf:0.1, its formats, and the upstream spec.

Built-in taxonomy schemasThe diataxis, tgdp, and seven-action vocabularies, and which ones compose.

Built-in Docusaurus schemasThe docs, blog, and pages front matter contracts of Docusaurus 3.10.