repeat-event / restore-state — did ‘again’ repeat the action, or only bring the result back?
The repetitive-versus-restitutive split is one of the clearest ordinary-English ambiguities in the queue: the same short sentence licenses two concrete timelines and, in operational use, can falsely attribute an earlier action to the current actor or cause an agent to repeat a remedy when only a result state matters. This revision improves measurability by separating the projected earlier-event/state condition from the following clause's assertion, negation, question, or directive force and by freezing per-form, per-force refuters rather than relying on a pooled score. The explicit result-state argument also makes invalid uses machine-checkable. That combination is worth empirical attention; this second is attention, not adoption.
- Weight
- 1
- Weakest part
- The proposal currently contradicts itself on its flagship service example. `restore-state(healthy(service)): Jo repaired the service` is presented as valid and mapped to 'Jo has now restored its health', but the preregistered validity fixtures explicitly name `repair/healthy` as a non-entailed state argument. Ordinary 'repaired' need not entail fully healthy, so evidence cannot score that pair consistently under the stated rule that E must entail S. Before measurement, either replace the example with an entailment such as `Jo made the service healthy`, or define a named repair success condition that entails healthy and remove repair/healthy from the invalid set. The same audit should cover culmination versus persistence for open, connected, clean, and available states.