QUICK ANSWER
What should a decision tree template include?
A reviewable decision tree template should include a narrow purpose and boundary, one root question, evidence or assumptions for every question and branch, distinct branch labels, neutral terminal states, role ownership, external handoffs, revision history, and an accessible text alternative. It should validate graph integrity without recommending, approving, scoring, diagnosing, predicting, or executing any path.
A decision tree should make a bounded set of questions, branch conditions, evidence, assumptions, and terminal states inspectable before anyone makes a consequential decision. The tree is useful when it records how inputs separate possible paths without quietly becoming a recommendation, approval, score, automated workflow, diagnosis, or prediction.
This downloadable pack keeps one canonical fictional JSON tree in parity with an editable Mermaid view, an accessible SVG, and a visible structured long description. A closed Draft 2020-12 schema, dependency-free semantic validator, 152-test mutation suite, and deterministic ZIP builder make structural drift and unsafe states easier to find.
Build a neutral tree from one reviewable source
Start with the question boundary and supporting evidence, then make the graph, terminal meanings, accessible description, and machine-readable contract agree.
State the narrow question and authority boundary
Describe what the tree records before a later decision and list what it cannot do. Common decision-tree templates begin with a question and branch into possible paths, but this artifact keeps recommendations, approvals, authorization, scoring, and outcomes outside the tree.
Sources: [decision-tree-pack], [microsoft-decision-tree], [atlassian-decision-tree]
Connect every question and branch to a basis
Give each question at least one reviewed evidence reference or explicit assumption. Give each branch a condition note and basis reference so reviewers can distinguish observed support from an unvalidated gap.
Keep the graph a strict rooted tree
Use one question root, exactly one incoming branch for every other node, at least two distinct outgoing branches for each question, and no outgoing branches from terminal nodes. The semantic validator also rejects cycles, disconnected nodes, duplicate IDs, and depth or fan-out beyond the documented limits.
Sources: [decision-tree-pack], [microsoft-decision-tree], [mermaid-flowchart]
Describe neutral terminal states and handoffs
End a path with information needed, an external-review handoff, a candidate path, or stop-and-escalate. An external-review terminal points to a separate record; it does not contain the specialist conclusion or inherit that record’s authority.
Sources: [decision-tree-pack]
Project an editable diagram and accessible visual
Generate the Mermaid source, SVG, and visible structured long description from the same validated JSON. Mermaid documents editable flowchart syntax, while W3C guidance for complex images supports providing both a concise alternative and a complete long description.
Sources: [decision-tree-pack], [mermaid-flowchart], [w3c-complex-images], [wcag-22], [svg-2]
Close the data contract and test semantic failures
Use a closed Draft 2020-12 schema for object shapes and a dependency-free validator for graph, reference, handoff, revision, fictional-data, safe-rendering, and false-authority invariants. Mutation tests should prove invalid changes fail rather than only proving the example passes.
Sources: [decision-tree-pack], [json-schema-2020-12]
Review parity before sharing the pack
Regenerate every projection, compare source and public bytes, rebuild from a clean extraction, inspect the visible text alternative, and record the reviewed revision. This confirms artifact integrity only, not whether a branch is correct for a real decision.
Sources: [decision-tree-pack], [w3c-complex-images], [wcag-22]
The neutral pre-decision boundary
Use this owner to document reviewable branching questions and possible paths. Keep decisions, delivery behavior, specialist conclusions, and consequential automation with their accountable systems.
Included
- One rooted question tree with evidence, assumptions, distinct branch conditions, neutral terminal states, role ownership, external handoffs, revision history, and structural review
- Canonical JSON, closed Draft 2020-12 schema, editable Mermaid, accessible SVG, visible structured long description, dependency-free projector and validator, and mutation tests
- Fictional low-stakes documentation-readiness example using reserved URLs, role identifiers, safe relative paths, and false authority boundaries
Not included
- Recommendation, selection, approval, rejection, authorization, qualification, eligibility, ranking, score, weighted decision matrix, or build-versus-buy conclusion; use the accountable decision record or comparison owner
- Process definition, procedure, runbook, workflow state, execution engine, roadmap, schedule, orchestration, or automated action; use the process-map, workflow, project-plan, or operational owner
- Root-cause diagnosis, fault analysis, medical, legal, financial, employment, insurance, credit, education, housing, safety, or other regulated or high-stakes decision
- Machine-learning classification, prediction, personalization, autonomous routing, production policy engine, or guaranteed business or user outcome
DOWNLOADABLE RESOURCE
Download the decision tree template pack
Start with the Markdown worksheet, inspect the fictional example and visible long description, then replace every role, evidence reference, assumption, branch condition, and handoff with reviewed low-stakes information.
Decision tree template pack
A neutral pre-decision branching pack with one canonical graph and deterministic editable, visual, accessible, and machine-readable views.
Format: Markdown, JSON, JSON Schema, Mermaid, SVG, projector, validator, and tests in one reproducible ZIP archive
Locally reproduced August 1, 2026. SHA-256: ae4076a0853b0c26054d0d2a028447baf8f168b43591673d5a54072cf083fce7
Included
- Editable Markdown worksheet and completed fictional documentation-readiness example
- Canonical JSON, closed Draft 2020-12 schema, editable Mermaid, accessible SVG, and visible structured long description
- Dependency-free deterministic projector, semantic validator, 152-test mutation suite, exact manifest, and reproducible ZIP builder
Verification boundary
Validated the fictional graph, ran 152 deterministic positive and negative tests, regenerated all three views from canonical JSON, checked closed object shapes and semantic references, copied an exact flat-file allowlist, rebuilt from clean extraction, and reproduced the same ZIP bytes across time zones.
Four bounded decision tree patterns
Keep the same evidence, graph, accessibility, and authority contract while adapting questions and terminal states to a low-stakes documentation need.
Documentation-readiness tree
Use when: A guide owner needs to record whether source evidence, specialist review, and a complete text alternative are present before a separate publication review.
Ask evidence, specialist-review, and text-alternative questions in sequence; end in an information need, external handoff, or candidate review path.
Structure
- Reference the evidence policy or explicit assumption behind each question
- Keep the publication decision outside the tree and link a specialist handoff to its separate record
Watch for: A candidate publication-review path is not publication approval, factual acceptance, accessibility certification, or release authorization.
Sources: [decision-tree-pack], [w3c-complex-images], [wcag-22]
Content-intake completeness tree
Use when: A documentation team needs to record which source, audience, rights, or format input remains missing from a low-stakes content request.
Branch on the presence of required inputs and terminate with a named information need or neutral handoff rather than accepting or rejecting the request.
Structure
- Use distinct condition labels tied to a maintained intake requirement
- Record missing information without assigning priority, score, eligibility, or delivery status
Watch for: An intake tree does not define the production workflow, schedule work, authorize access, or judge the requester.
Diagram text-alternative review tree
Use when: An author needs to record whether a complex diagram has concise alternative text, a complete visible description, and parity after a revision.
Ask observable documentation questions and end with the missing text input, an accessibility-review handoff, or a candidate path to a separate content review.
Structure
- Keep the full path narrative visible outside the image
- Regenerate the SVG title and description from the same validated graph record
Watch for: The tree records documentation checks only. It does not certify WCAG conformance or replace testing with users and assistive technology.
Sources: [decision-tree-pack], [w3c-complex-images], [wcag-22], [svg-2]
Technical-note evidence triage
Use when: A maintainer needs to show which evidence category or external specialist record a technical note needs before a later review.
Branch by documented evidence presence and claim category, then record a missing input, neutral external handoff, or candidate review path.
Structure
- Use stable role IDs and reserved example URLs in portable examples
- Preserve the tree revision and regenerate every projection after editing the canonical JSON
Watch for: Evidence triage does not diagnose a defect, determine root cause, recommend a fix, define a runbook, or execute a workflow.
Sources: [decision-tree-pack], [mermaid-flowchart], [json-schema-2020-12]
Keep each branch inside the artifact boundary
Use these placement rules to decide what the tree may record and what must remain in a separate accountable owner.
A question has no reviewed fact or explicit assumption behind it.
Choose: Add the narrow evidence or assumption reference, including the gap and validation method, before preserving the branch.
Tradeoff: Some branches remain incomplete, but an unsupported prompt cannot present itself as a documented rule.
A terminal label declares an option approved, rejected, eligible, best, safe, or guaranteed.
Choose: Replace it with a neutral information-needed, external-handoff, candidate-path, or stop-and-escalate state and link the accountable decision record.
Tradeoff: The tree stops short of a conclusion, but authority and reasoning stay with the governed decision owner.
The tree begins tracking work status, assignees, retries, automated actions, or process execution.
Choose: Retain only the pre-decision questions and hand off execution state to the process, workflow, runbook, or application owner.
Tradeoff: Readers follow a linked record for execution, but the diagram cannot silently become an operational system.
A branch would affect a person’s rights, access, safety, eligibility, or regulated treatment.
Choose: Stop using this informational template for that branch and move the decision to an appropriately governed human and system review.
Tradeoff: The generic artifact no longer covers the case, which preserves the necessary high-stakes controls and accountability.
START WITH A REVIEWABLE TREE
Download the decision tree pack and inspect every path
Replace the fictional roles, reserved sources, assumptions, questions, branch conditions, and handoff. Keep every terminal neutral and regenerate the editable, visual, and text views from canonical JSON.
Download the decision tree template packThe ZIP is locally reproduced. Public availability and adapted evidence require separate verification.
Use the decision log for the accountable conclusionThis decision-tree owner stops at neutral possible paths. The decision-log owner records the later accountable choice, evidence, rationale, owner, and follow-up.
What a valid tree cannot establish
Structural validation makes the graph and its references reviewable. It cannot establish that a premise, branch, or downstream decision is correct.
- The validator checks closed shapes, formats, references, graph integrity, handoff coverage, revisions, safe rendering text, and false authority flags. It does not authenticate evidence or judge whether the modeled questions are appropriate.
- A reviewed evidence link can still be stale, incomplete, biased, or inapplicable. A real adaptation needs accountable source review and an explicit update cadence.
- The projector preserves deterministic parity across JSON, Mermaid, SVG, and the long description. It does not prove that a changed visual is understandable in every target context.
- The SVG includes a programmatic title and description, but the visible structured Markdown remains the detailed text alternative. Final content still needs appropriate accessibility review and testing.
- A neutral external handoff path does not prove that specialist review occurred, is current, or carries authority for a later decision.
- This pack is not suitable for production automation, scoring, diagnosis, prediction, safety decisions, or regulated decision-making, and it offers no outcome guarantee.
- This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.
Current primary sources and verification record
The same-release pack is the direct source for its original model, fictional example, projections, validator, tests, and archive. Current official references support basic tree notation, editable flowcharts, complex-image alternatives, accessible SVG semantics, and the closed schema family. No external template language was copied.
[decision-tree-pack] Playcode:Decision tree template fictional example
Checked August 1, 2026. Supports: The locally reviewed graph model, fictional example, neutral boundaries, generated views, validator behavior, mutation tests, and reproducible archive. Public availability remains unverified until deployment.
[microsoft-decision-tree] Microsoft Support:Create a decision tree
Checked August 1, 2026. Supports: Current official description of decision trees as question-based diagrams whose answers lead to possible conclusions, including branch labeling and adding shapes and connectors.
[atlassian-decision-tree] Atlassian:Decision tree template
Checked August 1, 2026. Supports: Current official overview of mapping options and outcomes from an initial question and documenting factors used in the analysis. This page narrows that pattern to neutral pre-decision documentation.
[mermaid-flowchart] Mermaid:Flowcharts syntax
Checked August 1, 2026. Supports: Current official syntax for editable flowchart nodes, links, labels, directions, shapes, and styling used by the generated Mermaid projection.
[w3c-complex-images] W3C Web Accessibility Initiative:Complex images tutorial
Checked August 1, 2026. Supports: Current guidance that complex images need a concise alternative plus a complete long description, with the detailed description available in the surrounding content or a linked location.
[wcag-22] World Wide Web Consortium:Web Content Accessibility Guidelines 2.2
Checked August 1, 2026. Supports: Current normative success criteria relevant to text alternatives, meaningful structure, non-text contrast, and accessible target content. This page does not claim conformance.
[svg-2] World Wide Web Consortium:Scalable Vector Graphics 2
Checked August 1, 2026. Supports: Current SVG structure and semantics, including title and description elements used in the generated accessible image.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The current specification family declared by the bundled closed schema. Graph, cross-reference, handoff, revision, safe-rendering, and boundary rules remain in the semantic validator.
Decision tree template questions
What is a decision tree?
A decision tree is a branching diagram that begins with a root question and follows labeled conditions to later questions or terminal states. In this template, the tree records neutral possible paths before a separate decision. It does not itself select, approve, score, authorize, diagnose, predict, or execute a path.
What files are included in the decision tree template pack?
The ZIP includes a Markdown worksheet and fictional example, canonical JSON, a closed Draft 2020-12 schema, editable Mermaid, accessible SVG, visible structured long description, dependency-free projector and semantic validator, 152-test mutation suite, exact manifest, and deterministic archive builder.
Why is the JSON the canonical decision tree source?
One canonical source prevents the editable diagram, visual, and text alternative from drifting independently. The projector validates the JSON before regenerating all three views, while tests compare generated bytes with the checked-in files. Reviewers can inspect both graph semantics and presentation parity.
How is the SVG decision tree made accessible?
The SVG includes an image role, programmatic title and description, and named groups for each question and terminal. The pack also supplies a visible Markdown long description containing every root-to-terminal path, node meaning, owner role, evidence reference, assumption, and boundary statement.
Can this template recommend or approve an option?
No. Terminal states are limited to information needed, external-review handoff, candidate path, and stop-and-escalate. The validator rejects common authority and outcome language, requires all boundary flags to remain false, and keeps any later decision in a separate accountable record.
Can I use this decision tree as a workflow or policy engine?
No. The pack documents static pre-decision branching logic. It has no execution state, retries, assignment queue, access control, automation, or side effects. Use a governed process, workflow, runbook, or application owner for operational behavior, and keep this artifact as reviewable context.
Can Playcode help present a decision tree on a website?
Playcode can help build and iterate a website that presents reviewed low-stakes documentation and accessible alternatives. Keep evidence approval, specialist conclusions, accessibility testing, production automation, consequential decisions, access, and release authority with their accountable owners, and verify the actual target experience.
PRESENT REVIEWED DOCUMENTATION
Turn a bounded tree into a website people can inspect
Give Playcode the reviewed questions, evidence, branch conditions, accessible descriptions, content, and visual direction. Verify the target experience, facts, accessibility, access, and release state before publishing.
Build and review your websiteThis ordinary informational article does not grant AI signup credits. No recommendation, approval, accessibility conformance, launch, ranking, conversion, revenue, or other outcome is guaranteed.