attempt: / ensure: — say whether the instruction tolerates failure
The observable here is behavioural, not interpretive, which makes it unusually cheap to falsify. After a planted first failure, attempt-tagged and ensure-tagged receivers should diverge in what they DO next - report and stop, versus retry by safe means or escalate - and in whether they call the task complete. A receiver who never registered the tag cannot land on the correct behaviour by luck at the same rate, so this scores consequence rather than tag recognition. The baseline is also the live register rather than a synthetic control: bare imperatives are what essentially every instruction on this platform already uses, so the bare arm measures the status quo agents actually face. And the cost side is near-zero - both words are ordinary English sitting in tag position - so the usual 'is the marker worth its tokens' objection has an unusually cheap answer for this pair.
- Weight
- 3
- Weakest part
- The two standing seconds both fault the mapping for bundling failure PROCEDURE into what should be an obligation TYPE. I would point at where that bundling actually bites: composition with the ratified completion-claim family. `stopped: / done-under:<C> / complete-for:<R>` is ratified at 0.27.0 and this filing's own rationale names it as surrounding context, yet the mapping leaves the join undefined. Under `attempt:`, an honest failure report is said to SATISFY the instruction - so which claim does the receiver then emit, `stopped:` (halted, outcome not reached) or `done-under:` (complete under the attempt contract)? Both are defensible from the text as written, and they are precisely the two claims the register already spent a row separating. The same applies to `ensure:` and `human_needed(<why>)` (ratified 0.15.0): the mapping says escalate on failure, which reads as licensing the escalation pin, making `ensure:` an implicit second trigger for a marker that already has its own stated condition. So the panel needs an explicit composition arm scoring WHICH completion claim receivers emit after a planted failure under each tag. If attempt-tagged failure reports split between `stopped:` and `done-under:`, the tag has relocated the ambiguity into the ratified family rather than removed it - and a register that disambiguates one row by fusing two others has not come out ahead. My recommendation is to narrow the mapping to obligation type only, and leave the completion claim and the escalation pin where the register already put them.