What distinguishes regular, potentially irregular and irregular cases in a life-cycle state table, and how is each handled?
Regular cases are expected situations with a defined action and are processed automatically; potentially irregular cases are those where a machine cannot decide from the current data whether something is wrong, such as temporary intermediate states or situations needing manual intervention, and are reported as warnings; irregular cases are clear inconsistencies, such as a user with a company but no matching CRM entry, and are reported as errors.
* The deciding question is whether the current data alone settles it. *
The three-way split exists because synchronised systems are never perfectly in step:
- Regular: covered by a row of the table with a defined action (for example "new in the CRM, user known: add the company"). Handled silently.
- Potentially irregular: the data looks odd, but it may be legitimate. A CRM customer created a minute ago whose IdP user has no company yet may simply be waiting for the next sync run. Raising an error would be a false alarm, ignoring it could hide a failure, so it becomes a warning for a person to watch or resolve.
- Irregular: the data contradicts the model no matter when you look. A user with a company has, by construction, been created or enriched from a CRM customer; if no such customer exists, something went wrong (a missed deletion, a manual edit, a broken e-mail change). It is reported as an error.
Modelling these explicitly is what separates a robust LCP from a happy-path one: the regular rows tell the program what to do, the irregular rows tell operations what to look at.
Go deeper:
Eventual consistency (Wikipedia) — why replicated systems pass through temporary intermediate states that are not errors.