Flowchart diagram - accessible

///mermaid flowchart TD accTitle: Example flowchart accDescr: Flowchart illustrating holiday shopping choices after receiving money at Christmas. Christmas[Christmas] Christmas -->|Get money| GoShopping[Go shopping] GoShopping --> LetMeThink{Let me think} LetMeThink -->|One| Laptop[Laptop] LetMeThink -->|Two| IPhone[iPhone] LetMeThink -->|Three| F[F]

• Explain the Christmas Shopping Decision Flowchart

  Summary Narrative

  During Christmas, you receive money and decide to go shopping. As you consider your options, you reach a decision point where you think about what to buy. You have three choices: purchasing a laptop, buying an iPhone, or selecting an unspecified third option. This flowchart represents the simple decision-making process of spending money received during the holiday season.

  Overview

  This flowchart illustrates a sequential decision-making workflow. It comprises 6 distinct nodes (2 process steps, 1 central decision point, and 3 outcome terminal states) connected by 4 directed transitions.

  Nodes and Elements

  Christmas

  Represents the starting context or triggering event.

  • Type: Process Node

  • Text: Christmas

  Go shopping

  Represents the action taken after receiving money.

  • Type: Process Node

  • Text: Go shopping

  Let me think

  Represents the branch point where a purchase option is evaluated.

  • Type: Decision Node

  • Text: Let me think

  Laptop

  Represents the outcome selected under the first choice.

  • Type: Outcome Node

  • Text: Laptop

  iPhone

  Represents the outcome selected under the second choice.

  • Type: Outcome Node

  • Text: iPhone

  F

  Represents an unspecified fallback or alternate outcome selected under the third choice.

  • Type: Outcome Node

  • Text: F

  Relationships and Flow Transitions

  • Christmas leads to Go shopping via directed arrow labeled "Get money".

  • Go shopping leads to Let me think via directed arrow.

  • Let me think branches to Laptop via directed arrow labeled "One".

  • Let me think branches to iPhone via directed arrow labeled "Two".

  • Let me think branches to F via directed arrow labeled "Three".

Mindmap - accessible when not paired with Sankey diagram due to duplicate ids (node-1)

///mermaid %%{init: { "theme": "base", "themeVariables": { "fontSize": "18px", "primaryColor": "#003087", "primaryTextColor": "#ffffff", "primaryBorderColor": "#003087", "secondaryColor": "#F0F4F5", "secondaryTextColor": "#212B32", "secondaryBorderColor": "#AEB7BD", "tertiaryColor": "#005EB8", "tertiaryTextColor": "#ffffff", "tertiaryBorderColor": "#005EB8", "nodeBorderRadius": 10 }, "mindmap": { "padding": 15, "maxNodeWidth": 300 } }%% mindmap root(NHS Number) (Costs to implement) (Benefits) (Cost savings) ::icon(fa fa-sterling-sign) (Progress) (Highly adopted) (95% of the NHS) (Used by) (ISB 0149-01 NHS Number for General Practice) ::icon(fa fa-book) (ISB 0149-02 NHS Number for Secondary care) ::icon(fa fa-book) (Related to) (ISB 0086 Information Governance Toolkit) ::icon(fa fa-book-open) (ISB 1512 Information Governance Standards Framework) ::icon(fa fa-book-open) (ISB 1572 Sensitive Data) ::icon(fa fa-book-open) (ISB 1077 AIDC for Patient Identification) ::icon(fa fa-book-open) (ISB 1555 NHS Number for Babies) ::icon(fa fa-book-open) (Care settings) (Community health) (GP / Primary care) (Acute) (Hospital) (Maternity) (Mental health) (Urgent and Emergency Care) (Legal obligations) (Mandatory) (for NHS providers) ::icon(fa fa-hospital) (Due to) (Section 250) ::icon(fa fa-scale-balanced) (About) (Access to records) (Appointment / scheduling) (Continuity of care) (Demographics) (Key care information) (Patient communication) (Referrals)

• Explain the NHS Number Standard Mindmap

  Summary Narrative

  This diagram shows how the NHS Number is used across the health and care system to help keep your information safe, accurate, and easy to find. It explains that using the NHS Number is required by law for NHS services, and it’s already used by nearly all of them. It helps link your records when you go to different places for care—like your GP, hospital, or mental health services—so staff can see the right details about you. The diagram also shows how the NHS Number connects to other important rules and standards that protect your data and support good care. Overall, it helps make sure everyone involved in your care is on the same page.

  Overview

  This mindmap outlines the governance, adoption, clinical topics, and technical ecosystem of the NHS Number standard. It branches outward from a single root node into 8 primary domains connecting 25 subordinate nodes across health and care settings.

  Nodes and Elements

  NHS Number

  The central root entity representing the unique patient identifier standard across England and Wales.

  • Type: Root Node

  • Text: NHS Number

  About

  Represents clinical and operational information domains supported by the identifier.

  • Type: Domain Branch Node

  • Sub-nodes: Continuity of care, Key care information, Demographics, Access to records, Patient communication, Referrals, Appointment / scheduling

  Progress

  Represents national uptake metrics and deployment status across the estate.

  • Type: Domain Branch Node

  • Sub-nodes: Highly adopted, which leads to 95% of the NHS

  Used by

  Specifies individual Information Standards Board (ISB) scope definitions.

  • Type: Domain Branch Node

  • Sub-nodes: ISB 0149-01 NHS Number for General Practice, ISB 0149-02 NHS Number for Secondary care

  Costs to implement

  Represents the financial and resource commitments necessary to adopt the standard.

  • Type: Terminal Attribute Node

  • Text: Costs to implement

  Benefits

  Represents the operational improvements and financial returns delivered by standardized identification.

  • Type: Domain Branch Node

  • Sub-nodes: Cost savings

  Related to

  Specifies dependent and allied health informatics, baby identification, and information governance standards.

  • Type: Domain Branch Node

  • Sub-nodes: ISB 1555 NHS Number for Babies, ISB 0086 Information Governance Toolkit, ISB 1572 Sensitive Data, ISB 1512 Information Governance Standards Framework, ISB 1077 AIDC for Patient Identification

  Legal obligations

  Identifies legislative mandates and compliance statutory instruments governing usage.

  • Type: Domain Branch Node

  • Sub-nodes: Mandatory, which links sequentially to for NHS providers, Due to, and Section 250

  Care settings

  Details the health and social care sectors where implementation applies.

  • Type: Domain Branch Node

  • Sub-nodes: Community health, GP / Primary care, and Acute (which branches into Maternity, Hospital, Mental health, and Urgent and Emergency Care)

  Relationships and Branch Mappings

  • NHS Number connects to About.

  • About connects to Continuity of care.

  • About connects to Key care information.

  • About connects to Demographics.

  • About connects to Access to records.

  • About connects to Patient communication.

  • About connects to Referrals.

  • About connects to Appointment / scheduling.

  • NHS Number connects to Progress.

  • Progress connects to Highly adopted, which connects to 95% of the NHS.

  • NHS Number connects to Used by.

  • Used by connects to ISB 0149-01 NHS Number for General Practice.

  • Used by connects to ISB 0149-02 NHS Number for Secondary care.

  • NHS Number connects to Costs to implement.

  • NHS Number connects to Benefits.

  • Benefits connects to Cost savings.

  • NHS Number connects to Related to.

  • Related to connects to ISB 1555 NHS Number for Babies.

  • Related to connects to ISB 0086 Information Governance Toolkit.

  • Related to connects to ISB 1572 Sensitive Data.

  • Related to connects to ISB 1512 Information Governance Standards Framework.

  • Related to connects to ISB 1077 AIDC for Patient Identification.

  • NHS Number connects to Legal obligations.

  • Legal obligations connects to Mandatory.

  • Mandatory connects to for NHS providers.

  • for NHS providers connects to Due to.

  • Due to connects to Section 250.

  • NHS Number connects to Care settings.

  • Care settings connects to Community health.

  • Care settings connects to GP / Primary care.

  • Care settings connects to Acute.

  • Acute connects to Maternity.

  • Acute connects to Hospital.

  • Acute connects to Mental health.

  • Acute connects to Urgent and Emergency Care.

Standards Directory Roadmap (2024 - 2026) Gantt chart - accessible

///mermaid %%{init: { "theme": "default", "displayMode:" "compact", "themeVariables": { "primaryColor": "#005eb8", // NHS Blue for bars "primaryTextColor": "#ffffff", // White text for contrast "primaryBorderColor": "#003a70", // Darker NHS Blue border "secondaryColor": "#007f3b", // NHS Green for optional bars "tertiaryColor": "#768692", // NHS Mid Grey for milestones "fontSize": "16px", "textColor": "#231f20", // NHS Black for general text "lineColor": "#231f20", // NHS Black for grid lines "background": "#f0f4f5" // NHS Pale Grey background } }}%% gantt accTitle: Standards Directory Roadmap (2025 - 2026) accDescr: Gantt chart illustrating project milestones, content updates, and platform capabilities for the Standards Directory Roadmap. title Standards Directory Roadmap (2024 - 2026) dateFormat YYYY-MM-DD tickinterval 12month section Project WCAG 2.2 accessible :done, q1_2025, 2025-01-01, 2025-05-15 GDS live certified:done, q1_2026, 2025-12-01, 2026-03-30 Business cases:done, q1_2026, 2025-10-01, 2026-03-30 section Content Open standards :done, q2_2025, 2025-05-01, 2025-06-30 ISO TC215 standards :done, q1_2025, 2025-01-01, 2025-05-30 Create taxonomy :done, q3_2025, 2025-07-01, 2025-08-30 Create ontology :done, q4_2025, 2025-09-01, 2025-10-31 Data elements :done, q2_2025, 2025-04-01, 2025-07-31 Glossaries :done, q2_2025, 2025-05-01, 2025-10-30 Simplify standards :done, q2_2025, 2025-03-01, 2025-05-30 Requirements/Benefits:done, q2_2025, 2025-05-01, 2025-09-30 section Capability Data model upgrade :done, q1_2025, 2025-01-01, 2025-05-01 Email notifications :done, q1_2025, 2025-01-01, 2025-06-30 Integrate taxonomies :done, q3_2025, 2025-06-01, 2025-09-01 Content Management System :done, q4_2025, 2025-09-01, 2026-01-30 Autocomplete search :done, q1_2025, 2025-01-01, 2025-01-31 Accessible diagrams :done, q1_2025, 2025-01-01, 2025-05-31 Accessible documents :done, q1_2025, 2025-01-01, 2025-06-30

• Explain the Standards Directory Roadmap (2024 - 2026)

  Summary Narrative

  This chart shows the plan for improving the NHS Standards Directory from early 2025 to spring 2026. It starts with making documents easier to read and fully accessible by May 2025. During the year, important content like international and open standards was added, and the information was better organised using clear categories. Helpful features like search suggestions, email updates, and easier navigation were added throughout 2025. A system to manage content was put in place by early 2026. The project reaches a major milestone in March 2026 with official GDS live certification and completed business plans.

  Overview

  This Gantt chart details the strategic multi-year delivery timeline for the Standards Directory Roadmap from 2024 through 2026, demarcated by timeline markers for 01 January 2025 and 01 January 2026[cite: 3]. It organizes 17 distinct work packages and delivery streams across 3 primary strategic sections: Project, Content, and Capability[cite: 3].

  Nodes and Elements

  Project Section

  Represents governance, compliance accreditation, and business assurance deliverables[cite: 3].

  • WCAG 2.2 accessible: Accessibility standard compliance stream starting early 2025[cite: 3].

  • GDS live certified: Government Digital Service assessment and live service accreditation target positioned in early 2026[cite: 3].

  • Business cases: Strategic business justification and operational approvals scheduled across late 2025 into 2026[cite: 3].

  Content Section

  Encompasses metadata schemas, standard definitions, taxonomy frameworks, and core catalog curation[cite: 3].

  • Open standards: Publication and incorporation of mandated cross-government open standards[cite: 3].

  • ISO TC215 standards: Health informatics international standards adoption delivered across early 2025[cite: 3].

  • Create taxonomy: Development of categorized navigation structures in mid-to-late 2025[cite: 3].

  • Create ontology: Semantic relationship definitions and data modeling delivered during late 2025[cite: 3].

  • Data elements: Granular data item standardization delivered in mid 2025[cite: 3].

  • Glossaries: Terminology definitions and vocabulary harmonization delivered across mid 2025[cite: 3].

  • Simplify standards: Plain-language translation and structure simplification streams during mid 2025[cite: 3].

  • Requirements/Benefits: Impact definition framework and requirement mapping delivered during mid-to-late 2025[cite: 3].

  Capability Section

  Represents core digital infrastructure, publishing tools, and search functionality on the platform[cite: 3].

  • Data model upgrade: Backend schema enhancement and infrastructure refactoring in early 2025[cite: 3].

  • Email notifications: Automated user alert mechanisms scheduled across early 2025[cite: 3].

  • Integrate taxonomies: Implementation of standardized taxonomy tagging within search workflows during late 2025[cite: 3].

  • Content Management System: Dedicated authoring and publishing system rollout crossing from late 2025 into early 2026[cite: 3].

  • Autocomplete search: Predictive query completion component implemented in early 2025[cite: 3].

  • Accessible diagrams: Diagram refactoring and accessible alternative rendering across early 2025[cite: 3].

  • Accessible documents: Document remediation stream ensuring accessible downloads across early 2025[cite: 3].

  Relationships and Flow Transitions

  • Timeline milestone 01 Jan 2025 precedes delivery of foundational accessibility and infrastructure tasks including WCAG 2.2 accessible, Data model upgrade, Accessible diagrams, and Accessible documents[cite: 3].

  • Create taxonomy informs the subsequent delivery of Create ontology and downstream Integrate taxonomies[cite: 3].

  • Content preparation streams (Data elements, Glossaries, Simplify standards) feed into the finalization of Requirements/Benefits[cite: 3].

  • Platform capability enhancements across 2025 culminate in the delivery of the Content Management System spanning the 01 Jan 2026 milestone[cite: 3].

  • Timeline milestone 01 Jan 2026 leads directly into final project governance closure, completing Business cases and securing GDS live certified status[cite: 3].

Pie chart - accessible

///mermaid %%{init: { "pie": { "textPosition": 0.5 }, "theme": "default", "themeVariables": { "pieOuterStrokeWidth": "2px", "pieStrokeColor": "#003087", // Dark NHS Blue border "pie1": "#005eb8", // NHS Blue "pie2": "#007f3b", // NHS Green "pie3": "#8a1538", // NHS Dark Red "pie4": "#330072", // NHS Purple (optional) "pie5": "#768692" // NHS Dark Grey (supporting) } }}%% pie showData accTitle: Example piechart accDescr: Pie chart illustrating the percentage distribution of four key mineral elements in Product X. title Key elements in Product X "Calcium" : 42.96 "Potassium" : 50.05 "Magnesium" : 10.01 "Iron" : 5

• Explain the example Pie chart

  Summary Narrative

  This pie chart shows the main elements found in a product, using both colours and labels to help you understand the amounts[cite: 4]. Potassium is the largest part, making up 50.05% of the product[cite: 4]. Calcium is next, at 42.96%[cite: 4]. Magnesium is much smaller at 10.01%, and Iron is the smallest part at 5%[cite: 4].

  Overview

  This proportional pie chart displays the compositional breakdown of essential minerals within Product X[cite: 4]. It details 4 categorical slices representing constituent quantities and their corresponding percentage shares of the total formulation[cite: 4].

  Nodes and Elements

  Potassium

  Represents the primary mineral constituent of Product X[cite: 4].

  • Value: 50.05[cite: 4]

  • Chart Display: 46%[cite: 4]

  • Color: Slate blue[cite: 4]

  Calcium

  Represents the second largest mineral constituent of Product X[cite: 4].

  • Value: 42.96[cite: 4]

  • Chart Display: 40%[cite: 4]

  • Color: Light blue[cite: 4]

  Magnesium

  Represents a minor mineral constituent of Product X[cite: 4].

  • Value: 10.01[cite: 4]

  • Chart Display: 9%[cite: 4]

  • Color: Ochre gold[cite: 4]

  Iron

  Represents the smallest mineral constituent of Product X[cite: 4].

  • Value: 5[cite: 4]

  • Chart Display: 5%[cite: 4]

  • Color: Pink[cite: 4]

  Relationships and Data Distribution

  • Potassium [50.05] comprises the largest single slice, visually rendered at 46% of the chart area[cite: 4].

  • Calcium [42.96] comprises the second largest slice, visually rendered at 40% of the chart area[cite: 4].

  • Magnesium [10.01] comprises the third slice, visually rendered at 9% of the chart area[cite: 4].

  • Iron [5] comprises the smallest slice, visually rendered at 5% of the chart area[cite: 4].

  • Combined together, Potassium and Calcium account for 86% of the total visual composition of Product X[cite: 4].

Entity relationship diagram - accessible

///mermaid %%{init: { "theme": "default", "themeVariables": { "primaryColor": "#005eb8", // NHS Blue for entity background "primaryTextColor": "#ffffff", // White text for contrast "primaryBorderColor": "#003087", // Dark NHS Blue border "lineColor": "#330072", // Supporting Purple for relationships "fontSize": "14px" } }}%% erDiagram accTitle: Example entity relationship diagram accDescr: Entity relationship diagram showing the data connections between customers, delivery addresses, orders, invoices, and products. CUSTOMER }|..|{ DELIVERY-ADDRESS : has CUSTOMER ||--o{ ORDER : places CUSTOMER ||--o{ INVOICE : "liable for" DELIVERY-ADDRESS ||--o{ ORDER : receives INVOICE ||--|{ ORDER : covers ORDER ||--|{ ORDER-ITEM : includes PRODUCT-CATEGORY ||--|{ PRODUCT : contains PRODUCT ||--o{ ORDER-ITEM : "ordered in"

• Explain the example Entity relationship diagram

  Summary Narrative

  This diagram outlines the core components of an online shopping system and demonstrates how customer purchases move from basket to fulfillment. A customer can register multiple delivery addresses and place multiple orders. Each order contains specific line items tied to individual products, which are organised under overarching product categories. When an order is completed, it generates an invoice that the customer is liable for, ensuring a full audit trail linking buyer, products, billing, and destination.

  Overview

  This entity relationship diagram illustrates an e-commerce purchasing and invoicing data schema. It defines 7 primary entities and 7 relational links mapping customer accounts, order fulfillment lines, billing objects, and catalog hierarchies.

  Entities and Attributes

  CUSTOMER

  Represents the purchasing user or organization registered within the commerce system.

  • Entity: CUSTOMER

  • Role: Root account entity initiating orders and holding payment liability.

  DELIVERY-ADDRESS

  Represents the physical location where purchased goods must be shipped.

  • Entity: DELIVERY-ADDRESS

  • Role: Location record associated with customer profiles and order destinations.

  ORDER

  Represents an individual purchasing transaction created by a customer.

  • Entity: ORDER

  • Role: Central transactional entity tracking placement, shipping address, and line items.

  ORDER-ITEM

  Represents a specific line item and quantity within a placed order.

  • Entity: ORDER-ITEM

  • Role: Join and detail entity linking orders to specific catalog products.

  PRODUCT

  Represents an individual item available for purchase within the store catalog.

  • Entity: PRODUCT

  • Role: Catalog item referenced across order fulfillment records.

  PRODUCT-CATEGORY

  Represents a broader departmental grouping or taxonomy used to classify products.

  • Entity: PRODUCT-CATEGORY

  • Role: Hierarchical classification entity organizing the product catalog.

  INVOICE

  Represents the formal billing document issued for a completed transaction.

  • Entity: INVOICE

  • Role: Accounting record linked to an order and billed to a liable customer.

  Relationships and Flow Transitions

  • One CUSTOMER has zero, one, or more DELIVERY-ADDRESS records via 'has'.

  • One CUSTOMER places zero, one, or more ORDER records via 'places'.

  • One CUSTOMER is liable for zero, one, or more INVOICE records via 'liable for'.

  • One DELIVERY-ADDRESS receives one or more ORDER shipments via 'receives'.

  • One ORDER includes one or more ORDER-ITEM lines via 'includes'.

  • One INVOICE covers exactly one ORDER via 'covers'.

  • One PRODUCT-CATEGORY contains one or more PRODUCT entities via 'contains'.

  • One PRODUCT is ordered in zero, one, or more ORDER-ITEM lines via 'ordered in'.

Class diagram - accessible

///mermaid %%{init: { "theme": "default", "themeVariables": { "primaryColor": "#005eb8", // NHS Blue for node fill "primaryTextColor": "#ffffff", // White text for high contrast "primaryBorderColor": "#003087", // Darker NHS Blue border "lineColor": "#330072", // Supporting Purple for relationships "fontSize": "14px" } }}%% classDiagram accTitle: Example class diagram accDescr: Class diagram illustrating object-oriented inheritance relationships, attributes, and methods across animal types. Animal <|-- Ducks Animal <|-- Fish Animal <|-- Zebra Animal : +int age Animal : +String gender Animal: +isMammal() Animal: +mate() class Duck{ +String beakColor +swim() +quack() } class Fish{ -int sizeInFeet -canEat() } class Zebra{ +bool is_wild +run() }

• Explain the example Class diagram

  Summary Narrative

  This diagram organizes different animals into a clear family tree to show which traits they share and what makes each one unique. At the head of the tree is Animal, which sets common details like age, gender, and shared behaviors for everything below it. Specialized types—such as Duck, Fish, and Zebra—inherit these baseline details while adding their own distinct features, like swimming, running, or specific physical traits.

  Overview

  This UML class diagram models object-oriented inheritance relationships across biological classifications. It defines 5 distinct classes comprising 1 parent superclass and 4 subclasses, detailing visibility scopes, attribute data types, and method signatures.

  Entities and Attributes

  Animal

  Represents the core superclass defining general properties common to all creature instances.

  • Attribute: +int age (Public integer representing age)

  • Attribute: +String gender (Public string representing gender)

  • Method: +isMammal() (Public function returning mammal verification)

  • Method: +mate() (Public function representing reproduction)

  Duck

  Represents an avian subclass containing bird-specific characteristics.

  • Attribute: +String beakColor (Public string denoting beak appearance)

  • Method: +swim() (Public method defining aquatic locomotion)

  • Method: +quack() (Public method defining vocalization)

  Fish

  Represents an aquatic subclass with encapsulated dimensional attributes.

  • Attribute: -int sizeInFeet (Private integer recording length in feet)

  • Method: -canEat() (Private method governing consumption capabilities)

  Zebra

  Represents an ungulate mammal subclass with wild classification state.

  • Attribute: +bool is_wild (Public boolean flag tracking wild vs domesticated state)

  • Method: +run() (Public method defining terrestrial movement)

  Ducks

  Represents an alternate group or collection subclass derived from the base class.

  • Note: Contains empty attribute and operation compartments.

  Relationships and Flow Transitions

  • Fish inherits from Animal via directed generalization arrow.

  • Zebra inherits from Animal via directed generalization arrow.

  • Ducks inherits from Animal via directed generalization arrow.

  • Duck stands as a separate specialized class alongside the inheritance hierarchy.

Quadrant diagram - accessible

///mermaid %%{init: { "theme": "default", "themeVariables": { "quadrant1Fill": "#007f3b", // NHS Green – positive (We should expand) "quadrant2Fill": "#005eb8", // NHS Blue – strategic (Need to promote) "quadrant3Fill": "#8a1538", // NHS Dark Red – warning (Re-evaluate) "quadrant4Fill": "#768692", // NHS Dark Grey – neutral (May be improved) "textColor": "#ffffff", // High contrast white text "fontSize": "14px" } }}%% quadrantChart accTitle: Example quadrant diagram accDescr: Quadrant chart evaluating six marketing campaigns across reach and engagement dimensions to guide strategic promotion decisions. title Reach and engagement of campaigns x-axis Low Reach --> High Reach y-axis Low Engagement --> High Engagement quadrant-1 We should expand quadrant-2 Need to promote quadrant-3 Re-evaluate quadrant-4 May be improved Campaign A: [0.3, 0.6] Campaign B: [0.45, 0.23] Campaign C: [0.57, 0.69] Campaign D: [0.78, 0.34] Campaign E: [0.40, 0.34] Campaign F: [0.35, 0.78]

• Explain the example Quadrant diagram

  Summary Narrative

  This chart organizes six marketing campaigns into four distinct action categories based on how widely they were seen and how strongly audiences interacted with them. Campaigns that achieved both wide visibility and strong interaction are flagged for wider expansion, while those with high interaction but limited audience size need greater promotion. Conversely, initiatives with substantial visibility but weak engagement require optimization, and campaigns that scored poorly across both dimensions are recommended for re-evaluation.

  Overview

  This 2x2 quadrant matrix maps the performance distribution of campaigns A through F across dual axes: reach along the horizontal axis and engagement along the vertical axis. Each axis partitions performance into Low and High bands, establishing four distinct strategic action zones: Need to promote, We should expand, Re-evaluate, and May be improved.

  Nodes and Elements

  Need to promote

  Represents the upper-left quadrant defined by low reach and high audience engagement.

  • Campaign F: High engagement, low reach initiative.

  • Campaign A: High engagement, low reach initiative.

  We should expand

  Represents the upper-right quadrant defined by both high reach and high audience engagement.

  • Campaign C: Top-performing initiative with strong reach and engagement.

  Re-evaluate

  Represents the lower-left quadrant defined by both low reach and low audience engagement.

  • Campaign E: Underperforming initiative with low scores across both metrics.

  • Campaign B: Underperforming initiative with low scores across both metrics.

  May be improved

  Represents the lower-right quadrant defined by high reach but low audience engagement.

  • Campaign D: Broadly distributed initiative requiring content optimization to boost interaction.

  Relationships and Flow Transitions

  • Initiatives in Need to promote (Campaign A and Campaign F) demonstrate strong content resonance that can transition into We should expand if distribution reach is scaled up.

  • Initiatives in May be improved (Campaign D) possess established audience volume and can transition into We should expand by refining engagement triggers.

  • Initiatives in Re-evaluate (Campaign B and Campaign E) fall below threshold expectations across both axes and risk decommissioning unless fundamentally redesigned.

  • Campaign C serves as the benchmark outcome within We should expand, meeting criteria for continuous investment.

Xy bar line chart - accessible

///mermaid %%{init: {'look': 'handDrawn', 'theme': 'neutral', 'themeVariables': {'primaryColor': '#005EB8'}}}%% xychart-beta accTitle: Example bar chart accDescr: Vertical bar chart showing daily training time in minutes from Monday through Sunday, peaking on Saturday at 300 minutes. title "Training progress" x-axis [mon, tues, wed, thur, fri, sat, sun] y-axis "Time trained (minutes)" 0 --> 300 bar [60, 0, 120, 180, 230, 300, 0]

• Explain the example Bar chart

  Summary Narrative

  This chart tracks how much time was spent training each day across a full week[cite: 8]. Training kicks off on Monday, pauses on Tuesday, and then climbs steadily every single day until peaking with the longest session on Saturday[cite: 8]. Sunday serves as a rest day with no activity, wrapping up the weekly routine[cite: 8].

  Overview

  This XY bar chart visualizes weekly training volume titled "Training progress"[cite: 8]. The horizontal axis displays the seven consecutive days of the week from Monday through Sunday, while the vertical axis measures time trained in minutes spanning from 0 to 300 in 20-minute intervals[cite: 8].

  Nodes and Elements

  mon

  Represents training duration on Monday[cite: 8].

  • Day: mon[cite: 8]

  • Duration: 60 minutes[cite: 8]

  tues

  Represents a rest day on Tuesday with no recorded workout time[cite: 8].

  • Day: tues[cite: 8]

  • Duration: 0 minutes[cite: 8]

  wed

  Represents the mid-week training session on Wednesday[cite: 8].

  • Day: wed[cite: 8]

  • Duration: 120 minutes[cite: 8]

  thur

  Represents an escalated training session on Thursday[cite: 8].

  • Day: thur[cite: 8]

  • Duration: 180 minutes[cite: 8]

  fri

  Represents an extended training session on Friday[cite: 8].

  • Day: fri[cite: 8]

  • Duration: 230 minutes[cite: 8]

  sat

  Represents the peak training session of the week on Saturday[cite: 8].

  • Day: sat[cite: 8]

  • Duration: 300 minutes[cite: 8]

  sun

  Represents the final day of the week serving as an active recovery or complete rest day[cite: 8].

  • Day: sun[cite: 8]

  • Duration: 0 minutes[cite: 8]

  Relationships and Flow Transitions

  • Daily duration progresses from 60 minutes on mon to 0 minutes on tues[cite: 8].

  • Activity resumes on wed with a continuous daily increase: 120 minutes on wed, 180 minutes on thur, 230 minutes on fri, and reaching a maximum of 300 minutes on sat[cite: 8].

  • Training concludes with 0 minutes recorded on sun[cite: 8].

  • Total cumulative training duration across all seven days equals 890 minutes.

Git diagram - accessible

///mermaid %%{init: { "theme": "default", "themeVariables": { "git0": "#005eb8", // NHS Blue for base "git1": "#231f20", // NHS Black for highlights "git2": "#425563", // NHS Dark Grey "gitBranchLabelColor": "#ffffff", "gitLabelColor": "#231f20", "lineColor": "#005eb8", "textColor": "#231f20" } }}%% gitGraph accTitle: Example release diagram accDescr: Git release diagram tracking the progression of a standard along the main branch from Front door to Retired. commit id: "Front door" commit id: "Prototype standard:" type: NORMAL tag: "v1.0.0" commit id: "FCAP approved" commit id: "Review" type: REVERSE tag: "RC_1" commit id: "Standard published" commit id: "Adopted" type: HIGHLIGHT tag: "8.8.4" commit id: "Retired"

• Explain the example Progress diagram

  Summary Narrative

  This diagram shows how a standard moves through its complete lifecycle, from an early idea to when it is no longer used[cite: 9]. It starts when a proposal enters through the front door, moves into building an early prototype version, and earns formal committee approval[cite: 9]. After undergoing a detailed review, the standard is officially published and widely adopted across services[cite: 9]. Eventually, when newer approaches take over, the standard reaches the end of its life and is retired[cite: 9].

  Overview

  This Git-style release workflow diagram models the chronological governance lifecycle of a standard along the primary main branch[cite: 9]. It tracks 7 sequential lifecycle stages and 3 specific release version tags[cite: 9].

  Nodes and Elements

  main

  The primary release branch representing the single source of truth for the standard's lifecycle[cite: 9].

  • Branch Name: main[cite: 9]

  Front door

  Represents the initial submission, intake, and triage point for a new standard proposal[cite: 9].

  • Commit Stage: Front door[cite: 9]

  • State: Initial standard commit[cite: 9]

  Prototype standard:

  Represents initial draft specification and prototype development[cite: 9].

  • Commit Stage: Prototype standard:[cite: 9]

  • Release Tag: v1.0.0[cite: 9]

  FCAP approved

  Represents formal sign-off and approval by the governance board or assurance committee[cite: 9].

  • Commit Stage: FCAP approved[cite: 9]

  Review

  Represents formal scrutiny and evaluation preceding full operational release[cite: 9].

  • Commit Stage: Review[cite: 9]

  • Release Tag: RC_1 (Release Candidate 1)[cite: 9]

  • Node Marker: Highlighted cross icon[cite: 9]

  Standard published

  Represents the official public release of the assured standard[cite: 9].

  • Commit Stage: Standard published[cite: 9]

  Adopted

  Represents active deployment, integration, and operational uptake across health and care systems[cite: 9].

  • Commit Stage: Adopted[cite: 9]

  • Release Tag: 8.8.4[cite: 9]

  • Node Marker: Square milestone marker[cite: 9]

  Retired

  Represents the terminal stage where the standard is formally phased out or decommissioned[cite: 9].

  • Commit Stage: Retired[cite: 9]

  • Note: Concludes with a dashed connector line denoting completion of the active release track[cite: 9].

  Relationships and Flow Transitions

  • Front door commits sequentially forward to Prototype standard: (tagged as v1.0.0) along the main branch[cite: 9].

  • Prototype standard: progresses to FCAP approved following governance assessment[cite: 9].

  • FCAP approved moves into the Review gate (tagged as RC_1)[cite: 9].

  • Review advances to Standard published upon successful validation[cite: 9].

  • Standard published leads to widespread implementation at the Adopted milestone (tagged as 8.8.4)[cite: 9].

  • Adopted transitions into Retired when the standard reaches end-of-life status[cite: 9].