[PaulHoule]

It depends on what kind of system you're talking about.

If you have no memory, that memory can't get corrupted.

If the memory is carried by the request the memory can't get desynchronized with the request.

You can use cryptographic techniques to prevent tampering and even reuse of states, though reuse can be a feature instead of a bug. Sometimes the state is too big to pass around like a football but even then you can access it with a key and merge it in in a disciplined way.

[SpicyG]

I agree, and I think you’ve named the core constraint cleanly. The distinction I’m trying to draw isn’t “no memory ever,” but no implicit memory required for correctness. If there’s no memory, there’s nothing to corrupt. If memory is carried by the request, it can’t desynchronize from the request. That’s really the invariant I care about. I also agree that cryptographic techniques make this tractable in practice. Signed tokens, capabilities, idempotency keys, and replay protection let you move state to the edge, while also keeping the core enforcement logic stateless. In that model, reuse can be a feature rather than a bug, as long as it’s explicit and verifiable. Where I’ve seen things break down, is when state is large or shared and gets merged implicitly. As you say, sometimes you can’t pass it around like a football, but even then accessing it by key and merging it in a disciplined and bounded way, preserves the same principle: the system shouldn’t need to remember in order to act correctly. So for me it’s less “stateless vs stateful” and more “enforced state vs negotiated state.” Once the system starts negotiating with history, entropy creeps in very fast.