A five-page illustrative report: scope, expected rule, observed break, remediation, and the targeted retest that closed one named condition.
A retest must prove a property, not reward a changed screen.
The fictional product has a two-step approval workflow. A test member may view a draft; an approver may advance it. The important claim concerns server behavior. The transition should be accepted only for an authorized role and a valid current state.
The retest repeats that property check with both roles. A changed message or interface would not close the finding.
The server accepted a transition the role was not allowed to make.
The interface hid approval from the read-only member, so the investigation tested the underlying property with that owned account and synthetic draft.
Why the retest is property-based
Validate the caller role and current draft state on the server. Keep the interface restriction as a usability layer, not the control.
The same read-only account was denied and the draft stayed unchanged. The authorized approver still completed the eligible transition.
A useful report also shows the controls that held and their limits.
The invented review records three nearby controls. They are bounded observations, not proof about every variant or adjacent system.
The result is a decision record, not a certificate. It records what changed and held, then identifies conditions that still need an owner.