ARTF arrastra un bid_response fantasma cuando la etapa y el payload no cuadran
RTBlint detecta con artf.lifecycle.payload_unexpected los sobres ARTF cuyo enum de etapa contradice los miembros OpenRTB que llevan dentro, aunque gRPC responda OK.
Un sobre ARTF que declara la etapa de publisher bid request y, aun así, lleva dentro un bid_response completo hace que el agente se sitúe en el punto equivocado de la subasta. gRPC devuelve OK, el orquestador se topa con un seatbid que nunca le dijo al agente que existiera y todo apunta a un fallo en la activación de deals. No lo está: es un sobre reutilizado cuyo enum de ciclo de vida y sus miembros OpenRTB se contradicen.
El Agentic Real Time Framework de IAB Tech Lab coloca un agente en contenedor junto a un SSP, un exchange o un DSP. El host le manda un RTBRequest con un valor de lifecycle, un presupuesto tmax en milisegundos, el objeto OpenRTB que se va a mutar y los applicable_intents. El agente responde con mensajes Mutation y rutas semánticas; el orquestador aplica lo que acepta y solo entonces reenvía la subasta.
La etiqueta no borra lo que sobra
Las llamadas de publisher stage corren antes de que haya contestado ningún DSP. Las de response stage esperan un miembro bid_response cuando intents como BID_SHADE necesitan seat y bid ids. El enum lifecycle nombra la etapa; no elimina los miembros de más que dejaste en el JSON en un salto anterior. Si en LIFECYCLE_PUBLISHER_BID_REQUEST aparece un bid_response, RTBlint lo marca como artf.lifecycle.payload_unexpected. Con un orquestador por defecto eso es justo el problema: el modelo que tiene el agente de dónde está dentro de la subasta es falso aunque el JSON protobuf parsee sin quejarse. El validador lo trata como warning y no como error duro, porque un host privado podría estar pasando contexto previo a propósito.
El fallo inverso, response stage sin bid_response, es artf.lifecycle.payload_mismatch y sí bloquea los caminos de shading que necesitan un bid id que el sobre nunca incluyó. Los dos casos son el mismo contrato: lifecycle dice qué intents tienen sentido y los miembros OpenRTB que viajan tienen que contar la misma historia. En producción aparecen igual: alguien registra el estado completo de una subasta, copia el objeto en el siguiente fixture ARTF y se olvida de quitar bid_response cuando la etapa vuelve a publisher.
tmax no es el timeout de la subasta
En el mismo sobre hay otra trampa de unidades. El tmax de ARTF son milisegundos presupuestados para el RPC de mutación dentro de la subasta, no el timeout de OpenRTB copiado de bid_request.tmax. Las muestras de referencia rondan los 120 a 150 ms; por encima de 1000 ms salta artf.tmax.implausible, porque el extension point corre dentro del timeout de un exchange y un presupuesto medido en segundos suele significar que alguien pegó un límite de subasta sin convertir unidades. No rompe el sobre por sí solo, pero se lleva mal con una etapa mal etiquetada: puedes quemar segundos de agente en una llamada que sigue arrastrando el bid_response fantasma.
RTBlint, el linter open source de OpenRTB y ARTF que mantiene el autor, ejecuta las comprobaciones de sobre antes que las de mutación, porque lifecycle e intents definen qué puede proponer la respuesta. El comando es:
rtblint validate --type artf-request rtb-request.json
Si el documento no parsea, nada aguas abajo corre y sale artf.payload.invalid_json. La segunda pasada empareja cada mutación con applicable_intents y rutas semánticas; la tercera aplica las mutaciones aceptadas y revalida OpenRTB para ver el daño campo a campo. Las mismas reglas están en el simulador ARTF, en herramientas MCP y por gRPC en openadtech.rtblint.v1. Como el propio estándar ARTF ya obliga a usar gRPC para el extension point, validar en ese canal sale más barato que descubrir el desajuste de etapa después de que los deals se hayan activado contra el documento equivocado. La herramienta es independiente de IAB Tech Lab y los identificadores de regla salen del proto público y del documento v1.0.