Content Type

The atomic unit of a Content Type. Each field is a named container with explicit constraints that eliminate ambiguity.

• Data Typing: Enforces machine-readable formats (e.g., string, integer, datetime, reference).
• Cardinality: Defines whether a field is required (1..1) or repeatable (0..n).
• Validation Rules: Applies regex patterns, min/max values, or enumerated lists to ensure data integrity.

Example: A 'Product Page' Content Type might define price as a required float with a minimum value of 0.01.

Content Types model real-world connections through explicit relational fields, moving beyond flat spreadsheets to rich knowledge graphs.

• Reference Fields: Link one Content Type to another (e.g., an 'Article' references an 'Author').
• One-to-Many: A single 'Category' contains multiple 'Blog Posts'.
• Many-to-Many: 'Products' linked to multiple 'Features', and vice versa.

These relationships are the foundation of Linked Data and enable graph-based querying.

A Content Type is useless without rigorous automated validation. The schema acts as a gatekeeper, rejecting any data that violates the contract.

• Schema-on-Write: Data is validated against the schema before persistence, guaranteeing structural consistency.
• Error Handling: Invalid documents are rejected with specific, actionable error messages.
• Type Coercion: Some systems attempt safe type casting (e.g., "5" to 5), but strict schemas often forbid it to prevent data corruption.

This ensures that every 'Blog Post' in the repository has a valid publishDate.

The logical definition of a Content Type is independent of its wire format. The same conceptual model can be rendered into multiple serialization formats for different consumers.

• JSON Schema: For REST APIs and web applications.
• Protocol Buffers (protobuf): For high-performance gRPC microservices.
• GraphQL Schema: For flexible, client-driven data fetching.
• JSON-LD: For embedding semantic meaning into HTML for search engines.

This decoupling allows a single Canonical Data Model to serve diverse technical ecosystems.

Business requirements change, and Content Types must adapt without breaking existing consumers. Schema Evolution is a critical design characteristic.

• Backward Compatibility: New schema versions can read data written by old versions.
• Forward Compatibility: Old schema versions can read data written by new versions (often by ignoring unknown fields).
• Semantic Versioning: Uses MAJOR.MINOR.PATCH to signal breaking vs. non-breaking changes.

A robust Content Type strategy treats the schema as a living Data Contract between producers and consumers.

Beyond business-specific fields, every Content Type inherits a set of system-level attributes for management and observability.

• Identity: A universally unique identifier (UUID) for every entry.
• Audit Trail: Automatic tracking of createdAt, updatedAt, and createdBy fields.
• Status: A workflow state like draft, published, or archived.
• Locale: A marker for multi-language content variants.

These properties are typically managed by the Headless Content Management system itself, not the content author.

The foundational long-form content type for editorial and thought-leadership platforms. It structures narrative text with rich metadata for discovery.

Core Fields:

• title (Text, required)
• slug (Slug, unique)
• body (Rich Text / Markdown)
• author (Reference to Author content type)
• publishedDate (DateTime)
• featuredImage (Media reference)
• categories (Array of Taxonomy references)
• seoMetadata (Object: metaTitle, metaDescription)

Validation Rules: Slug must be URL-safe and unique. Published date cannot be in the future for live content.

The canonical e-commerce content type that represents a sellable inventory item. It combines marketing copy with structured product data for faceted search and comparison.

Core Fields:

• productName (Text, required)
• SKU (Text, unique, required)
• description (Rich Text)
• price (Number, decimal)
• currency (Enum: USD, EUR, GBP)
• images (Array of Media references)
• specifications (Array of key-value pairs)
• variants (Array of nested objects: size, color, stockLevel)
• relatedProducts (Array of references)

Cardinality: One product can have many variants (1:N). Each variant has exactly one stock level.

A reusable entity representing an individual, typically referenced by other content types like Blog Posts, Press Releases, or Team Pages. This separation enables single-source author management.

Core Fields:

• fullName (Text, required)
• slug (Slug, unique)
• bio (Rich Text, max 500 characters)
• headshot (Media reference)
• role (Text)
• socialLinks (Array of objects: platform, url)
• email (Email, validated format)

Relationship: A Blog Post references a Person via an author field. Deleting a Person should be prevented if referenced by published content (referential integrity).

A modular, campaign-oriented content type designed for marketing conversion. Unlike rigid templates, it uses a composable section model where editors assemble pages from reusable blocks.

Core Fields:

• pageTitle (Text, required)
• slug (Slug, unique)
• sections (Array of polymorphic blocks)
  • HeroBlock: headline, subheadline, ctaText, ctaUrl, backgroundImage
  • FeatureGridBlock: Array of {icon, title, description}
  • TestimonialBlock: quote, attribution, avatar
  • FormBlock: formId (reference to Form content type)
• seoMetadata (Object)
• noIndex (Boolean, default: false)

Schema Design Pattern: Uses a union type or polymorphic array where each section block has a discriminator field (e.g., _type: "hero").

A time-bound content type for webinars, conferences, and meetups. It requires precise temporal data and often integrates with calendar schemas like Schema.org's Event type.

Core Fields:

• eventName (Text, required)
• slug (Slug, unique)
• startDateTime (DateTime, required, with timezone)
• endDateTime (DateTime, must be after startDateTime)
• venue (Object: name, address, geoCoordinates) OR virtualLink (URL)
• description (Rich Text)
• speakers (Array of Person references)
• registrationUrl (URL)
• status (Enum: upcoming, live, past, cancelled)

Automation Rule: Status should auto-update from upcoming to live to past based on current server time. Past events should be excluded from primary listing pages.

A granular, structured content type optimized for featured snippets and voice search. Each item is a self-contained question-answer pair, often assembled into FAQ pages programmatically.

Core Fields:

• question (Text, required, unique)
• answer (Rich Text, required)
• category (Taxonomy reference)
• order (Integer, for manual sorting)
• audience (Enum: general, developer, enterprise)

Structured Data Mapping: This type maps directly to the Schema.org Question and Answer types. The JSON-LD output aggregates multiple FAQ Items into a single FAQPage schema on the rendered page.

Programmatic Behavior: FAQ Items are rarely displayed individually. A Dynamic Content Assembly query pulls all items tagged with a specific category and renders them as an accordion component.