DOT-Graph Decision Flow Embedded in Prompt

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Route issues to reproduction, planning or clarification. Teaching A reports observable failure, B requests new behavior and C only says improve experience. Completion needs evidence/scope, not merely a selected state name.

Mechanism

Define exclusive conditions, ambiguous/conflicting cases, re-entry and terminal evidence, then express a small DOT graph. Follow satisfied edges; clarification waits for an actual answer before re-entry. Explain node exits beside the graph rather than decorative arrows.

Bad example

Triage A/B/C appropriately and ask if unclear. Mark done without answers or selection evidence.

Good example

Use the teaching DOT flow:
digraph triage {
  done [shape=doublecircle];
  start -> reproduce [label=observed_failure];
  start -> plan [label=new_behavior];
  start -> clarify [label=ambiguous_or_conflicting];
  clarify -> start [label=actual_answer_received];
  reproduce -> done [label=evidence_recorded];
  plan -> done [label=scope_recorded];
}
A/B select reproduce/plan; C stays clarify until answered. Reach done only after evidence or scope is recorded. This completes triage, not implementation.

Why the change matters

Named edge conditions make transition reasons inspectable and define waiting/re-entry. Terminal evidence distinguishes choosing a flow, finishing triage and completing development.

Observable expectation

Teaching A→reproduce, B→plan and C→clarify. An actual new-behavior answer moves C back through start→plan. No answer stays clarify; no scope record means not done.

Check conditions and terminal meaning. Valid DOT syntax alone does not prove runtime adherence.

Limits

Use small graphs for clear flows and separate complex exceptions when needed. DOT supplies neither execution engine nor authorization/exclusive predicates. Branch labels are teaching choices rather than upstream commands.