Specification Root
The Specification Root is the topmost canonical node for the Cuddler standards hierarchy. It explains how Document Roles comply with the root and how Artifact Definitions are governed alongside the shared Artifact Specification.
Use Cuddler's standards directory when a hidden document rule needs one canonical answer, exact scope, and an inspectable published version.
The Artifact Specification makes metadata, exact constraints, machine guidance, conformance, attribution, and publication requirements inspectable before a definition-building agent turns them into a public Artifact Definition.
Read from the top-level authority down to the concrete artifact type. Each detail page exposes the exact scope, release identity, rules, and machine-readable publication artifacts you can use as proof.
The Specification Root is the topmost canonical node for the Cuddler standards hierarchy. It explains how Document Roles comply with the root and how Artifact Definitions are governed alongside the shared Artifact Specification.
Choose the document role that matches what your artifact is supposed to do: store data, define a template, or drive a process.
Cuddler's flagship shared authoring standard for building Artifact Definitions whose exact Data Schemas make AI-generated JSON predictable and validatable.
Start from Cuddler's public library of inspectable Artifact Definitions instead of redefining a document type from scratch.
Every public standards release is reviewed before publication. The goal is not only readable prose. The review checks that each page, its machine-readable artifacts, and its publication metadata all agree closely enough to be cited, implemented, validated, and reused as a dependable public contract.
The publication process is designed to stop a standard from going live while key governance issues remain unresolved.
Reviewers confirm that the draft stays inside its layer in the standards hierarchy and uses the canonical Cuddler terms consistently.
Requirement language, conformance statements, and implementation expectations are checked for ambiguity before publication is allowed to proceed.
The page is compared against its JSON sources, schema identifiers, fixtures, examples, and supporting files so the public evidence remains aligned.
Version framing, status, attribution, and release details are checked before the draft is approved or returned for revision.