Model kinds

What Kinds Are

A model kind describes the role a model plays in the content system.

Kinds are not just labels for organisation. They express architectural intent that can guide validation, translation, and platform-specific modelling decisions.

Why Kinds Matter

Without kinds, every model looks like just another structure with fields. That hides an important distinction between things like:

• a publishable standalone entry
• a reusable component
• an embedded object
• a taxonomy or classification structure
• a singleton settings model

By making those roles explicit, CMMF allows tools and translators to treat models differently while preserving a shared source definition.

Supported Kinds in 1.2.0

entry

An entry is standalone content.

Typical characteristics:

• can often exist independently
• usually has its own editorial lifecycle
• is commonly translated into a top-level content type in a CMS

Examples:

• article
• page
• person

component

A component is a reusable composable block.

Typical characteristics:

• designed to be assembled into larger content structures
• may be reused across entries
• may translate into a component/block type, or sometimes into a full type depending on CMS capabilities

This kind is valuable because many CMSs distinguish between content entries and composable blocks, but they do so differently.

object

An object represents an embedded structure.

Typical characteristics:

• carries structure but is not inherently standalone
• often travels as part of another model
• may translate to an inline object, embedded type, or separate reusable schema depending on the target platform

This is one of the most important examples of why kind exists. The source intent may say “this is an object-shaped structure,” while a translator may still choose between:

• an inline embedded object
• a reusable embedded schema
• a dedicated content type if the target platform requires it

The source kind preserves the conceptual role even when implementation choices differ.

taxonomy

A taxonomy is a classification model.

Typical characteristics:

• used to categorise or organise content
• often behaves differently from editorial entries
• may translate into tags, categories, or dedicated classification types

settings

A settings model represents singleton or global configuration.

Typical characteristics:

• intended to exist once per environment, locale, or project scope
• often maps to global settings in a CMS
• may need special translator behaviour to enforce singleton semantics

What Kinds Allow Us to Do

Kinds create space for intelligent tooling. For example, a translator can use kind information to:

• decide whether a model should become a top-level content type
• decide whether a model is more naturally embedded than linked
• apply platform-specific conventions to taxonomies and settings
• generate clearer diagrams and editor documentation
• run better model-quality checks

Kinds and Translation

Kinds do not fully determine translation output. They guide it.

For example, an object kind might become:

• an inline object in Sanity
• a nested object schema in another system
• a separate content type in a platform that does not support rich embedded structures

Likewise, a component might become:

• a block schema
• a modular content type
• a union of reusable element definitions

The value of CMMF is that the source role stays consistent even when the translation shape changes.

Kinds and Validation

Kinds also create future opportunities for validation rules such as:

• warning when a settings model is not marked singleton in translation
• flagging references from object models that make embedding semantics unclear
• detecting taxonomy models that are being treated as generic entries without classification intent

Source: canonical 1.2.0 material at 32604441 · Download original Markdown