PM-STR-0030

An implementation MUST NOT assume that at most one State Restriction of a Thing is satisfied at a time. The sources' own examples are monotone and overlap.

Non-normative, and this is the most consequential single observation in the specification so far. Take the three restrictions the blog gives for Artist:

| State | Restriction | |---|---| | New Artist | has no createdDate | | Created Artist | has at least one createdDate | | Active Artist | has at least one activatedDate |

An Active Artist necessarily has a createdDate — the Derivation that reached the created stage wrote it, and nothing removes it. So an Active Artist satisfies both "Created Artist" and "Active Artist". The restrictions are property-accretion predicates, and accretion does not exclude.

Nothing in either source says which State the object is therefore in. So state(object) as documented returns a set, not a value, and "the state" is undefined. Every downstream claim about determinism inherits that.

This is a defect in what is written, not necessarily in what Guil intended, which is exactly why it is recorded as CONFLICT with a question rather than silently repaired. MID-0001 sets out the candidate repairs and what each would cost.