Lifecycles, events and invariants

1. Define the object and its accompanying information

A team is specifying instruction handling for a fictional service. For each instruction, it needs to know whether amendment, validation, commitment or cancellation is still allowed. First establish the unit of analysis: one instruction whose identity remains stable throughout the sequence.

Mapping several teams' activities can help explain the process; deciding what one instruction permits at a given moment also requires its state. In this exercise, the complete state contains phase, revision, validatedRevision and commitments.

The phase is draft, open, committed or cancelled. Revision identifies the content version; validatedRevision records the version whose validation was completed. The commitments list records commitments emitted by the model.

An instruction starts in draft at revision 1, with no validation and no commitments. Creation is outside the event sequence. Every subsequent event belongs to the same instruction.

These choices bound the problem: the workshop does not establish customer identity, user permissions, message transport or persistence. Record such boundaries alongside a business model. A visually simple diagram may require several data fields to support a correct decision.

2. Write the event, condition and effect separately

Each rule needs an origin, a recognized event, a condition and a defined effect. In the fictional contract, submit in draft opens the instruction. In open, validate sets validatedRevision to the current revision.

This event represents completed confirmation; requesting validation and the time taken to perform it are outside the model. Also in open, amend increases revision from 1 to 2 while retaining previous validation evidence. Commit is permitted in open only when validatedRevision equals revision.

It changes the phase to committed and appends a commitment record. Cancel in open terminates the instruction in cancelled. A second commit in committed returns already-committed and retains every field.

Any recognized event outside these conditions returns not-permitted without changing the state. An action's outcome and the resulting phase are therefore separate concepts. A disallowed attempt does not automatically create a rejected phase.

When a stakeholder uses words such as approved or processed, ask for an observable definition: what evidence exists, which version it concerns, what changed and which actions become permissible?

3. Retain the information needed for the decision

Compare two sequences from the initial state. The first is submit, validate, amend. It ends in open at revision 2, with validatedRevision equal to 1.

The second is submit, amend, validate. It also ends in open at revision 2, but validatedRevision is 2. A screen displaying only open gives both cases the same label.

The model permits the next commit only in the second case. This difference shows why phase alone is insufficient. The distinction can be represented through sufficiently precise states or through data and explicit conditions.

The workshop uses the latter approach. Retaining validation of revision 1 explains the history without establishing validation of revision 2. Avoid a boolean that continues to say validated after every amendment unless an additional rule makes its meaning unambiguous.

This workshop permits only one amendment. The revision-2 limit makes exploration finite; a real application needs its own decision about further amendments. That limit does not come from a business-analysis recommendation.

4. Compare orders and handle lifecycle termination

Event order is part of the requirement. In submit, cancel, validate, commit, cancellation occurs before any commitment exists. The next two actions return not-permitted, leaving the instruction cancelled with no commitments.

In submit, validate, commit, cancel, commitment already exists when cancel arrives. Cancellation is disallowed, leaving the instruction committed with one commitment. This contract contains no reversal rule.

If the business needs to undo a commitment, that behavior requires a specification of effects and responsibilities. Adding an arrow from committed to cancelled does not define what happens to the earlier commitment. To study ordering, write the complete state after each event and identify the first relevant difference.

A disallowed intermediate attempt can retain the state, allowing a later valid action to succeed. For example, submit, commit, validate, commit ends with one commitment: the first commit lacks validation, validate supplies the evidence and the second commit applies the rule.

These events are serialized. Their comparison does not establish the behavior of simultaneous operations in a distributed system.

5. Look for overlapping conditions and gaps

Now consider a small table separate from the executable workshop. An open instruction receives route with an integer amount from 0 to 12,000 euros. The fictional policy requires review up to and including 10,000 euros and escalation above that amount.

The first proposed row says amount <= 10,000, target review; the second says amount >= 10,000, target escalate. Both rows apply at 10,000. Without a priority rule, the table provides no unique target.

Making the second condition strictly greater than 10,000 preserves the policy. If both conditions were strict, no row would apply at 10,000. Use boundary values and values within each interval to distinguish overlaps from gaps.

Also check whether each row's origin can be reached. A transition can have a satisfiable condition while starting from a phase that is never reached from the initial state. A table giving one answer for every amount can still route everything to the wrong business destination.

Structural review and confirmation of intent by responsible stakeholders therefore provide different evidence. These numerical conditions belong only to this teaching example.

6. Check invariants over effects

The contract specifies three conditions to preserve: an instruction emits at most one commitment; each commitment uses validation of the revision it commits; and a cancelled instruction has no commitments. The effects list is needed to check these conditions.

One defective variant repeats the effect whenever commit arrives in committed. The final phase remains committed after two calls, but the list contains two records. A test checking only the final label misses that error.

Another variant accepts any earlier validation while the instruction is open. After submit, validate, amend, commit, it emits a commitment of revision 2 using validation of revision 1. Recording the pair in the effect makes the failure demonstrable.

Each variant changes a single rule to support a controlled comparison. Preserving invariants also does not establish progress: a model blocking every commit may never duplicate a commitment while failing the need to process valid instructions.

Add permitted-progress examples alongside prohibition examples. These invariants are explicit fictional agreements, not universal payments or certification policies.

7. Explore the model and interpret the evidence

The lesson materials let you edit sequences and compare the baseline contract with the two variants. Before running them, calculate a short trace manually and write its expected initial state, event, outcome, next state and accumulated commitments.

Submit, validate, amend, commit requires four steps and ends without a commitment under the baseline policy. The stale-validation variant provides a counterexample to the revision invariant. For duplication, use submit, validate, commit, commit and count effects.

When the explorer enumerates sequences, its universe is determined by the five-event alphabet and selected depth. A search through four events does not establish a result for every longer sequence. The workshop supports depths through six and retains revisions 1 and 2.

Compare declared coverage with any rules you change; another event or revision changes the universe. Execution demonstrates behavior of that model and those data. It does not establish message delivery, concurrency, transactions, permissions or recovery of a real service.

Downloadable instructions and solutions explain how to repeat the experiments and interpret each result.

8. Turn the model into a useful review

Bring a small set of discriminating traces to review: current validation followed by commitment, amendment after validation, repeated commitment and cancellation before or after commitment. For each trace, show the applicable rule and expected evidence, including effects.

Ask responsible stakeholders to confirm outcomes and boundaries: who recognizes completed validation, which amendments invalidate it, what constitutes a business commitment and what recovery needs its own lifecycle? A contradiction-free table can still misrepresent those needs.

Record disagreement as an open question with an owner and impact before silently choosing one interpretation. If the existing system stores only phase, identify the additional information needed to distinguish the lesson's two open states. If operations require reversal, specify that behavior with its own criteria.

To close the review, connect accepted examples to the rules and assumptions supporting them. A change to those assumptions should identify which examples need reconsideration. The resulting artifact should let business, development, testing and support explain the same decision using the same context.

Common pitfalls

Storing only the phase name; turning a disallowed attempt into a new phase without a rule; retaining a validation boolean after amendment; checking final state without counting effects; adding cancellation without defining the fate of an earlier commitment; presenting bounded enumeration as proof of a real system.