10 ARTF Mistakes That Return gRPC OK and Still Kill Fill

On 3 November 2026, at IAB Tech Lab's Agentic Bootcamp in London, Bedrock Platform ran a live buy: seller agents negotiated line items, the buyer committed to deals, and a bidder took over on each impression. That handoff is the moment ARTF matters. Containers patch the live ticket; orchestrators merge mutations; DSPs still read an OpenRTB object with a dated grammar. gRPC can return OK while the request that leaves the host fails a downstream check you never wired.

ARTF v1.0 is FINAL and in production bidstreams. The RPC validates the framework envelope, not whether your exchange can apply every mutation on the OpenRTB version and policy ACL it runs. These ten failures show up in logs as green sidecars and empty bid density.

Ten mistakes that clear the sidecar and still cost fill

1. Treating RTBResponse OK as OpenRTB clean. The response protobuf can be well formed while the carried bid_request is still protobuf JSON with integer flags (imp.secure: 1) on a hop that only accepts bools. Unmarshal fails for the whole message on the next gRPC leg. See how dialect drift shows up after apply in the ARTF mutations and bid request validation walkthrough.

2. Forwarding mutations when the root payload is not an object. Some agents stringify the OpenRTB slice or double-encode JSON. The framework may still deserialize; artf.payload.root_not_object means you are not patching a bid request, you are patching a blob the apply step cannot walk.

3. Relative paths that look like JSON pointers. Paths must be absolute semantic references (/imp/imp-1/pmp/deals/deal-premium), not imp[0].pmp.deals[0]. A relative segment passes casual review and fails artf.mutation.path_not_absolute. The orchestrator drops the mutation silently or rejects the ticket after timeout.

4. REMOVE on an intent that only supports add/replace. ACTIVATE_DEALS expects ids with an add semantics. Sending MUTATION_OP_REMOVE triggers artf.mutation.op_not_applicable. gRPC still succeeds; the deal never lands on the impression that was supposed to carry it.

5. Wrong oneof for the declared intent. ACTIVATE_DEALS with an adjust_bid payload parses as protobuf JSON and breaks intent binding: artf.mutation.payload_intent_mismatch. This is the copy-paste failure between publisher curation templates and DSP shading templates.

6. Publisher-lifecycle shading. BID_SHADE belongs on LIFECYCLE_DSP_BID_RESPONSE when a bid id exists. Running shade intents on the publisher ticket has no bid target. You get intent-not-applicable warnings, not a cheaper auction. Curators think they shaded; buyers see the unmodified floor.

7. ADJUST_DEAL_MARGIN treated as an OpenRTB field change. Margin rides the same adjust_deal oneof as floor, but margin is orchestrator bookkeeping, not a Deal member buyers parse. Forwarding it as success leaves revenue logic and bid object out of sync.

8. Intents outside applicable_intents. The host publishes an ACL. Agents that propose ADD_CIDS when the SSP never whitelisted it are policy violations, not syntax errors. v1.0 does not force the container to fail the RPC; the host may strip mutations and you only notice missing segments in the cleared request.

9. ADD_CIDS on an exchange pinned to pre-202505 OpenRTB. The intent is valid ARTF. The field may not exist on the snapshot the exchange runs. Apply no-ops or produces a request DSPs drop at the edge. Version negotiation is outside the mutation list; the envelope does not carry the dated snapshot for the agent to read.

10. Skipping apply-then-revalidate. Framework v1.0 does not require a third pass after merge. A metric value sent as a string can survive the mutation check and poison imp.metric[] on the fan-out object. Without revalidation, the failure appears as "DSP does not bid" with no ARTF error code to chase.

How you catch it

I run envelope validation, per-mutation checks (lifecycle, path, intent, oneof), then apply accepted patches and validate OpenRTB again on the object buyers will see. The ARTF simulator runs the same pipeline in a browser. CLI and MCP mirror it:

$ rtblint validate --type artf-request rtb-request.json
$ rtblint validate --type artf-response --apply \
    --request rtb-request.json rtb-response.json

MCP tools validate_artf_request and validate_artf_response (with apply when you need post-patch OpenRTB) are documented on the OpenRTB validator MCP page. An LLM implementing ARTF can emit a legal-looking mutation set and still get an OK from its own transport. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is the deterministic check on that envelope and mutation set. It is independent of IAB Tech Lab and of AAO; the spec does not require it.

Where to go next

• ARTF explained: lifecycle, intents, and where patches land in OpenRTB.
• Rule refs for root payload and path discipline: artf-payload-root_not_object, artf-mutation-path_not_absolute, artf-mutation-op_not_applicable.
• Post-apply OpenRTB damage: ARTF mutations and bid request validation.