The old way. Workflow configuration lives on a screen called "Status Workflows": a paginated table of rows, each row a (note_type, note_area, from_status, to_status, role, evidence) tuple. You scroll, you sort, you guess. Which statuses are actually reachable from "Open"? Are there orphan statuses that no transition leads into? Did the same rule get created twice with different role permissions when two team leads filed separate requests last quarter? The data answers all three questions; the table doesn't surface any of them. New hires read the table for thirty minutes and still ask their manager to draw the workflow on a whiteboard.
What ISPCQ does. Status workflows are drawn as a directed graph: each status is a node, each allowed transition an edge. To create a transition you drag from one node's port to another — a pre-filled form opens with the source and target already set. Inherited transitions from broader scope (type-global rules, default-type-this-area rules, the global default) are ghosted in so you can see what's already true here before redefining anything. System transitions (Close-Error, Reopen) are visually locked so nobody breaks the integrations that depend on them. Per-(type, area) layout is persisted — once you've arranged the graph the way you understand it, it stays that way for everyone.
The operational outcome. Orphan statuses and dead-end paths are caught the first time someone opens the editor — not three months later when a ticket gets stuck. New hires understand the workflow by looking at it. The list view stays as a fallback for power editing; the graph is the default because it's how humans actually think about state machines.
