A dispute team can meet every deadline it measures and still miss a notice that never entered the investigation queue. The question is whether its checks follow every route a valid notice can take, including the route created when a customer leaves a secondary form incomplete.
Our Dispute Workflow Verification demonstration makes that question concrete. Its post-forms case is a synthetic reconstruction inspired by the form-routing failure described in the Consumer Financial Protection Bureau's October 2024 Apple consent order. It is a modeled workflow, not Apple's actual state machine or a replay of customer disputes. The case asks what happens when the initial billing-error notice is treated as valid, but the missing secondary form sends it to a closed state.
The route a dashboard can miss
In the supplied model, a consumer submits a notice through Messages on model day 0. The workflow requests a secondary form on day 1. If that form is not completed, a timeout moves the case to ClosedIncomplete on day 6. That state has no outgoing route to investigation. A different branch, where the form is completed, continues through routing, acknowledgment and investigation.
The distinction matters because a tracker built around cases that enter the normal queue can accurately describe those cases while saying nothing about the notice that exited before the queue. The modeled happy-path baseline reports COMPLIANT; the state explorer finds a counterexample. Those outputs answer different questions. One follows the expected route. The other asks whether any reachable valid-notice state can become trapped without an investigation route.
In the synthetic workflow graph, the red branch reaches Closed Incomplete. The completed-form route continues toward investigation.
This is the useful unit of review: a path, not a status color. The checker explores 93 reachable states in this supplied model and marks four configured properties with counterexamples. The first finding is structural. A valid notice reaches a terminal state from which investigation cannot be reached. The other findings concern the model's acknowledgment, resolution and example network-window checks on that same branch. They do not mean a real institution breached four legal duties.
The model's expected-route baseline says COMPLIANT. The state check flags the reachable branch that baseline did not explore.
What the counterexample lets a reviewer ask
An overall failing verdict tells a reviewer where to look. The ordered trace explains why. It starts with submission, records the secondary-form request, then shows the timeout closing the case on model day 6. The finding is therefore more precise than “some deadline was missed.” The workflow removed the case from any route to investigation before the modeled acknowledgment and resolution flags were satisfied.
The event trace shows the specific modeled sequence that ends at ClosedIncomplete without investigation.
That sequence gives operations, compliance and engineering reviewers a sharper design question: does the real intake channel create an obligation before the secondary form is completed, and what actually happens when that form times out? If the answer differs from the model, the model should change. If the answer matches, the route deserves attention even if the queue's resolved-case metrics look healthy.
The comparison also shows why a proposed repair should be checked as a workflow change, not just as a new instruction to staff. In the supplied remediated model, an incomplete secondary form still routes to investigation. The checker finds all four configured properties PROVEN across that model's 153 reachable states. That result is evidence about the revised model. It does not establish that a production system has been changed, that its data matches the model, or that a regulator would reach the same conclusion.
The boundary that makes the result useful
The demonstration uses finite JSON state models and deterministic state exploration. Its rule checks are simplified, including a calendar-day ceiling in place of Regulation Z's two-complete-billing-cycles requirement and an illustrative network window. The CFPB's Regulation Z text sets the actual notice conditions and timing procedures; this demonstration does not decide their applicability to a real case. The proof certificate records the model, checked properties and limitations for review.
For a real workflow, the hard work is to establish that the model represents actual intake channels, timeout behavior, handoffs and applicable obligations. Only then can a path finding guide a control decision. The full breakdown shows the synthetic example and its limits. The practical test is to trace a valid notice from receipt through every branch, especially the branches that never appear in the investigation queue.