Overview

Before publication, each public Cuddler standards surface is reviewed as both a human-readable document and a machine-consumable contract. That review applies to the public standards stack: the Specification Root, each published Domain Specification, the shared Artifact Specification, and the public Artifact Definitions those governing standards support.

The purpose of the process is straightforward. A public standard should say exactly what it governs, stay within its layer of responsibility, align with its JSON and publication artifacts, and be clear enough that an implementer, validator, reviewer, or AI system can use it without private background context.

Peer review is therefore not treated as a cosmetic editorial pass. It is the final check that a proposed publication is ready to be cited, implemented, validated, and reused responsibly.

What the review is designed to protect

The peer review process exists to protect four qualities before publication:

1. Terminology discipline: the draft uses the canonical Cuddler terms consistently and does not blur Domain Specification, Artifact Specification, Artifact Definition, and Artifact Document responsibilities.
2. Normative clarity: requirement language is explicit enough to guide implementers and reviewers without hidden assumptions.
3. Evidence alignment: prose, canonical URLs, JSON artifacts, fixtures, and supporting files agree with one another.
4. Publication readiness: attribution, status, versioning, and release framing are complete enough for public publication.

Scope of peer review

Peer review is expected before publication of any public standards material that establishes or updates an externally visible contract, including:

• the Specification Root,
• any published Domain Specification,
• the shared Artifact Specification,
• and public Artifact Definitions.

Supporting materials are also reviewed when they affect interpretation or implementation of the published contract. That includes canonical JSON source artifacts, support schemas, fixture bundles, implementation notes, and any page-level metadata required to publish the standard responsibly.

Review stages

The review is organized as a staged publication gate. Those stages are intended to surface different classes of problems before a public release is approved.

1. Scope and terminology review

The committee first confirms that the proposed standard stays inside its intended layer in the hierarchy. A Domain Specification must behave like a Domain Specification, the shared Artifact Specification must remain a cross-domain authoring standard, and an Artifact Definition must remain a concrete artifact-type definition rather than silently expanding into a higher-level governing standard.

At this stage, reviewers also confirm that the canonical Cuddler terms are used consistently, that section titles and summaries reflect the document’s actual authority, and that the page does not create ambiguous overlap with sibling standards.

2. Normative and conformance review

Once the scope is stable, the committee reviews the normative language. Requirement statements should be precise enough to guide authoring, validation, publication, and implementation behavior. If a requirement can be read in materially different ways, or if a conformance statement cannot be operationalized by a reviewer or validator, the draft is not ready for publication.

This stage is where reviewers look closely at definitions, required metadata, allowed behaviors, publication rules, and any statements that would affect interoperability or validator behavior.

3. Artifact and evidence alignment review

The review then checks whether the written document matches the public artifacts that support it. Canonical URLs, JSON source documents, schema identifiers, fixtures, examples, and any related support files should tell the same story as the prose page.

This matters because public standards are implemented from evidence, not only from narrative explanation. A standard that reads well but does not align with its published artifacts is not ready to be treated as a dependable contract.

4. Publication readiness review

The final stage checks whether the release can be published responsibly. Reviewers confirm version framing, status language, copyright and attribution statements, public links, and other release details that allow downstream users to cite and reuse the publication correctly.

At the end of this stage, the standard is either approved for publication or returned for revision with blocking issues that must be resolved before release.

Approval expectations

Cuddler standards are peer reviewed before publication, which means a standard is not published while blocking review issues remain open. Approval requires the review cycle to finish with the draft judged clear in scope, coherent in normative language, aligned with its supporting public artifacts, and ready for responsible public release.

Where the committee identifies ambiguities, misalignment, or incomplete publication framing, the standard returns to revision rather than being published in a partially clarified state.

Review outputs

The peer review process normally ends in one of two outcomes:

1. Revision required: the draft needs changes before publication because one or more review gates did not clear.
2. Approved for publication: the draft is ready to be published as a public Cuddler standards surface.

When a draft is approved, the expectation is that the canonical page, its metadata, and the public machine-readable artifacts that support the release remain aligned at publication time.

Peer Review Committee

The current Cuddler Standards Peer Review Committee members are:

• Emily Tell, EMBA
• Dr. Darlington Etaje, PhD
• Dr. Adefemi Debo-omidokun, PhD

The committee’s role is to review proposed public standards before release, challenge unclear or incomplete material, and help ensure that what is published is readable, governable, and implementable.

Relationship to the publication hierarchy

Peer review does not replace the standards hierarchy. It exists to protect it. The Standards page explains the public system at a high level, the Specification Root anchors the hierarchy, Domain Specifications classify domains, the shared Artifact Specification governs authoring rules, and Artifact Definitions define concrete artifact types for implementation.

Peer review is the governance checkpoint that confirms those layers remain coherent before a public standard is released.