Flowchart Generator

Direction{{ resultsReady ? directionLabel : '—' }} Decisions{{ resultsReady ? computation.values.decision_count : '—' }} Validation{{ resultsReady ? 'Passed' : 'Review' }}

Reading direction:

Top to bottom suits process documents; left to right suits wide screens and slides.

Flowchart definition:

Use id [type]: Label and from -> to: Label. Edits are mirrored into the page URL; avoid sensitive process text.

Definition syntax

Node types are start, process, decision, and end. Use # for comments. Limits: 30 nodes and 60 connections.

Review note:

Neutral when blank. A note appears only in the process ledger and its exports.

Scroll the preview horizontally to inspect wide branches at readable size.

The chart renderer is unavailable. Exact node types remain available in the process ledger.

Kind	ID / path	Type	Label / detail	Copy
{{ row.kind }}	{{ row.id }}	{{ row.type }}	{{ row.label }}

A process becomes difficult to review when its steps and decisions live only in prose. A flowchart turns that description into nodes and directed connections, making alternate routes, missing handoffs, and dead ends visible.

The shapes have simple jobs. Rounded start and end nodes mark the boundaries, process nodes describe work, and decision diamonds split the path according to labelled outcomes. Arrows establish direction; their order on the page is secondary to the source and destination they connect.

Start: An entry point from which every included step should be reachable.
Process: An action, handoff, or state change that moves the work forward.
Decision: A question or condition whose outgoing connections should name the alternatives.
End: A valid finishing point that every included route should be able to reach.

Direction affects readability rather than process meaning. Top-to-bottom diagrams fit procedures and documents, while left-to-right diagrams often fit slides and wide screens. A dense graph can remain hard to understand in either direction, so a useful chart keeps labels short and separates truly different processes.

A valid flowchart proves that the written graph follows the accepted rules. It does not prove that the real process works that way, that every exception is present, or that a decision has the right policy. Review important diagrams with the people, logs, procedures, or controls that describe the actual work.

How to Use This Tool:

Define the nodes first, then connect them into complete routes from a start node to an end node.

Choose Top to bottom for a vertical procedure or Left to right for a wider presentation.
Write each node as id [type]: Label, using start, process, decision, or end as the type. Keep every identifier unique.
Connect nodes with from -> to. Add a short label after a colon for decision outcomes such as Yes and No.
Correct the first reported line when a node is missing, duplicated, unknown, unreachable, self-connected, or unable to reach an end.
Compare the SVG with the Node mix and Process ledger. Use the optional Review note for context that belongs with the ledger rather than inside the diagram.

Interpreting Results:

Read each route from its start node to an end node and check decision labels where the path splits. Curved return connections may represent loops, but the renderer does not infer repeat conditions or stopping rules that were not written.

Node and connection counts describe diagram structure. They do not measure duration, workload, cost, risk, or process quality.
A decision count shows how many decision nodes exist, not whether each decision has two branches or uses complete outcome labels.
A successful render confirms reachability under the accepted graph rules. Compare the ledger with the intended process before sharing the chart as approved documentation.

Technical Details:

The definition is a bounded line grammar, not a general diagram language. Blank lines and lines beginning with # are ignored. Every other material line must declare one reading direction, one node, or one directed connection.

Rule Core:

Accepted flowchart grammar and graph rules
Element	Accepted form	Required rule
Direction	`direction: TB` or `direction: LR`	At most one declaration; top to bottom is the default.
Node	`id [type]: Label`	The ID starts with a letter, remains unique, and is at most 32 characters. Labels are at most 80 characters.
Connection	`source -> target: Label`	Both IDs must exist. Self-connections and repeated source-to-target pairs are rejected; labels are at most 40 characters.
Graph boundary	At least two nodes and one connection	At least one start and one end are required.
Reachability	Forward and reverse graph walks	Every node must be reachable from a start and must be able to reach an end.

A definition may contain up to 20,000 characters, 30 nodes, and 60 connections. The optional review note is limited to 240 characters and does not become a diagram node.

Transformation Core:

Validated lines become a normalized node-and-connection graph. Nodes are grouped into levels by their distance from a start, then arranged vertically or horizontally. Start and end nodes render as rounded shapes, processes as rounded rectangles, and decisions as diamonds. Connection labels remain text, and labels are escaped before the inert SVG is assembled.

The SVG includes an accessible title and description derived from the validated graph. Long node labels wrap to four visual lines, with additional text shortened in the drawing; the complete validated label remains available in the process data.

Privacy Notes:

The definition is parsed without executing its text, but the definition and review note are mirrored into the page address. Do not enter secrets, customer data, internal incident details, or other sensitive process text that should not appear in browser history, copied links, logs, or shared screenshots.