Typically, you do it in one of two ways
In the world of HTML, unsafe operations were described by forms, and the description of the form could include hints for the client as to what possible values were expected.
In a world where you are manipulating representations of the resources directly, this is normally achieved by documenting a schema for the representation, and within that schema documenting the restrictions on the information contained within.
For example, the JSON Patch specification documents what operations are supported. Sticking in anything else means that you aren't providing a valid application/json-patch+json
document.
But if I'm reading your example correctly, what you are trying to do is allow the client to drive some resource to the next state of an FSM. As far as I can tell, nobody is claiming that's a good fit for the PUT verb
Clients should never decide the current state of an entity, instead, they should request transitions of that entity to the desired state. -- Richard Clayton
PUT (and similarly PATCH) are good fits for remote authoring: situations where the client is the authority for the information, and is just sending to the server a cacheable copy. It's not as a good a fit for manipulating resources where the server, rather than the client, is the source of truth.