Content Model

Across the live runtime, the most common shared pattern is item-plus-fields. The generic visual parser reads az_item blocks, collects az_field name values, normalizes az_list content into point arrays, and turns az_section or az_substep content into titled body sections. That pattern powers the validated tabbed / indexed reader family.
The docs path uses a narrower grammar. az_docs accepts az_field name=”intro” and az_field name=”body”, a top-level az_list name=”points”, nested az_section blocks, and nested az_example blocks. The docs renderer then decides whether the current page is acting as an overview or as a section detail view.
The case-study family is separate and explicit. It uses az_case_hero, az_case_facts, az_case_fact, az_case_section, az_case_figure, az_case_video, az_case_related, and az_case_link rather than the generic az_item grammar.

Prose policy is not identical across every family, so only confirmed behaviour should be treated as system guidance.
In the live case-study runtime, prose is plain text only. The parser removes HTML authoring, strips accidental Markdown-style heading markers at the start of lines, and keeps paragraph breaks readable. That policy currently applies to hero body, section body, related-link summaries, and lead intro for case studies.
In the active docs path, intro, body, section prose, and example prose are flattened to text by the docs parser before rendering. That means docs content should also be treated as structured plain text rather than as a hidden HTML authoring channel.
Other validated visual families store authored text and render it as prose, but this pass does not define a stricter global prose policy beyond the cases explicitly confirmed above.

az_field blocks store named text values. In the generic item parser, the field name is normalized to lowercase, so authored names such as principleDesc are read as principledesc in the parsed data. That is why renderer mappings must use the normalized key, not the original mixed-case spelling.
az_list blocks are parsed as line-based lists. Leading hyphens are stripped, empty lines are ignored, and the renderer receives a clean array of points.
az_section blocks store a title plus body text. In the tabbed reader family, they become narrative sections inside the main reading column. In the docs family, they become titled documentation blocks that can also contain examples and points. In the case-study family, section content is carried through the dedicated az_case_section tag because that family also needs ordered media and related-link handling.

Confirmed media handling is currently strongest in the case-study family. az_case_figure requires a src value and may also carry alt, label, and caption. az_case_video requires a url value and may also carry title, label, and caption. These media nodes are preserved in authored order alongside narrative sections rather than collapsed into generic prose fields.
The case-study renderer groups consecutive media entries into a media grid while keeping their place in the overall flow. Video embeds attempt normal oEmbed rendering first and fall back to a visible link if embed resolution fails.
The Geometries of Use facilitation specimen uses a different media path. Its SVG artefacts are not shortcode-authored; they are loaded from the uploads directory by the theme pattern and laid out through shell CSS as page-owned specimen parts.

Evidence in the active runtime shows that requirements vary by family.