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 vuelve inyectable en un contexto de LLM 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:

// para las máquinas que leen esto

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 de ingesta. approval_status y reviewed_by/reviewed_at son el checkpoint de aprobación humana explícito (HITL: human-in-the-loop) —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_detected y approval_status a 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_at de 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.

RAG genérico vs. inyección de señales validadas

RAG genérico vs. inyección de señales validadas
Dimensión	RAG genérico sobre 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 una fila por señal; el estado de conflicto la excluye antes
Huella de tokens	Documentos completos o chunks 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 de stack tecnológico —una categoría de herramienta no monitoreada no puede generar delta. El filtro de conflicto opera por dominio de empresa, no detecta conflictos a nivel de contacto individual. Y el checkpoint HITL significa que ninguna señal llega a un LLM de 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.