PM-CND-0040

An implementation MUST NOT assume an evaluation point for Conditions. The sources support two incompatible readings and the specification does not yet choose between them.

Non-normative. Claim 2 validates "the first object data in accordance with a condition" as part of calculating the valid state transition, which reads as validating the data as it is. Claim 4 then stores the first object data only "if the condition is true", which places storage after validation and is consistent with validating a proposed post-transition image. The blog's framing — a gate between the Operation and the new State, where "all Conditions are true for the state target by the transition" — leans toward the proposed image, since the target state's conditions are what get checked.

The difference is visible to every model author. Under the pre-image reading a Condition can only constrain what was already true, so it cannot express "the result must satisfy this invariant". Under the post-image reading it can, and Conditions become genuine postcondition contracts on Operations — which is considerably more useful and matches what PM-DRV-0030 implies about Derivations guaranteeing their target State.

We would choose the post-image reading. That is a preference, not a finding, so this assertion stays CONFLICT and states the problem rather than the fix.

Withdrawn 2026-09-08. The description states the evaluation point directly. It is the post-image reading. Recorded rather than deleted, because the claims really are ambiguous and a reader who starts from the claims will arrive at this same fork. See PM-CND-0050.