content-modellinglisted

# Content Modelling Design structured content models for reusable, multi-channel content. ## When to Use / Not Use **Use when:** - Designing a CMS schema for a new project - Defining content types with fields, constraints, and relationships - Planning editorial workflows (draft, review, publish, archive) - Building multi-channel content systems (web, mobile, email, API) - Migrating from page-based to structured content models - Establishing naming conventions for content types and fields **Do NOT use when:** - Building formal ontologies with classes, properties, and inference rules -> use `ontology-design` - Standardizing naming conventions across code and documentation -> use `consistency-standards` - Designing API schemas and endpoints -> use `api-design` ## Decision Tree ``` What are you modeling? ├── CMS content types (what fields, what relationships) │ ├── New system? -> Start with content inventory, then type design (§Field Types, §Relationship Types) │ └── Existing system with problems? -> Audit for anti-patterns first (§Anti-Patterns) ├── Multi-channel publishing (same content, different outputs) │ └── Need COPE? -> Use semantic fields, not layout fields (§Design Principles) ├── Editorial workflow (who reviews, when, how) │ └── Need lifecycle model? -> Define status enum + transition rules (§Content Model Template) ├── Terminology standardization (what to call things) │ └── Naming conventions only? -> Use `consistency-standards` instead └── Formal know