El Motor de Clasificación
¿Por qué REVsign ignora los cargos corporativos tradicionales y cómo identifica al decisor real?
Un rastreo tradicional que filtra por taxonomía de cargo (“VP of Growth”, “Head of Sales”) hereda un problema de origen: un título de LinkedIn es una declaración, no una verificación. La etiqueta puede estar desactualizada, ser honorífica, o simplemente no reflejar quién ejecuta de verdad dentro de la organización — y una taxonomía rígida que confía en ese texto genera falsos positivos sistemáticos.
RevSign evalúa cada contacto con persona_classifier, un agente clasificador que corre en Claude Haiku 4.5. En vez de comparar el título declarado contra una lista de cargos objetivo, compara vocabulario y capacidad de ejecución real contra el perfil de comprador buscado. La salida nunca es un booleano: es uno de tres estados — ajuste claro, ajuste plausible, o rechazado.
Esto es la aplicación directa del primer Mandato Fundacional del sistema: la función dicta la realidad, no la etiqueta.
Gobernanza Financiera
¿Qué es la estrategia “Late Reveal” y cómo protege el presupuesto operativo?
El candidato llega al clasificador sin datos de contacto — sin email, sin teléfono. No es un campo marcado como oculto: esos datos directamente no forman parte del objeto hasta ese punto del proceso.
Revelar el email o el teléfono de un contacto es una llamada de enriquecimiento real y facturada. El sistema solo la dispara después de que persona_classifier aprobó el ajuste (clara o plausible); un contacto rechazado nunca genera esa llamada. El resultado: el presupuesto de enriquecimiento se gasta únicamente en contactos que ya pasaron el filtro de que vale la pena mirarlos, no en cada fila de una lista de prospección cruda.
Infraestructura de Datos
¿Cómo funciona la Capa Única de Señales y la verificación de identidades corporativas?
La Capa Única de Señales es la infraestructura descrita en Arquitectura de Señales: una fuente de verdad, sin copias duplicadas por sistema. Antes de que un dominio entre a esa capa, pasa por una verificación de varios pasos:
- Sondeo activo del dominio. Un HEAD HTTP con seguimiento de redirects descarta dominios caídos o estacionados. No alcanza un solo chequeo: hacen falta dos confirmaciones consecutivas antes de marcar un dominio como muerto o parkeado, para no penalizar un error transitorio de red.
- Validación de CUIT. Un checksum matemático (módulo 11) y las reglas de prefijo para personas físicas y jurídicas validan el formato. El cruce contra el padrón de AFIP vía AfipSDK está construido pero todavía no validado con credenciales reales de producción — queda activo recién cuando el entorno las tenga configuradas, y hasta entonces la empresa queda con estado “pendiente” en ese campo.
- Mapeo de la red societaria. Empresas que comparten CUIT pero tienen dominios distintos se marcan como candidatas a fusión por coincidencia de marca y CUIT. Nunca se fusionan solas: siempre quedan como una señal para revisión humana.
Vectores de Operación
¿Cuáles son los vectores operativos que permite desplegar el motor?
| Vector | Qué hace | Estado |
|---|---|---|
| GTM y Outreach | Cada señal validada se bifurca en dos caminos: una alerta que un Account Manager gestiona a mano, o (cuando hay volumen) una campaña de secuencias generadas en lote. | En producción |
| Señales de contenido coordinado | El mismo motor de radar que ingesta narrativas para la Capa Única de Señales corre un índice vectorial (pgvector con HNSW) que detecta contenido casi idéntico publicado por medios distintos dentro de una ventana temporal corta (Cross-Outlet X-Ray), más un analizador léxico que estima probabilidad de generación por IA sin depender de un modelo externo. | Primitivas de radar reutilizadas, no un producto de monitoreo empaquetado |
| Mapeo de estructuras societarias opacas | Documentado como dirección futura. | Sin código implementado todavía |
Prevención de Alucinaciones
¿Cómo garantiza REVsign la integridad auditable y evita que los LLMs alucinen información?
Todo análisis que cita una fuente debe traer, por cada afirmación, un chunk_id y una quote textual. Antes de que esa síntesis llegue a cualquier briefing, un validador mecánico verifica que la quote sea un substring literal del contenido de ese chunk — no una coincidencia semántica ni aproximada, una comparación de substring exacta.
Si una sola cita no verifica, el sistema dispara un error de contrato y descarta la síntesis completa. No se guarda una versión parcial ni se sigue adelante con lo que sí pasó. Esto obliga al modelo a operar como motor de extracción sobre texto crudo, no como generador de texto libre con apariencia de cita.
Seguridad de Agentes
¿Cómo se controla a los sub-agentes tácticos autónomos para que no operen fuera de sus parámetros?
Cada sub-agente tiene, en código — no en el prompt —, una lista explícita de herramientas que puede invocar (para varios agentes, ninguna en absoluto), un tope de tokens por llamada y un tope de iteraciones. El modelo no “decide no usar” una herramienta fuera de esa lista: directamente no existe para él en esa invocación, porque nunca se le describe.
La salida de cada agente además se valida contra su contrato de datos en el límite exacto de la llamada. Cualquier desvío del esquema esperado dispara un error inmediato que corta la ejecución, con un presupuesto acotado de reintentos de reparación — nunca ilimitado. El equipo interno llama a esto la “camisa de fuerza digital”: restricciones escritas como código ejecutable, no como una sugerencia que un modelo podría malinterpretar o ignorar bajo presión.
$ curl revsign.os/docs/preguntas-frecuentes
→ {
title: "Preguntas Frecuentes: clasificación, verificación y seguridad de agentes",
answers: "¿Cómo evita RevSign los falsos positivos de cargo, el gasto de enriquecimiento prematuro y la alucinación de un agente?",
schema: [FAQPage]
}