01
Model the publishing decisions
Start with what changes independently, what needs its own URL and what must be reused across views. A person, event, resource or portfolio company may deserve a content type because it has a lifecycle and relationships, not because it needs a custom template.
Taxonomies should describe stable ways the audience or editorial team groups content. One-off labels belong closer to presentation.
02
Make relationships directional
Define which record owns a relationship and whether the inverse view is derived. This avoids two fields that can disagree about the same association.
Required relationships, ordering and fallback behaviour should be visible in field instructions and validation.
03
Reuse fields with meaning
Field groups can reduce duplication when the same concept has the same rules. Reusing a visually similar field with a different business meaning creates hidden coupling.
Names should match the editor’s mental model. Template implementation details can stay in code.
04
Ship the administration guide
Document the content types, where they render, which fields are required, how relationships behave and what SEO controls are available. Include examples of common tasks and safe retirement paths.
The guide is not a handover appendix. It is the interface specification for the people operating the platform.