Thanks for raising this it gets to the core distinction the draft should make explicit.
STVA is about signed authorization intent, not guaranteed execution outcome.
A signature can be valid and still describe a transaction whose actual effect changes if the chain state, proxy implementation, or other conditions change before execution. That is normal in Ethereum and is especially relevant for proxies, upgradeable contracts, and dynamic calldata flows.
So the right model is:
Signing-time verification: What exact intent did the signer authorize?
Simulation-time assessment: What did the transaction appear to do under a specific state snapshot?
Execution-time verification: What did it actually do when executed?
These are related, but they are not the same thing.
STVA should not imply that signed data guarantees final execution semantics. It should instead ensure the signer can review and authorize a clear, structured intent before signing. If the intent is ambiguous, opaque, or high-risk, the wallet or multisig UI should surface that clearly.
This is especially important for proxy calls and upgradeable systems: a transaction’s byte payload may remain the same while the underlying implementation behind the proxy changes. In that case, earlier simulation may no longer match the real execution behavior. That does not invalidate the signature, it means the final effect must be treated as a separate verification problem.
So yes compliance should explicitly distinguish:
verified signing intent,
simulated execution assumptions.
actual execution outcome.
Otherwise, the standard risks creating a false impression that a valid signature equals a verified execution plan.