Mutation uses the ARTF document's vocabulary, not its proto's
The mutation is written the way the ARTF v1.0 document's examples are, with camelCase intents and a value wrapper, rather than the enum names and oneof members its own .proto defines.
What it means
The mutation carries an intent such as activateSegments or adjustDeals, an op such as add, or a payload wrapped as value: {IDsPayload: ...}. The ARTF v1.0 document's worked examples use that vocabulary; the .proto in the same repository defines ACTIVATE_SEGMENTS, OPERATION_ADD, and top-level oneof members.
Why it matters
The two are not interchangeable, and the reference server speaks only the second. Someone implementing from the specification document produces the first and gets a rejection that reads like an unknown intent, which sends them looking for a mistake they did not make. The validator maps the spelling and keeps checking the rest of the mutation for that reason.
How to fix it
Generate mutations from the .proto rather than from the document's examples: enum value names for intent and op, and the payload as a top-level oneof member.
Example that trips it
{ "intent": "adjustDeals", "op": "replace", "path": "/imp/1/deals/500", "value": { "AdjustDealPayload": { "bidfloor": 8.0 } } }Copied from the ARTF v1.0 document's complex orchestration example.
Check your payload
Paste a bid request or response into the tester to see whether this code fires against it, or gate on the id in CI with the CLI: the id is stable, wording is not.
Back to the full diagnostic code reference.