Content elements: the blocks every page is built from
Use a governed library of definitions, answers, steps, comparisons, evidence, notices, navigation, and conversion blocks so every section keeps its function across authors, pages, machines, and CMSes.
An element is a content contract
A named, typed, parameterized block defines what belongs inside it, how much it may contain, where it may appear, and what systems may do with it.
- ✓Named by purpose — definition, warning, comparison, source, and CTA describe jobs rather than visual styles.
- ✓Bounded by parameters — labels, items, citations, variants, and limits prevent improvised structures from drifting.
- ✓Placed by rule — an opening answer, in-flow warning, closing sources block, and next-step CTA occupy different parts of a document.
- ✓Rendered by channel — one element can become semantic HTML in Hugo, a native WordPress block, structured data, or a feed record.
What a content element is
Free text stores sentences. A content element stores sentences plus an explicit account of what those sentences do.
An author adds an H2 called “What is churn?”, follows it with a paragraph, and may give the first sentence bold styling. A reader can infer that it is a definition. The content system only sees a heading and prose.
Nothing records whether the definition is canonical, whether it must be near the opening, which term it defines, how long it may be, or whether another channel may reuse it.
The author inserts a definition element with a term, a concise body, and an optional qualifier. The element contract controls placement, accessible markup, length, and presentation.
A template can render it, an audit can find it, a migration can map it, and an answer system can distinguish the definition from surrounding explanation.
An element is a named, typed, parameterized content block. “Named” gives it a stable identity. “Typed” connects it to behavior. “Parameterized” means its meaningful parts are fields instead of an undifferentiated blob. It also carries position rules, content limits, variants, accessibility requirements, schema mappings, and QA checks.
This does not eliminate prose. A definition, warning, or source note still needs precise writing. It eliminates ambiguity about the prose’s job. Language can vary while honoring the contract, just as different records contain different data while sharing one schema.
Why elements beat content briefs
A prose brief can describe the desired page. Typed elements preserve its important decisions after the brief leaves the editor’s screen.
The goal is not that every page looks identical. It is that repeated functions behave predictably. A case study and glossary page can have different voices and layouts while their sources remain queryable and their related-content blocks remain governed.
The element precedence rule
If an element’s purpose matches what the section does, that element is mandatory—even when a heading and paragraph could display the same words. Free text is the fallback, not the default.
Do not search only for the label in the outline. “Clinical considerations” may conceal a warning. “At a glance” may mean key takeaways. Name the reader task: define, summarize, warn, compare, instruct, prove, navigate, or convert.
Then check purpose statements. A matching purpose takes precedence over a custom heading because the type preserves function outside the visible page.
Free text is right for analysis, transitions, examples, and explanations with no reusable contract. It should connect elements and develop the argument, not impersonate an existing component.
If a free-text pattern repeats, record it for library review. Repetition may reveal a missing element, but authors should not create unofficial components page by page.
| Outline wording | Purpose | Required choice | What prose loses |
|---|---|---|---|
| “What is X?” | Give one bounded meaning | definition box | The definition cannot be separated reliably from context. |
| “When to seek help” or “contraindications” | State risk, consequence, and safe action | warning box | A stop condition has no warning semantics. |
| A practical aside | Offer optional execution advice | tip box | The aside competes with or disappears inside required steps. |
| The summary at the top | Surface supported conclusions | key takeaways | A loose list has no placement, limit, or summary meaning. |
| A list to tick | Track completion states | Checklist element | Bullets do not distinguish actions from observations or status. |
The checklist example is unlinked because its detail specification belongs to a later library wave. The precedence decision still applies: use an approved checklist implementation where the CMS provides it; do not disguise completion states as decorative bullets.
Typed blocks vs plain text
The visible sentence is identical. The typed version retains identity and fields that downstream systems can use without guessing.
Customer churn is the loss of customers or subscribers during a measured period.
Stored as
{ "heading": "What is customer churn?",
"html": "<p>Customer churn is…</p>" }Machine output: heading and generic HTML. Definition status, term, placement, and reuse are unknown.
Customer churn is the loss of customers or subscribers during a measured period.
Stored as
{ "type": "definition",
"term": "customer churn",
"body": "Customer churn is…",
"position": "opening" }Machine output: a known definition with addressable fields, validation, semantic rendering, schema mapping, and feed eligibility.
The difference is functional, not cosmetic. Replace the component with a heading and paragraph and the reader may notice nothing, while the system loses validation, analytics, schema mapping, migration logic, and portfolio queries. Swapping a typed element for free text is a loss of function.
The eleven element groups
Each live card mirrors child-page playbookFamily metadata. Counts describe the published element librarynned for later waves.
Read first — the precedence rule that governs every other element.
The record that drives identity, discovery and schema.
The first screen: answer, summary, definition, orientation.
Definition Box · Direct Answer Block · Freshness Stamp · Intro Hook · Key Takeaways Box · Table of Contents · Who Is This For? Audience Block Rules
The blocks that carry the argument.
Accordion · Bullet Lists · Checklist · Custom Listings · Decision Tree · Do's and Don'ts · Free Text Paragraph Rules · Heading System · Iconbox · Imagebox · Infobox · Infobox · Step Lists · Tabs / Persona Switcher · Timelines · Zigzag Sections
Structured facts a reader and a machine can both use.
Calculator Embeds · Chart Blocks · Comparison Tables · Price Tables · Pros and Cons Blocks · Scorecards · Spec Tables · Stat Bands
Tips, notes and warnings — used sparingly or not at all.
Images, video, diagrams and their text equivalents.
Annotated Screenshots · Audio and Podcast Embeds · Diagrams and Illustrations · Image Gallery · Inline Images · Inline Video · Video Embeds
Product, price, availability and composition.
Availability Blocks · Composition Blocks · Offer Boxes · Product Cards · Product Sliders
Authorship, review, citation and social proof.
Author Bio Block · Disclaimer Block · Pull Quote and Expert Quote · Reviewed-by Block · Reviews Blocks · Sources and References · Testimonials · Trust Badges and Certifications · Update Log
Links, anchors and the next action.
Anchor Links · Breadcrumbs · CTA Blocks · Glossary Term Links and Tooltips · Inline CTA Button · Internal Link Modules · Mini Banner · Newsletter Capture · Related Content Blocks
Hours, address, map and booking.
Booking Blocks · Hours and Contact Blocks · Map Blocks · NAP Blocks
How a page ends, and what it asks next.
One element, three formats
Every element has one conceptual contract and adapters for portable Markdown, Hugo, and WordPress.
Consider a tip with a title and body of optional advice. Its purpose, allowed content, accessibility role, position, and QA rules stay constant. Only notation changes.
:::tip{title="Keep the query stable"}
Change one variable at a time.
:::Readable in source and independent of a site theme.
{{< callout type="tip" title="Keep the query stable" >}}
Change one variable at a time.
{{< /callout >}}The adapter maps named fields into the approved component.
<!-- wp:amicited/tip
{"title":"Keep the query stable"} -->
<p>Change one variable at a time.</p>
<!-- /wp:amicited/tip -->Native editor controls preserve the same type and fields.
Portability is not copying rendered HTML. Each adapter accepts the same meaningful input, enforces equivalent constraints, and produces channel-appropriate output. If a field cannot map safely, the adapter must fail visibly or document a controlled fallback; it must not discard meaning silently.
What's on each element page
Each detail page is public guidance and a production specification. It removes guesses that otherwise return in every implementation.
| Area | Question answered | Failure prevented |
|---|---|---|
| Purpose and non-purpose | What job does it perform, and what similar job belongs elsewhere? | A tip carrying a required step or a definition becoming a mini-article. |
| Parameter table | Which fields are required, optional, typed, repeatable, and limited? | Adapters accepting different data or several ideas hidden in one field. |
| Position rules | Where may it appear, how often, and beside what? | Takeaways buried mid-page or sources detached from claims. |
| Variant gallery | Which named variations exist and when is each appropriate? | Visual one-offs masquerading as official variants. |
| Good versus bad | What does a compliant example do that a plausible failure misses? | Teams copying syntax while missing purpose. |
| Schema mapping | How do fields map to HTML, accessibility, schema, APIs, and feeds? | Visible content disagreeing with machine output. |
| QA | What can automation enforce and what needs judgment? | A valid block publishing with vague, false, stale, or misplaced content. |
Automation can check required fields, counts, lengths, placement, identifiers, URLs, and adapter support. Editorial QA must check accuracy, usefulness, evidence quality, proportional emphasis, and whether the element is right for the reader’s task.
Which elements are required
Mandatory means the system expects the function in essentially every complete post type. It does not mean every block must be large or identical.
- Frontmatter establishes identity, ownership, discovery, and joins.
- Introduction confirms scope and reader fit.
- Key takeaways surface supported conclusions on substantial pages.
- FAQ resolves genuine residual questions.
- Sources make factual support traceable.
- Related content supplies the next learning route.
- CTA offers one proportionate action.
- Use a definition when a term needs a bounded meaning.
- Use a direct answer for a clear primary question.
- Use steps for an ordered procedure and verifiable outcome.
- Use comparisons when readers evaluate alternatives on consistent criteria.
- Use a tip for optional improvement and a warning for material risk.
- Use annotated media when the visual communicates something prose cannot as efficiently.
Exceptions matter. A short glossary definition may not need separate takeaways. A page with no externally supported factual claim may not need visible references. An FAQ with invented questions is worse than none. Post-type specifications set defaults; authors document justified omissions instead of filling slots mechanically.
Start with the relevant post types specification, which orders the usual elements for the reader’s task. Then apply precedence section by section. The result is neither a blank page nor a rigid form: it is governed assembly with room for original argument, evidence, examples, and voice.
Typed elements let an agent assemble instead of invent
The element library is where a content system stops being a document and becomes something a machine can execute. A block with declared fields either has what it needs or visibly does not.
A comparison table needs comparable options, a stated dimension per row, and a verification date. When one of those inputs does not exist, a typed block gives the agent somewhere to fail loudly.
Free prose has no such property. Asked for a table with no data behind it, an agent produces a table anyway, and the invented cell looks exactly like a researched one.
Check the library by purpose before writing a heading. That instruction is followed far more reliably by an agent than by a person under deadline, because an agent will genuinely re-read the whole library every time.
This is a case where the agent is the better operator: the rule is mechanical, and mechanical is what agents are for.
Each element is defined once and expressed as a portable Markdown directive, a Hugo shortcode, and a WordPress block. The agent works against the portable form and never has to know which CMS the output lands in.
That also means changing a CMS does not invalidate the content system or require re-teaching the agent.
Because elements are typed, the corpus can be queried. Which pages lack a sources block. Which comparison tables have no verification date. Which direct answers exceed their band.
You can only run that audit on content assembled from named blocks. Prose is not queryable, so prose-based quality control does not scale past the number of pages a person can read.
Every element page carries a parameter table with required fields, minimums and maximums, position rules, and a QA checklist. That is the level of precision an agent needs to build without guessing — and the same precision makes the output reviewable by a human in a fraction of the time.
Content elements FAQ
A content element is a named, typed, parameterized block with a defined purpose, allowed fields, position rules, length limits, rendering behavior, and quality checks. It stores content and function.
Use free text when no library element matches the purpose. Analysis, narrative, transitions, and unique explanations often remain prose; established definitions, warnings, comparisons, sources, and CTAs do not.
No. The contract standardizes structure and function, not conclusions or voice. Authors still choose arguments, evidence, examples, and wording.
Yes. The portable contract is independent of presentation. Adapters map the same fields into native syntax and markup while preserving validation and semantics.
Build one page from blocks you can govern at scale
Free check · 7-day trial · no credit card