Hi Valentyn, Thanks for sending the probe. I checked the SHA-256 and reran it. All eight scenario outputs match your results.json.
> [VR] fresh observation != commit-time guarantee [IS] T7b demonstrates that ordering in the model: the final read passes, the approved compliance version changes, and the target mutation still occurs. The unchanged-state control commits too. There is one test I'd strengthen before using this to compare implementations. T4 calculates all_ok but never calls a guarded execution path, so its zero effect doesn't yet test enforcement. Could it call that path and assert refusal with zero effect, alongside a no-race case that commits through the same path? That would catch a guard being bypassed. For T7b, the code changes compliance.version but leaves compliance.value at 1. I'd describe the current case as invalidation of the approved version. If you mean an actual change from approved to suspended, could that state change and its predicate be explicit too? > [VR] I can put it in a public GitHub commit next if that is the most useful > form for comparison. [IS] Yes, a pinned commit with the probe and results would give us a shared baseline. Your README is right that this doesn't establish a standards gap. I'd also say explicitly that these are in-memory cases modeling the checks, not tests against OAuth, HTTP servers or participating providers. Best, Iman _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
