PM-CND-0050

A Condition MUST be evaluated against the prospective post-transition image of the object: the State the Operation would achieve, not the State the object currently holds. An implementation MUST evaluate Conditions before the object data is stored, and MUST NOT store that data when a Condition does not hold.

Non-normative. This makes a Condition a genuine postcondition contract on an Operation rather than a re-check of what was already true, which is what PM-DRV-0030 already implied about Derivations guaranteeing their target State.

The description's own worked example settles the reading beyond argument: the Condition Validate First Name declares that the property firstName is required for achieving the Created Candidate State, and returns the message "First Name is a required property of Candidate" when it does not hold. A pre-image reading cannot express that — at evaluation time the instance is precisely the one that does not yet satisfy the target State.

The graphical notation says the same thing in one line: Conditions "are used like gates between the Operations and the States to be achieved" (PAT:us9378071b2#para-2056), which is also where the blog's "gate" wording in PM-CND-0010 comes from.

Ordering consequence, and the reason this matters for the kernel: Derivations run before Conditions. A Derivation that supplies a default value is part of the image a Condition then validates, so a Condition cannot be evaluated until the Derivations for that Authorization have been applied. That ordering is now forced, not chosen.

The blog's worked Condition table (IMG:conditions-validates-state) agrees, and its column headings make the point on their own: a Condition is validatedAgainst a State, and every message names the transition being attempted rather than the object's current situation — "required for instantiating a new Artist", "required for creating an Artist", "required for activating an Artist". A Condition on New Artist cannot be a check on an Artist that is already New; there is no such object yet.

The table also shows a Condition Type column with values Error and Warning (IMG:conditions-validates-state#r12c6). A Warning Condition that does not hold apparently does not invalidate the transition, which PM-CND-0020 does not accommodate — it treats a failed Condition as always blocking. Recorded as Q-G-0035 rather than resolved here, because one cell in one table is thin evidence for a second Condition semantics.