Review a state model for reachable and contradictory behavior

A state model describes how a process changes after events. Its boxes can look complete while one state cannot be reached or two rules permit contradictory results. Review sequences as well as individual arrows. The following fictional practice model concerns an invented request process; it does not describe Kiguri implementation or prove that any software follows the model.

Define states, events, and persistent rules

Use four states: Draft, Submitted, Returned, and Closed. A new request starts in Draft. Submit moves Draft or Returned to Submitted only when required fields are complete. Return moves Submitted to Returned. Approve moves Submitted to Closed only when the review is accepted. Fields can be edited only in Draft or Returned. Closed has no further transitions in this model.

Record these rules in a transition register with starting state, event, guard, resulting state, and open question. Also write two invariants: every Submitted request has complete required fields, and every Closed request has an accepted review. These describe conditions that must remain true after each permitted event, not merely expectations for one example.

Trace reachability from the initial state

Follow Draft, Submit, Submitted to establish the ordinary path. Then follow Return to Returned, repair the fields, Submit to Submitted, and Approve to Closed after review acceptance. Each intended state now has an explicit route from the initial state under the stated conditions.

Suppose a diagram also contains Archived but no event leads there. Mark it unreachable under the current model. Ask whether it is a future state, an omitted transition, or a mistaken label. Do not draw an arbitrary arrow just to make every box reachable. A deliberately prohibited condition can be correct, while an intended state without a path is an unresolved modeling issue.

Inspect guards and repeated events

Give the group a deliberately faulty rule: Submit always moves Returned to Submitted, regardless of required fields. Trace a Returned request whose required field was removed during revision. The faulty rule produces a Submitted request with incomplete fields, violating the first invariant. Applying the same completeness guard to resubmission repairs that contradiction.

Next propose a second faulty rule that closes any Submitted request on Approve, even without an accepted review. It conflicts with the guarded approval rule and the Closed invariant. Remove or clarify the unguarded rule rather than trusting participants to choose the safer arrow. Also record what happens when Submit occurs twice: in this model it has no permitted transition from Submitted. Whether a future implementation ignores or reports it remains a separate requirement.

Replay terminal and return sequences

Try Return after Closed. Because Closed is terminal here, no permitted transition exists. If a stakeholder wants reopening, that request changes the model and needs an explicit event, authority, and invariant discussion. It cannot be smuggled into the existing Return arrow.

Replay the repaired resubmission sequence and check both invariants after every event. Legitimate cycles, such as returning and resubmitting, are different from a guidance flow accidentally looping forever. Record which sequence and guard revealed each problem so another reviewer can repeat the reasoning.

Preserve decisions the model cannot settle

Keep unresolved event behavior, intended states, and policy choices alongside the revised register. Ask another participant to trace the incomplete-field resubmission without narration. If they choose an incompatible arrow, the conditions remain unclear. The output is a coherent model with stated limits, not evidence of executed tests, passing code, or permission to change a live system.