Model content, not transactions
Structure guides, network references, and notices with clear permissions, review states, validation, and an exportable publishing workflow.
Read the guide03 / CONTENT OPERATIONS
Decentralized application CMS.Model first. Publish second.
Design a publishing system that keeps explanations consistent without giving ordinary copy control over application configuration.
Start with semantic content types
Define entries by their meaning: guide, network explanation, feature reference, or release notice. Use fields that help editors understand the item rather than fields that merely reproduce one page layout. Titles and labels can change; stable relationships let the team maintain the structure without manually repairing every page.
Keep configuration separately reviewed
A contract address used for execution has different consequences from a paragraph describing that contract. Decide where runtime destinations, environment identifiers, and access rules are owned. Render reference information from reviewed configuration when appropriate rather than letting independent copies drift apart. An editorial correction should not redirect an application action.
Make approval states answer real questions
Draft, editorial review, technical review, and published can be a useful starting sequence. Each state should have a purpose and an owner. Technical review asks whether the text describes the actual behavior; editorial review asks whether a reader can understand it. Show important changes in a real page preview with nearby controls and links.
Test portability and change
Export several representative entries and inspect relationships, media, and rich text. Then change a field or retire a feature in a test copy. Does the build identify broken references? Can an editor repair them? A content model is ready for use when realistic updates and recovery are understandable, not when its field list is longest.
Contentful’s explanation describes the separation of content management from presentation in a headless CMS.
Read the headless CMS explanationQuestions to settle early
What does headless mean here?
It means separating managed content from the interface that presents it. The public output can still be prebuilt HTML; headless describes the authoring and delivery architecture, not a requirement to render every page in the browser.
How many workflow states are necessary?
Use only states that answer a real review question. A small team can have a simple process while keeping the responsibilities distinct.
READ NEXT / DAPP CMS LAB
All Lab notes Go deeper in the Lab
What is a Dapp CMS?
Separate published explanations from interface behavior and onchain state. Start with a content model your team can actually maintain.
Read the guide
AI drafts. People decide.
Scope a useful AI drafting task, preserve source evidence, validate the output, and keep editorial authority with the reviewer.
Read the guide