Reference
Content metadata schema
The content registry is the single route and discovery contract. It describes pages; native HTML continues to own durable article semantics and prose.
Base content entry
Each entry defines identity and discovery data including id, route, source/output paths, content type, canonical/navigation titles, summary, audience, programme, research area, topics, maturity, dates, authors, sitemap/searchability flags, structured-data intent, and public/canonical flags.
The schema rejects duplicate IDs, routes, source paths, and outputs at build time.
Documentation metadata
| Field | Meaning |
|---|---|
section | Landing, Start, Tutorials, How-to, Concepts, Reference, or Contributing hierarchy. |
purpose | Index, start, tutorial, how-to, explanation, reference, or contributing user need. |
order | Stable ordering inside a section. |
applies_to | Visible programme/workspace/version scope. |
related | Registry IDs of real related public content. |
Section and purpose are separate intentionally: information architecture can reflect the Pinega programme as users experience it without pretending that every hierarchy must be a literal four-folder Diátaxis map.
Build-time consumers
The build uses documentation metadata to generate the grouped docs catalogue, side navigation, breadcrumbs, provenance blocks, route metadata, and content/documentation-manifest.json. Repeated navigation/discovery chrome therefore cannot silently drift from registered routes.
Search-readiness contract
The generated documentation manifest exposes title, summary, section, purpose, applicability, related IDs, topics, programme, maturity, update date, and authors. Gate 2 does not implement full-text search; the manifest creates a stable metadata surface that Gate 5 can index alongside later blog and paper content.
The current `/docs/` control remains a topic filter over real page cards, not a site-wide search feature.
Versioning
schema_version: 2 identifies the Gate 2 registry contract. Changing required fields or semantics requires an explicit schema change and build/test update rather than an undocumented consumer assumption.