Qué es una señal semánticamente pura
Una señal semánticamente pura es un registro con estado explícito: se sabe cuándo se detectó, si fue revisada por un humano, y si un modelo generó un análisis sobre ella. No es un párrafo de texto libre, es una fila con campos verificables. Eso es lo que la deja lista para pasársela a un modelo de IA sin arriesgar una alucinación: el modelo no tiene que inferir la procedencia del dato, la procedencia ya está en el registro.
Anatomía de una señal
Los campos reales de auditoría de una señal, no un ejemplo simplificado, son estos:
revsign.os/signal
$ curl revsign.os/signal/8f2a1c
→ {
company_domain: "acme.com",
signal_type: "tech_stack_change",
intent_score: 82,
status: "pending",
approval_status: null,
date_detected: "2026-07-14T09:00:00Z",
reviewed_by: null,
reviewed_at: null,
insight_status: "pending",
version: 1
}
# Nota: no existen campos "ingested_at"/"validated_at"/"logged_at",
# la cadena real es date_detected → approval_status/reviewed_at → insight_status.Cadena de custodia: detección → revisión → insight
date_detected marca el momento en que se cargó. approval_status y reviewed_by/reviewed_at son el punto de aprobación humana explícito, una señal no pasa a acción sin que ese campo se llene. insight_status, junto con insight_attempts e insight_model, registra si y cómo un modelo generó un análisis adicional sobre la señal ya aprobada. Cada etapa queda en la misma fila, no en un log separado que se puede perder.
Cómo se arma el contexto que consume el modelo
- Se filtran señales por
status != 'suppressed'y por la banda de intención relevante para la consulta. - Se adjunta
date_detectedyapproval_statusa cada señal incluida en el contexto, para que el modelo pueda citar la fecha y el estado de revisión, no solo el contenido. - Se excluyen señales sin
reviewed_atde cualquier contexto que vaya a producir una recomendación accionable, solo lo ya revisado por un humano se usa para decisiones, no para exploración. - Se entrega el registro completo, no un resumen: el modelo recibe los campos, no una paráfrasis de los campos.
Búsqueda genérica en documentos vs. señales validadas
| Dimensión | Búsqueda genérica en documentos | Inyección de señales validadas |
|---|---|---|
| Origen | Documentos de cualquier antigüedad, sin estado | Filas con date_detected explícito |
| Frescura | Depende de cuándo se indexó el documento | Verificable por consulta directa al campo |
| Verificabilidad | El modelo no puede distinguir hecho de opinión | El campo approval_status distingue revisado de pendiente |
| Comportamiento ante contradicción | El modelo puede citar dos fuentes contradictorias sin saberlo | Solo un registro por señal, y el estado de conflicto la excluye antes |
| Volumen de texto | Documentos completos o fragmentos largos | Un registro estructurado, compacto |
Límites conocidos
Esto no resuelve todo. La calidad del score de intención depende de la cobertura de detección del software que usa cada empresa, una categoría de herramienta no monitoreada no puede mostrar un cambio. El filtro de conflicto opera por dominio de empresa, no detecta conflictos a nivel de contacto individual. Y ese punto de aprobación humana significa que ninguna señal llega a un modelo de IA en producción sin que, en algún punto, un humano la haya revisado, esto es una decisión de diseño deliberada, no una limitación a resolver.
$ curl revsign.os/docs/inyeccion-de-datos-para-llms
→ {
title: "Datos listos para la IA: anatomía de una señal auditable",
answers: "¿Cómo le doy a un modelo de IA datos auditables de mi empresa?",
schema: [TechArticle, HowTo]
}