Mermaid Diagram Conventions

Two diagram styles are used across this space. Both are plain Mermaid code fences (```mermaid), so they render natively on GitHub/GitLab and in most editors.

Org chart diagrams

Used in orgchart/.

• Diagram type: flowchart TD.
• One subgraph per region for regional views (global.md may show all regions, a regional file shows just that region’s subgraph).
• Rectangular nodes ([Label]) for individual contributors.
• Rounded nodes ((Label)) for managers/leads.

Example (org chart):

flowchart TD
    CTO(VP Engineering)
    CTO --> LeadA(DXP Engineering Lead - LATAM)
    CTO --> LeadB(DXP Engineering Lead - EMEA)
    LeadA --> ICA1[Frontend Developer]
    LeadA --> ICA2[Backend Developer]
    LeadB --> ICB1[Frontend Developer]

Roadmap diagrams (roadmap.sh style)

Used in roadmaps/.

• Diagram type: flowchart TD or flowchart LR.
• Priority is encoded with three classDefs, always defined at the top of the diagram in this order: essential, recommended, optional.
• Related topics are grouped with subgraph per phase/area.
• Every roadmap diagram is preceded by the legend (see the _templates/roadmap-template.md template in the repository root, not part of this site).

Color values (keep consistent across all roadmap diagrams):

Priority	classDef
Essential	fill:#4C6EF5,color:#fff,stroke:#333;
Recommended	fill:#F5A623,color:#000,stroke:#333;
Optional	fill:#eee,color:#000,stroke:#999,stroke-dasharray: 3 3;

Example:

flowchart TD
    classDef essential fill:#4C6EF5,color:#fff,stroke:#333;
    classDef recommended fill:#F5A623,color:#000,stroke:#333;
    classDef optional fill:#eee,color:#000,stroke:#999,stroke-dasharray: 3 3;

    subgraph Fundamentals
        A[Topic A]:::essential --> B[Topic B]:::essential
    end
    subgraph "Going Further"
        B --> C[Topic C]:::recommended
        B --> D[Topic D]:::optional
    end

Specializations branch

When a track’s roadmap has CMS-specific specializations (see reference/tracks.md), the diagram adds one more layer after the common trunk (Fundamentals / Going Further): one subgraph per CMS, always in the same order (AEM Traditional, AEM EDS, Optimizely Cloud, Contentful), each reached by an edge from the last common node. Give each specialization subgraph an explicit id so it can be an edge target: subgraph <Id>["<CMS Display Name>"]. The priority classDefs (essential/recommended/optional) apply inside specialization subgraphs the same as in the common trunk.

Example (trunk omitted, showing just the branch):

flowchart TD
    classDef essential fill:#4C6EF5,color:#fff,stroke:#333;
    classDef recommended fill:#F5A623,color:#000,stroke:#333;

    Core[...common core...] --> AEMT
    Core --> AEMEDS

    subgraph AEMT["AEM Traditional"]
        X[Topic X]:::essential
    end
    subgraph AEMEDS["AEM EDS"]
        Y[Topic Y]:::recommended
    end