Been thinking about something that seems small in an API schema but can actually change how an integration behaves.
When an RPC marks a field like intent signature as optional, it's easy to assume every request can safely skip it. But that,s only true at the shared schema level. The real requirement often depends on the policy, the selected Policy Client, and whether the flow relies on identity verification.
What caught my attention is that there are really two different layers of validation happening. First, the request matches the generic schema. Then the selected flow decides if extra information, like an EIP-712 signature, is mandatory. If that signature is expected and the app sends nothing, or even a placeholder like 0x, the request may fail before the policy logic even gets a chance to run.
To me, the interesting part isn't that the schema is flexible. Flexibility is actually useful because one endpoint can support many different policy designs. The bigger challenge is making sure applications understand the requirements of the exact flow they are using before they submit anything.
This is why flow-aware validation feels more important than schema validation alone. Passing the base request doesnt always mean the request is complete for that specific integration. Missing that distinction can create confusing failures, extra debugging, and a poor developer experience.
I'm curious how others see it. Should integrations rely on external policy metadata to determine when signing is required, or should those requirements be exposed more directly so developers can catch these issues before a request is ever sent?
@NewtonProtocol #newt $NEWT #NEWT $LAB $BAS

Does an optional task schema improve integrations?