Built-in schemas

manni meta bundles forty-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. Each id links to its own page, with its fields, an example page, and the finding a common mistake produces.

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

The registry

Id	Constrains	Requires	On by default	JSON
google:okf:0.1	type, title, description, resource, tags, timestamp	type	Yes	okf/0.1.json
passo-uno:seven-action:1.0	action	nothing	Yes	seven-action/1.0.json
diataxis:diataxis:1.0	type	type	No	diataxis/1.0.json
tgdp:templates:1.0	type	type	No	tgdp/1.0.json
tgdp:templates:1.1	type	type	No	tgdp/1.1.json
tgdp:templates-strict:1.1	type, closed to the 25 template slugs	nothing	No	tgdp-strict/1.1.json
docusaurus:docs:3.10	25 Docusaurus docs fields	nothing	No	docusaurus-docs/3.10.json
docusaurus:blog:3.10	20 Docusaurus blog fields	nothing	No	docusaurus-blog/3.10.json
docusaurus:pages:3.10	9 Docusaurus pages fields	nothing	No	docusaurus-pages/3.10.json
astro:starlight:0.41	15 Starlight front matter fields	title	No	starlight/0.41.json
antora:page:3.1	10 Antora page header attributes	title	No	antora/3.1.json
sphinx:docinfo:9.1	5 Sphinx file-wide docinfo fields	nothing	No	sphinx/9.1.json
myst:frontmatter:1.10	41 MyST page frontmatter fields	nothing	No	myst/1.10.json
ogp:article:1.0	17 Open Graph and article:* properties	og:title, og:type, og:url, og:image	No	ogp/1.0.json
dcmi:elements:1.1	the 15 Dublin Core elements	nothing	No	dcmi/1.1.json
microsoft:learn:1.0	16 Microsoft Learn attributes	title, description, author, ms.author, ms.date	No	microsoft-learn/1.0.json
oasis:dita-metadata:1.3	30 DITA metadata keys	nothing	No	dita/1.3.json
hugo:page:0.165	28 Hugo front matter fields	nothing	No	hugo/0.165.json
jekyll:page:4.4	7 Jekyll front matter variables	nothing	No	jekyll/4.4.json
vitepress:page:1.6	16 VitePress front matter options	nothing	No	vitepress/1.6.json
x:cards:1.0	23 twitter:* card tags	twitter:card	No	x-cards/1.0.json
agentskills:skill:1.0	the 6 Agent Skills SKILL.md fields	name, description	No	agent-skills/1.0.json
anthropic:claude-skill:2.1	20 Claude Code SKILL.md fields	nothing	No	claude-skill/2.1.json
mkdocs:material:9.7	19 MkDocs and Material front matter keys	nothing	No	mkdocs-material/9.7.json
anthropic:claude-subagent:2.1	18 Claude Code agent definition fields	name, description	No	claude-subagent/2.1.json
manni:core:1.0.0	title, description, id, type, keywords, language	title, description	Yes	core/1.0.0.json
manni:core-strict:1.0.0	the form of title, description, id, type, keywords, language	nothing	No	core-strict/1.0.0.json
manni:stewardship:1.0.0	authors, owner, stakeholders, reviewed-by, created, last-updated, last-reviewed, review-interval, verified-against, source-of-truth	nothing	Yes	stewardship/1.0.0.json
manni:stewardship-strict:1.0.0	the form of authors, owner, stakeholders, reviewed-by, created, last-updated, last-reviewed, verified-against, source-of-truth	nothing	No	stewardship-strict/1.0.0.json
manni:audience:1.0.0	audiences, personas, journeys, intent, visibility	nothing	Yes	audience/1.0.0.json
manni:audience-strict:1.0.0	the form of audiences, personas, journeys, intent	nothing	No	audience-strict/1.0.0.json
manni:lifecycle:1.0.0	lifecycle, replaced-by, supersedes, remove-by	replaced-by or remove-by on a deprecated page	Yes	lifecycle/1.0.0.json
manni:lifecycle-strict:1.0.0	the form of replaced-by, supersedes, remove-by	nothing	No	lifecycle-strict/1.0.0.json
manni:structure:1.0.0	applies-to, not-applicable-to, concepts, prerequisites, next-steps, related-pages	nothing	Yes	structure/1.0.0.json
manni:structure-strict:1.0.0	the form of applies-to, not-applicable-to, prerequisites, next-steps, related-pages	nothing	No	structure-strict/1.0.0.json
manni:terminology:1.0.0	label, definition, abstract, alt-labels, hidden-labels, broader, narrower, related-terms, see, scope-note	label, and definition or see, on a type: term page	No	terminology/1.0.0.json
manni:terminology-strict:1.0.0	the form of label, see	nothing	No	terminology-strict/1.0.0.json
manni:ai-context:1.0.0	provenance, meta-provenance, risks, sample-questions	nothing	Yes	ai-context/1.0.0.json
manni:ai-context-strict:1.0.0	the form of meta-provenance, risks	nothing	No	ai-context-strict/1.0.0.json
manni:evals:1.0.0	evals, eval-suite, eval-skip	nothing	Yes	evals/1.0.0.json
manni:evals-strict:1.0.0	the form of evals, eval-suite	nothing	No	evals-strict/1.0.0.json
manni:artifact-evals:1.0.0	metadata	nothing	No	artifact-evals/1.0.0.json
manni:artifact-evals-strict:1.0.0	the form of metadata	nothing	No	artifact-evals-strict/1.0.0.json
manni:graph:1.0.0	graph	nothing	Yes	graph/1.0.0.json
manni:graph-strict:1.0.0	the form of graph	nothing	No	graph-strict/1.0.0.json
manni:citations:1.0.0	citations	nothing	Yes	citations/1.0.0.json
manni:citations-strict:1.0.0	the form of citations	nothing	No	citations-strict/1.0.0.json

All forty-seven use Draft 2020-12 and are built-in references. A typo in an id is reported as an unknown schema rather than a missing file.

Forty-six of them allow additional properties. agentskills:skill:1.0 is the one exception, and not out of strictness. The tooling that packages a skill for distribution hard-errors on a key outside the standard’s six rather than ignoring it. A schema that tolerated unknown keys would pass exactly the file that cannot ship. See agentskills:skill:1.0.

The published URLs

Every built-in is also served as plain JSON, at a version-pinned path under https://hawkeyexl.github.io/manni/schemas/. The twenty-three that predate the manni: vocabularies stay served under the pre-rename base as well, https://hawkeyexl.github.io/docmeta/schemas/. Both spellings resolve to the bundled copy, so a $schema line or a $ref written before the rename keeps working offline. New references should use the current base:

https://hawkeyexl.github.io/manni/schemas/okf/0.1.json
https://hawkeyexl.github.io/manni/schemas/seven-action/1.0.json
https://hawkeyexl.github.io/manni/schemas/diataxis/1.0.json
https://hawkeyexl.github.io/manni/schemas/tgdp/1.0.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-docs/3.10.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-blog/3.10.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-pages/3.10.json
https://hawkeyexl.github.io/manni/schemas/starlight/0.41.json
https://hawkeyexl.github.io/manni/schemas/antora/3.1.json
https://hawkeyexl.github.io/manni/schemas/sphinx/9.1.json
https://hawkeyexl.github.io/manni/schemas/myst/1.10.json
https://hawkeyexl.github.io/manni/schemas/ogp/1.0.json
https://hawkeyexl.github.io/manni/schemas/dcmi/1.1.json
https://hawkeyexl.github.io/manni/schemas/microsoft-learn/1.0.json
https://hawkeyexl.github.io/manni/schemas/dita/1.3.json
https://hawkeyexl.github.io/manni/schemas/hugo/0.165.json
https://hawkeyexl.github.io/manni/schemas/jekyll/4.4.json
https://hawkeyexl.github.io/manni/schemas/vitepress/1.6.json
https://hawkeyexl.github.io/manni/schemas/x-cards/1.0.json
https://hawkeyexl.github.io/manni/schemas/agent-skills/1.0.json
https://hawkeyexl.github.io/manni/schemas/claude-skill/2.1.json
https://hawkeyexl.github.io/manni/schemas/mkdocs-material/9.7.json
https://hawkeyexl.github.io/manni/schemas/claude-subagent/2.1.json
https://hawkeyexl.github.io/manni/schemas/core/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/core-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/stewardship/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/stewardship-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/audience/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/audience-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/lifecycle/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/lifecycle-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/structure/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/structure-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/terminology/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/terminology-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/ai-context/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/ai-context-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/evals/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/evals-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/artifact-evals/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/artifact-evals-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/graph/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/graph-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/citations/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/citations-strict/1.0.0.json
https://hawkeyexl.github.io/manni/schemas/tgdp/1.1.json
https://hawkeyexl.github.io/manni/schemas/tgdp-strict/1.1.json

They exist for three jobs. You can $ref a built-in from a schema of your own, or use one with a JSON Schema tool that is not manni meta. You can also read the actual JSON instead of a description of it.

Inside manni meta, a published URL costs nothing. manni meta recognises its own URLs and answers them from the copy bundled in the package. There is no request, no timeout, and no dependence on GitHub Pages being up. --offline and an air-gapped build work exactly as they do with the id. A schemaTrust policy that refuses URLs still accepts these, because they reach nothing. The two spellings are interchangeable:

---
$schema: https://hawkeyexl.github.io/manni/schemas/okf/0.1.json
type: how-to
---

Each schema's `$id` is not its URL, on purpose

Open one of the files and you will see "$id": "google:okf:0.1" rather than the https://… address you fetched it from. Some strict JSON Schema tooling warns about that mismatch. The warning is expected and the file is not broken.

The $id is manni meta’s reference for the schema. It is what a document’s $schema names, what Ajv de-duplicates registrations on, and what appears in every report. Changing it to the URL would move all three at once and would break every document already carrying $schema: google:okf:0.1. The retrieval URI and the identifier are simply two different names for one schema, and both resolve.

Extend a built-in with $ref

The reason a URL beats a copy-paste. Reference a built-in from your own schema and add to it, by either name. The id and the URL both work, and neither touches the network:

house.schema.json

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "allOf": [{ "$ref": "google:okf:0.1" }],
  "required": ["title", "owner"],
  "properties": {
    "owner": { "type": "string", "minLength": 1 }
  }
}

Every rule the built-in carries still applies, and yours are added on top. That is composition inside one schema. Listing two schemas in a set is different. A set applies each schema whole and attributes failures separately. A $ref lets you narrow or extend what the built-in said.

A published URL never changes, and that is the point

Each of these paths is immutable. The bytes served at schemas/okf/0.1.json today are the bytes served there for good. A fix to a built-in ships as a new version file rather than an edit to a published one. A CI check hashes every schema against a committed manifest and fails the build if an already-published version is altered. This is enforced rather than promised.

Two hosting caveats apply to anything load-bearing outside manni meta. GitHub Pages can return 404 briefly during a deploy, and its Access-Control-Allow-Origin: * is current behaviour rather than a contract. If a build must not depend on either, vendor the file into your own repository and reference the local copy.

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. 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. A platform schema requires exactly what the generator refuses to build without, and nothing more. What it demands is a fact about the tool, not an editorial choice manni meta made for you.

That cuts both ways. The three docusaurus:* schemas and sphinx:docinfo:9.1 require nothing, because those tools mark no field as mandatory. Switching one on cannot fail a page that was already building. astro:starlight:0.41 and antora:page:3.1 both require title, because Starlight and Antora both error without a page title. A page failing that check was already broken, and manni meta is only telling you sooner.

The three agent schemas are platform schemas of a different sort: the platform is the agent runtime rather than a site generator. anthropic:claude-skill:2.1 requires nothing, because Claude Code marks every SKILL.md field optional. agentskills:skill:1.0 requires name and description, because the open standard does and the packaging tools refuse a skill without them. anthropic:claude-subagent:2.1 requires the same two for a third reason. Claude Code will not load an agent definition that is missing either. See Agent Skills schemas and Claude Code subagent schema.

Every id in the registry links to its full field table.

Vocabulary schemas are a third kind. They describe a document to something outside your docs site: a social card renderer (ogp:article:1.0), a catalogue or repository (dcmi:elements:1.1), or another publisher’s build (microsoft:learn:1.0). Open Graph is the one built-in that checks something no build tool checks. Nothing fails when og:image is missing, and the page just renders badly everywhere it is shared. See Metadata vocabularies.

The manni vocabularies are editorial schemas of manni’s own, eleven families that each answer one question about a page. Only manni:core:1.0.0 requires anything, a title and a description. Two more require a key only on a page that opts in. A deprecated lifecycle needs its successor or removal date, and a type: term page needs its label. Each family has a strict overlay, manni:<family>-strict:1.0.0. Stack it beside the open vocabulary to narrow the form of values the open one already claims. An overlay requires nothing. See manni vocabularies.

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:

manni meta 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 diataxis:diataxis:1.0 or tgdp:templates:1.1 rather than with OKF, or use the string form. Those two claim only type. 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

Eleven of the forty-seven are in the default set, in this order:

google:okf:0.1
passo-uno:seven-action:1.0
manni:core:1.0.0
manni:audience:1.0.0
manni:structure:1.0.0
manni:stewardship:1.0.0
manni:lifecycle:1.0.0
manni:ai-context:1.0.0
manni:evals:1.0.0
manni:graph:1.0.0
manni:citations:1.0.0

A bare run therefore requires type, which OKF requires, and title and description, which core requires. The other nine rule on a field only when a page carries it. Seven-Action rules that an action, if present, is legitimate, without insisting on one. A field a vocabulary prefers in external metadata draws a location:external warning when it sits on the page. Warnings never fail a run.

Terminology, artifact-evals, and every strict overlay stay out of the default set. strict: true in config stacks the overlay of each manni: default after its base. See strict versions.

The default set sits at the bottom of the precedence chain. Config schemas join it rather than replace it, unless the config sets defaults: false. A --schema flag or an in-file $schema replaces it. So does a matching config override, unless it sets defaults: true.

Turn one on

Three ways, in precedence order. The first one that matches wins. The flag and the document replace the set. An override replaces it too, unless it sets defaults: true. Config schemas add to the default set.

Command line

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

manni meta validate docs/ -s docusaurus:docs:3.10 -s google:okf:0.1

Config file

Add a schema for the whole repo, and override the set per directory. This is the right place for the Docusaurus schemas, since a Docusaurus site has three content roots with three different contracts:

manni.config.yaml

meta:
  schemas:
    - tgdp:templates:1.1         # joins the default set for every other file
  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

Each override here replaces the set for its files. Add defaults: true to an entry to keep the default set in front of its schemas.

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 manni meta 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 manni meta’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.
• hugo:page:0.165 is the contract as of Hugo 0.165, and Hugo releases monthly. Its front matter fields change far more slowly, so this id is not expected to move every month. A new one ships when the contract changes, not when Hugo does.
• mkdocs:material:9.7 versions on Material for MkDocs 9.7, not on MkDocs 1.6, even though the vendor segment says mkdocs. MkDocs itself defines two front matter keys and Material defines the other seventeen. Material is what the contract tracks, and Material’s version is the one that can move it. astro:starlight:0.41 pairs a platform with a theme the same way. Ids are stable. A new upstream version arrives as a new id rather than a change to an existing one. Upgrading manni meta never silently retightens a check you already passed. Pin the id you validated against and move it deliberately.
• manni:core:1.0.0 versions a vocabulary manni itself defines, so its version has three segments and tracks no upstream. Ids resolve by exact string. manni:core:1 names nothing, and a later 1.1.0 registers beside 1.0.0 rather than replacing it.

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. That is 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.

meta.register names your own schema by its $id, such as house:page:1.0.0. The id then works anywhere a built-in id does, and a registered house:page-strict:1.0.0 stacks beside it under strict: true. manni meta schemas lists the registered ids after the built-ins. See Name your schema and its strict version.

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.

manni vocabulariesThe eleven manni vocabulary families and their strict overlays.

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.