“Return incomplete requests; leave longer than three days also needs a department lead.” An AI assistant can turn that sentence into a diagram in seconds. The trouble starts when you trace its arrows: an incomplete request may lead to “approved,” or a rejected request may have nowhere to go. A flowchart is an operating instruction, not decoration.
This tutorial uses a fictional company leave policy to turn prose into a Mermaid flowchart and test its paths. The three-day threshold is an example, not legal advice or a claim about any employer. The method works for operations staff, administrators, product managers, and anyone maintaining SOPs in Markdown, a knowledge base, or a repository.
Turn the policy into decidable facts before asking for a diagram
Our example rules are limited: an employee submits dates, a reason, and a handover contact. Incomplete information is returned for correction and can be resubmitted. A complete request goes to the direct manager. A rejection ends with a reason. If the manager approves, a request of three days or fewer is communicated to the employee and added to the calendar. A longer request also needs department-lead approval; that lead may approve or reject it.
The rules say nothing about an absent manager, withdrawal, or whether weekends count. These are questions for the policy owner, not invitations for the model to invent policy. Before drawing, make a three-column list: condition, actor, destination. For example, “missing details | applicant corrects | resubmit” and “manager rejects | manager gives reason | rejected.” If those rows are ambiguous, a polished diagram will still be wrong.
Prompt the AI to list paths before generating Mermaid
Open a fresh conversation in ChatGPT or Claude and use the following prompt. Replace any real employee information with placeholders; the sample contains only invented rules.
You are a process analyst. Use only the fictional rules below; do not add unstated company policy.
Rules: An employee submits leave dates, a reason, and a handover contact. Incomplete requests are returned for correction and may be resubmitted. Complete requests go to the direct manager. If the manager rejects, end as rejected and state the reason. If the manager approves, requests of three days or fewer are communicated to the employee and added to the calendar. Requests longer than three days also need department-lead approval. The lead can reject or approve; approval leads to notification and a calendar update.
First provide:
1. A node list with each actor and action;
2. A branch list showing both yes/no destinations for every decision;
3. Questions about cases not defined by the rules.
Only then output Mermaid flowchart TD code. Every decision must have labeled yes/no edges. Correction must return to submission, not approval. Approved and rejected must be distinct terminal states. Do not add styling or invented approvers. Outside the code block, explain the paths for three days or fewer and for more than three days.Listing nodes and edges first makes mistakes visible in plain language. If “longer than three days” incorrectly points to direct approval, you can correct a single branch before rendering. A focused follow-up such as “change only branch four; keep the remaining rules and node IDs” is easier to control than “draw it again.”
A Mermaid example you can paste directly
Paste the code into the Mermaid Live Editor. Square brackets denote actions and braces denote decisions. Yes/no labels matter more than color because they remain legible in monochrome.
flowchart TD
A["Employee submits leave request"] --> B{"Information complete?"}
B -->|No| C["Return for correction"]
C --> A
B -->|Yes| D["Direct manager reviews"]
D --> E{"Manager approves?"}
E -->|No| H["Reject and explain why"]
E -->|Yes| F{"More than three days?"}
F -->|No| I["Notify employee and update calendar"]
F -->|Yes| G["Department lead reviews"]
G --> J{"Lead approves?"}
J -->|No| H
J -->|Yes| Iflowchart TD lays the graph out from top to bottom. A, B, and C are internal node IDs; quoted strings are visible labels. Keep IDs stable when changing copy so you do not have to reconnect every edge. The “No” branch of “More than three days?” includes exactly three days. If a real policy says “three working days,” both the condition and boundary tests must change.
The manager review appears once: every complete request passes through it, and only approved requests branch by duration. Duplicating the manager node on both paths can hide a missing rejection route. If a real policy requires parallel approvals instead of sequential ones, this diagram is unsuitable. Confirm the order and what happens when one approver rejects before drawing a new graph.
Test business paths, not just whether the graph looks good
After pasting the code into the Live Editor, check for parser errors and trace these six cases:
- Missing handover contact: submit → incomplete → return for correction → resubmit; it must not reach approval.
- Complete two-day request, manager approves: notify and update the calendar.
- Complete request for exactly three days, manager approves: still use the three-days-or-fewer route.
- Five-day request, manager rejects: stop as rejected, without involving the department lead.
- Five-day request, manager approves, lead rejects: end as rejected.
- Five-day request, both approvers agree: only then notify and update the calendar.
Inspect every decision diamond: are all exits labeled? Does an intermediate node have no onward edge? Can a correction loop skip review? The loop back to submission is intentional resubmission, not a programmatic infinite loop. In practice an employee might abandon or withdraw a request, but our example rules do not define that state, so the diagram does not fabricate it.
Fix syntax locally rather than rewriting the whole diagram
A common AI-generated error is mixing Markdown explanation or triple backticks with Mermaid source. Paste only the code beginning with flowchart TD. Put punctuation or non-ASCII labels in quoted strings, such as B{"Information complete?"}, and place branch text on edges, such as B -->|No| C. Lowercase end has a special meaning in flowchart syntax; do not use it as a node ID. Use Finish or another name instead. Check the official Mermaid flowchart syntax for details.
If the graph renders but feels crowded, shorten visible labels before removing decisions. Put policy detail in accompanying prose. A large process can also be split into “submission and correction” and “approval and notification,” provided the handoff between the two diagrams is explicit.
Deliver the diagram and its editable source
Use the Live Editor to preview and export. If recipients work in Word, slides, or chat, send SVG or PNG and keep the .mmd source in a repository or knowledge base. An image alone makes the next policy change needlessly expensive. Online editors or shared links may carry the pasted process text, so redact employee data and unpublished internal policy, or render in an approved local environment.
Add a short text summary beside the diagram: “Incomplete requests are returned; complete requests go to the direct manager; requests longer than three days also go to the department lead after manager approval; either approver can reject.” Readers can then understand the main path even if the image fails to load. Have the policy owner confirm the rules before circulating the diagram; AI output and valid Mermaid syntax are not policy approval.
Five checks before publishing
- Every action and condition in the source rules appears in the graph, with no invented policy.
- Every decision has explicit exits, and boundary values such as exactly three days take the correct route.
- Correction returns to an actionable node; approved and rejected remain separate endpoints.
- Trace normal, rejected, incomplete, and boundary-value cases.
- Deliver SVG/PNG, editable Mermaid source, a text summary, and the policy owner and confirmation date.
The useful part of this workflow is not asking AI to “draw a chart.” It is converting prose into nodes and edges that a person can test. The more official a diagram looks, the more important those two minutes of path testing become.