# Software Review

## Findings

### High: required fields are defined, but no concrete message shape or example flow is provided

The event model is understandable, but two implementers could still serialize or correlate it differently. A non-normative example showing `failure -> rollback-request -> rollback-result` with task identifiers, dependency references, and partial-success handling would materially reduce ambiguity.

### High: task state transitions are incomplete at the procedure level

The draft lists states but does not specify enough transition rules. For example, can a task move from `completed` directly to `rollback-requested`? Can `compensation-required` be terminal? Can `rollback-failed` later transition to `rolled-back` after manual intervention? Without a transition table or explicit rules, interoperability tests will be hard to design.

### Medium: rollback scope remains too abstract for independent implementations

The draft requires a target checkpoint or explicit rollback set, but it does not describe the structure of a rollback set or how direct and transitive dependencies are represented. The draft needs at least a minimal abstract shape for scope membership.

### Medium: timeout behavior is named but not operationalized

Timeout is listed as an error condition, but no rule says whether timeout yields `failure`, `partial-success`, or local retry. This will fragment behavior.

## Open questions

- Is a compact transition table sufficient, or does the draft need a separate state machine subsection?
- Should rollback set representation be a list of task identifiers, checkpoint identifiers, or both?

## Residual risk

The current draft is close to implementable, but it still needs one more layer of precision around flow shape and state progression before two vendors would likely build compatible behavior.
