Regions, History and Deferred Events in a 900-State Claims Machine

Every Transition has a container Region, and in UML 2.5.1 the source and target vertices of a transition must lie in that region; a transition may not connect a vertex in one orthogonal region to a vertex in another. Deleting the regions "fixed" the diagram by destroying the concurrency the model needed - ADJ and FRAUD were meant to run in parallel.

Legal encodings:

1. Fork into the regions. Put a ForkPseudostate at the boundary (or inside the composite) with one incoming transition from the triggering state and outgoing transitions into each region. This is the standard idiom for entering several orthogonal regions at chosen vertices and it preserves concurrency.
2. Enter through an entry point. Define an entryPoint pseudostate on the composite Adjudication, transition from Review to that entry point, then from the entry point to Escalate in FRAUD. A transition outside a composite may target the state or one of its entry points, which lets you name the region and the vertex entered.
3. Leave through an exit point. The mirror image: an exitPoint on the composite, an internal transition from the region vertex to it, then the external transition.

For "a fraud suspicion moves the case", the honest reading is usually not a move but an effect: the case stays in ADJ while FRAUD fires a trigger that drives Escalate, or Review completes and Adjudication is exited and re-entered through the fork with the FRAUD configuration. Decide which semantics the business wants before choosing the encoding - a fork preserves the other region, exit and re-entry does not.

Shallow history (HistoryPseudostate with kind = shallow) restores only the most recently active direct substate of the composite. If that substate was itself composite - say Approve contains CheckLimits and Post - the machine re-enters Approve at Approve's initial pseudostate, so Post is lost. That matches the symptom: the resumed case restarts at a coarser granularity than where it stopped.

Deep history (kind = deep) restores the full nested configuration down to the leaves, so Post is reinstated. Use deep history on Adjudication if the case must resume exactly; keep shallow history deliberately where the rule is "restart the approved branch from its beginning".

Entry/exit ordering, which drives the audit log:

• On leaving a configuration, exit behaviours run innermost first, outermost last.
• On entering, entry behaviours run outermost first, innermost last.
• With history, the restored states are re-entered, so their entry behaviours run again; do-activities restart, they are not resumed from where they were suspended.
• History pseudostates compose: a deep history restores nested configurations, and each restored composite re-enters according to its own history pseudostate (or its initial pseudostate if it has none).

Expected log for one suspend-and-resume cycle across Adjudication/Approve/Post: exit(Post), exit(Approve), exit(Adjudication), then entry(Adjudication), entry(Approve), entry(Post). If the log shows only Review, the history kind is shallow, or the composite has no history pseudostate and the default initial-pseudostate rule applied.

A State may list event types as deferred. While that state is active, an occurrence of a deferred type that would otherwise be discarded - no enabled transition in the current configuration consumes it - is retained in the event pool rather than lost, and it is re-offered once the configuration changes so the event is no longer deferred. Deferral is a fallback for events that would otherwise be thrown away; it is not a per-state queue and it does not block dispatch of other events.

Likely causes of the loss:

1. A competing trigger. The same event type also triggers a transition in another active region or in an ancestor state; an enabled transition consumes the event, and the deferral never applies.
2. Event type mismatch. Deferring a SignalEvent named PaymentReceived does not defer a CallEvent or a TimeEvent of the same name - the types are distinct and deferral is per type.
3. Completion events. A completion event is generated by the state machine itself, not queued as an external occurrence, so declaring it deferred is silently meaningless.
4. Engine non-conformance. Some simulators implement deferral only within a single region or drop deferred occurrences when the state is exited. Check the engine's event-pool behaviour against the standard before changing the model.

Fix: defer the exact event type, verify no other trigger in the active configuration consumes it, and add an audit assertion that a deferred occurrence is either consumed by a transition after resume or explicitly discarded - never silently dropped.