Add a New Content Type¶

Controlled process for expanding documentation formats without breaking existing workflows.

When to add a new content type¶

A recurring authoring need does not fit any existing template (e.g., case-study, incident-report, release-notes).
An ad-hoc artifact has been produced > 3 times in different shapes and would benefit from a normalized template.

Define the type. A short proposal:
identifier (<lowercase-hyphen>),
audience and intent,
sections required,
quality checklist additions if any.
Update the schema.
Bump content-type.schema.json minor version.
Add the new identifier to allowed content_type values (if enumerated).
Create the template.
File: templates/<identifier>.template.md.
Frontmatter conforms to content-type.schema.json.
Required sections present; placeholders explicit.
Editorial guidance.
Append a "Review requirements by content type" row in editorial-policy.md.
Compatibility tests.
Render one document of the new type from a real project source via the doc-generation loop.
Confirm:
- schema validation passes,
- editorial policy checks pass,
- publish-loop dry-run succeeds against at least one applicable adapter (or skip if no adapter applies yet).
Publishing-policy update.
If the new type maps to a new venue category, update publishing-policy.yaml approvals_required.
Document and announce.
Add a row to README.md "Files" table.
Add a row to the add-new-content-type runbook history below.

If the new type causes lint or workflow regressions, revert the schema version and template, and reissue a smaller, more focused proposal.

Date	Identifier	Reason