Projection Engineering proyecta Claims inciertos en un grafo auditable

Imagen: generada con Google Gemini.

Un sistema automatizado afirma que no se pagó el alquiler de julio.

Producir esa frase es barato. Verificarla no. Alguien debe examinar el contrato de arrendamiento, identificar las cuentas registradas, comprobar el periodo pertinente, distinguir las transferencias liquidadas de las pendientes, preguntar si el pago pudo haberse aplicado a otra deuda y determinar qué política permite que el resultado active una notificación o un desalojo.

La respuesta es una sola frase. Su frontera de verificación se extiende por todo el mundo.

Este es el problema estructural de la IA generativa. No se trata simplemente de que un modelo pueda equivocarse. Ahora puede producirse un Claim plausible casi al instante, mientras que comprobarlo puede exigir reconstruir los registros, supuestos, transformaciones, políticas y omisiones que hay detrás.

Verificar se volvió más caro que generar.

Hacer que el modelo sea más fluido no corrige esa inversión. Tampoco basta con adjuntar una cita si nadie puede determinar qué parte de la fuente respalda cada proposición, qué versión se utilizó o qué debe reabrirse cuando la fuente cambia.

Las instituciones maduras resolvieron problemas análogos insertando una capa de responsabilidad entre la observación y el cálculo. La física construyó la metrología. El derecho construyó la determinación jurídica de los hechos. La IA posee fragmentos de ambas, pero carece de una disciplina reconocida responsable de convertir Claims del mundo abierto en premisas que una decisión pueda utilizar con seguridad.

Llamo a esa responsabilidad ausente Projection Engineering.

La capa que falta entre un registro y una decisión

La metrología no confía en la aguja

Un sensor que muestra un número aún no ha producido una medición fiable. Una medición también necesita una unidad, un historial de calibración, una cadena de trazabilidad, incertidumbre y un rango de validez declarado. El NIST subraya que la trazabilidad metrológica pertenece al resultado de una medición, no simplemente a un instrumento que lleva una etiqueta de calibración (Trazabilidad metrológica: preguntas frecuentes y política del NIST).

La maquinaria que rodea la medición permite diagnosticar los fallos. Si una estructura falla, un investigador puede recorrer el camino desde el valor informado, pasando por las transformaciones y calibraciones, hasta la observación original. La aritmética por sí sola no ofrece ese camino. La metrología hace que un número pueda soportar peso institucional.

Una respuesta de un LLM suele llegar sin una cadena equivalente. Rara vez identifica la observación que originó cada Claim, qué se perdió durante la transformación, dónde sigue siendo válido el Claim o qué decisiones dependientes deben reabrirse tras una corrección. Es una aguja en movimiento sin escala ni certificado de calibración.

El derecho no confía en la alegación

Un tribunal no se encuentra con el pasado mismo. Se encuentra con alegaciones, testimonios, registros, pruebas documentales e informes periciales. Mediante reglas probatorias, cargas, estándares de prueba y procedimientos autorizados, la determinación jurídica de los hechos decide qué Claims contrapuestos pueden servir como premisas en un caso concreto. La distinción entre la realidad sustantiva y la verdad jurídica formal es un antiguo problema de la determinación judicial de los hechos (Verdad jurídica formal y verdad sustantiva en la determinación judicial de los hechos).

Separar la determinación de los hechos de la aplicación de las reglas también separa los errores. Un registro puede recopilarse incorrectamente. Una proposición puede admitirse bajo el estándar equivocado. Una premisa correcta puede encontrarse con una regla implementada de forma incorrecta. Una conclusión correcta puede ejecutarse contra la persona equivocada. Cada fallo pertenece a una capa distinta y exige una reparación diferente.

La metrología convierte observaciones en valores trazables. El derecho convierte un registro controvertido en conclusiones de hecho utilizables para una decisión. Ambos se niegan a permitir que la entrada bruta fluya en silencio hacia un cálculo con consecuencias. Esa es la capa que falta en los sistemas de decisión basados en IA.

Fact significa Accepted Fact

El nombre Projection Engineering necesita una frontera estricta. No promete fabricar una verdad absoluta.

En Projection Engineering, Fact significa Accepted Fact.

Un Accepted Fact es un Claim autorizado para utilizarse como premisa en una decisión concreta bajo un propósito, un alcance, un momento de referencia, un estándar de prueba y una política explícitos.

Tres objetos deben permanecer separados:

  • Claim: una afirmación u observación presentada por una fuente identificada.
  • Accepted Fact: un Claim admitido como premisa mediante un procedimiento autorizado.
  • Conclusión: un resultado calculado a partir de Accepted Facts y reglas.

Un Accepted Fact es un Claim con un estado institucional documentado, no la realidad capturada en un campo. La verdad sigue siendo el objetivo: la proposición debería corresponderse con la realidad. Lo que el sistema puede conservar es más limitado y operativo: quién afirmó qué, a partir de qué registro, en qué momento y mediante qué transformación; quién lo aceptó o rechazó y bajo qué autoridad; y qué se derivó de ese conjunto acotado de premisas.

Projection Engineering no es dueña de la verdad. Diseña la frontera alrededor de una decisión para que otra persona pueda inspeccionarla e impugnarla.

La IA ya está cerrada: sobre tokens

Un Transformer congelado está cerrado en un sentido computacional útil. Si se fijan sus pesos, entrada, entorno de ejecución y condiciones de decodificación, su pasada hacia delante puede reproducirse. La arquitectura calcula qué token debería venir a continuación (La atención es todo lo que necesitas). Está cerrada sobre probabilidades de tokens, no sobre la realidad.

Esa distinción explica tanto su resiliencia como su límite. Un corpus de entrenamiento puede contener X y not-X. La deducción clásica debe gestionar tal contradicción porque una explosión sin restricciones puede permitir que se derive cualquier cosa. Un modelo de lenguaje no explota: los pasajes contradictorios alteran una distribución en lugar de invalidar una prueba, porque la implicación lógica no es la operación primitiva que se está realizando.

Por la misma razón, la atención y softmax no contienen ninguna regla que garantice que las premisas verdaderas conserven la verdad durante la generación. Los sistemas modernos pueden reducir los errores expresados con seguridad, pero las alucinaciones persisten en parte porque el entrenamiento y la evaluación pueden premiar la conjetura frente al reconocimiento de la incertidumbre (Por qué alucinan los modelos de lenguaje).

Tomamos un cálculo sobre el lenguaje y lo usamos como un juicio sobre el mundo. El cierre existe, pero una capa por debajo de donde se necesita la responsabilidad. Projection Engineering aporta un cierre diferente: declara qué Claims, políticas, autoridades y momentos definen el mundo de esta decisión. Entonces las reglas reproducibles pueden calcular dentro de él.

El metro muestra lo que puede hacer el cierre

En 1983, la 17.ª Conferencia General de Pesas y Medidas definió el metro como la distancia que recorre la luz en el vacío durante 1/299,792,458 de segundo, fijando la velocidad de la luz exactamente en 299,792,458 m/s dentro de la definición del SI (Resolución 1 de la 17.ª CGPM (1983)).

El valor no se volvió exacto porque la humanidad por fin midiera la naturaleza sin incertidumbre. Una comunidad autorizada lo trasladó al otro lado de una frontera: de una magnitud que debía refinarse a una parte de la definición del sistema. Las mediciones bajo esa frontera se volvieron más precisas porque la frontera era explícita.

No era una pretensión de poseer la realidad. Era una convención fechada, adoptada por una autoridad identificable mediante un procedimiento definido y revisable mediante otro procedimiento. Projection Engineering cierra una decisión en el mismo sentido limitado. No cierra la realidad. Congela qué Claims pueden servir como premisas aquí y ahora, bajo una política y una autoridad determinadas.

Donde se rompe la analogía

La metrología es una guía, no un disfraz para problemas sin resolver.

En primer lugar, la medición ordinaria suele beneficiarse de la repetición. Un pago, un consentimiento, una inspección, un despido o un accidente puede ser un acontecimiento único. El modelo más cercano es la metrología forense: una sola observación debe sobrevivir a un proceso contradictorio mediante artefactos preservados, cadena de custodia, procedimiento documentado y límites conocidos del instrumento.

En segundo lugar, la incertidumbre numérica a menudo puede propagarse mediante ecuaciones. Las proposiciones sin resolver todavía no poseen una aritmética igual de general. Conservar supported, defeated y unknown a lo largo de derivaciones extensas sin blanquearlos como falsa precisión sigue siendo un problema de investigación abierto.

En tercer lugar, declarar que una fuente es completa o que una política es vinculante constituye un ejercicio de autoridad. La trazabilidad puede revelar esa elección, pero no volverla imparcial. Projection Engineering debe mostrar quién puso el pulgar en la balanza; no puede prometer eliminar todos los pulgares.

Un GAF no es una lista

Almacenar únicamente un Accepted Fact destruye la información que lo hizo aceptable. Perdemos quién lo presentó, qué lo impugnó, qué política lo admitió y qué autoridad hizo operativa esa política.

Por tanto, el entregable de Projection Engineering es un Graph of Accepted Facts (GAF).

Records / Observations
          │
          ▼
        Claims ◀──── Evidence / Counterevidence
          │
          ▼
  Evaluation + Projection Policy
          │
          ▼
   Accepted Facts ─────┐
          │             │
          ▼             │
 Rules / Derivations    │
          │             │
          ▼             │
      Conclusions       │
                        │
 Provenance ────────────┘

Un GAF conecta registros originales, Claims extraídos, pruebas favorables y contrarias, evaluaciones, política y autoridad, Accepted Facts, derivaciones, conclusiones, versiones, marcas temporales y dependencias. Los estándares existentes ya modelan entidades, actividades, agentes y relaciones de provenance; PROV-O: la ontología PROV muestra que este vocabulario no tiene por qué pertenecer a un solo producto de base de datos.

Tampoco es necesario que un GAF resida en una base de datos de grafos. Una base de datos relacional o un registro de solo anexado basta si conserva las relaciones y el linaje bidireccional.

  • A partir de una conclusión, un auditor debe poder recorrer hacia atrás los Accepted Facts y Claims hasta los registros originales.
  • A partir de un registro invalidado, el sistema debe poder recorrer hacia delante hasta cada Accepted Fact, conclusión y acción autorizada que pueda requerir una reapertura.

El primer camino hace que una decisión sea auditable. El segundo hace que la corrección sea computable.

Un pago de alquiler, tres problemas de ingeniería

Volvamos a la disputa por el alquiler. El inquilino afirma que pagó. El propietario sostiene que no lo recibió como alquiler. Un libro mayor bancario muestra que el dinero se movió entre sus cuentas registradas durante el periodo acordado, pero el concepto está en blanco.

La primera tarea es la descomposición de proposiciones:

A payment moved from the tenant's account to the landlord.  [accepted]
That payment discharged this month's rent obligation.       [undetermined]

La transferencia y la imputación jurídica son Claims distintos. Si pudiera existir otra deuda, el primero no implica el segundo. Decidir separarlos no es trabajo administrativo. En un caso de despido, preguntar si existió el motivo declarado, si se siguió el procedimiento, si el motivo justificaba el despido y si el actor tenía autoridad produce grafos de decisión diferentes a partir de los mismos registros.

Esto es la formación de cuestiones, el oficio central de Projection Engineering. Quien formula las proposiciones determina qué puede aceptarse, refutarse o dejarse como desconocido. El sistema debe conservar quién realizó esa descomposición, con qué propósito, bajo qué autoridad y qué alternativas se excluyeron. Una provenance perfecta después de un encuadre sesgado solo documenta el sesgo con elegancia.

El segundo problema es la ausencia. No encontrar un pago no demuestra el impago. El periodo puede ser incorrecto, la búsqueda incompleta, la transferencia puede estar pendiente o la información puede estar en manos de otra institución. La ausencia se convierte en prueba únicamente después de que un contrato de completitud defina qué promete contener la fuente.

Completeness contract C-04

Declarant: operator of ledger L
Scope: all settled transactions for account A during period P
Excludes: pending transactions and records held by other institutions
Authority: signed policy version V

Solo entonces la ausencia puede respaldar la negación dentro de ese alcance. Declarar completa una fuente conveniente puede convertir un caso desconocido en uno decidible, por lo que la declaración debe incluir identidad, firma, fecha, versión y autoridad.

El tercer problema es el juicio humano repetido. Una persona puede decidir que una transferencia desde la cuenta registrada, dentro del periodo acordado, por el importe exacto y sin una deuda concurrente, cuenta como alquiler pese a que el concepto esté en blanco. El activo reutilizable no es esa respuesta concreta. Es el juicio general que hay detrás.

Esto es la preservación de decisiones, pero un ejemplo no debe convertirse silenciosamente en precedente. El juicio sigue siendo un candidato a política hasta que una persona autorizada especifica su alcance, excepciones, momento de entrada en vigor, retroactividad y condiciones de revocación. Solo entonces se convierte en una política ratificada.

Del Claim a la acción autorizada

Projection Engineering no es un modelo ni un producto de almacenamiento. Es el proceso que proyecta registros del mundo abierto en un mundo de decisión cerrado y vuelve a abrir ese mundo cuando cambian las pruebas o las políticas.

Reality
   │
   ▼
Records / Observations
   │  preservation · calibration · transformation history
   ▼
Claims
   │  proposition decomposition · source evaluation · conflicts and gaps
   ▼
Projection
   │  purpose · scope · reference time · proof standard · authority · policy version
   ▼
GAF
   │  Accepted Facts · provenance · dependencies
   ▼
Closed Decision World
   │
   ▼
Deterministic Conclusion
   │
   ▼
Authorized Action

Cada transición puede producir un error diferente:

  • Omitir un registro original es un error de recopilación.
  • Un OCR o una extracción deficientes constituyen un error de transformación.
  • Formular la cuestión equivocada o aceptar el Claim erróneo es un error de proyección.
  • Calcular una conclusión incorrecta a partir de Accepted Facts correctos es un error de regla.
  • Aplicar una conclusión correcta al destinatario equivocado es un error de ejecución.

Cada uno exige una reparación distinta. Las nuevas pruebas reparan la recopilación. Una nueva evaluación repara la proyección. Un motor de reglas corregido puede reproducir un GAF congelado. Los fallos de ejecución requieren cancelación, corrección o compensación, no hechos reescritos. Llamar a cada fallo «la IA se equivocó» hace que ninguno pueda repararse.

Pagar una sola vez el coste de comprender

La capa que falta no solo es un riesgo. También es una fuente de desperdicio. Un modelo lee un contrato, identifica a las partes, extrae obligaciones y responde una pregunta. La siguiente pregunta suele volver a pagar buena parte del mismo coste de interpretación. La recuperación reduce el texto cargado, pero continúa trasladando fragmentos de prosa porque la unidad reutilizable sigue siendo el fragmento de documento.

La compilación semántica cambia esa unidad. Un documento se interpreta una vez como proposiciones estables con identificadores, fuentes, alcance temporal y dependencias. Las preguntas posteriores reutilizan esas proposiciones entre prompts, usuarios y documentos. Pagamos una sola vez el coste de comprender, cuando el Claim entra en el sistema, en vez de cada vez que alguien pregunta por él.

El almacenamiento en caché de prompts no puede sustituir esta capa. Una caché conserva bytes y orden. Un GAF conserva significado y provenance. Una caché de prefijos puede romperse cuando cambia el orden; una proposición puede combinarse con Claims extraídos en otro lugar y servir a todas las decisiones que dependen de ella.

La reutilización significativa crea un problema de invalidación más difícil. Si una fuente se corrige, se sustituye o se descubre que es fraudulenta, ¿qué conclusiones deben reabrirse? Una caché de hechos sin provenance es una caché de alucinaciones: repite el mismo error más rápido y con mayor seguridad.

El linaje es invalidación de caché.

La estructura que permite a una persona impugnar una decisión es la misma que permite a una máquina recalcular únicamente las conclusiones afectadas. La rendición de cuentas y la eficiencia no son características enfrentadas en este caso. Son dos usos del mismo grafo de dependencias.

La frontera con las disciplinas vecinas

Projection Engineering no sustituye a Data, Knowledge, Rule, Prompt o Context Engineering. Se hace cargo de la frontera de responsabilidad que hoy cruzan sin un custodio responsable.

Data Engineering mueve registros a través de source → ingest → transform → store → serve. Projection Engineering pregunta si un registro califica como información utilizable como premisa mediante record → claim → evaluate → project → GAF. Un esquema válido puede contener un registro falso.

Knowledge Engineering representa conceptos y relaciones para su uso por máquinas. Projection Engineering trata primero cada relación como un Claim y registra quién autorizó su uso como conocimiento en una decisión acotada.

Rule Engineering calcula conclusiones a partir de las premisas suministradas. Projection Engineering construye y congela el grafo de premisas sobre el que operan esas reglas.

Prompt Engineering da forma a las instrucciones. Context Engineering selecciona información para el cálculo. Projection Engineering formula la pregunta previa: ¿qué Claim representa esta información y por qué puede servir aquí como premisa?

Un prompt mejor no puede rescatar una premisa aceptada erróneamente.

El LLM es un trabajador, no la autoridad

Un LLM es un trabajador dentro de este proceso. Puede extraer Claims candidatos de registros no estructurados, dividir afirmaciones compuestas, identificar conflictos, solicitar pruebas ausentes y traducir el linaje a un lenguaje legible.

No es la autoridad. Su salida es otro Claim. La investigación sobre atribución distingue la generación fluida de las afirmaciones respaldables por fuentes identificadas (Medición de la atribución en modelos de generación de lenguaje natural). La investigación sobre la fidelidad del razonamiento también muestra que la cadena de pensamiento generada no funciona de manera fiable como traza causal de ejecución de una respuesta (Hacer que el razonamiento importe: medición y mejora de la fidelidad del razonamiento en cadena de pensamiento).

Si el mismo modelo extrae un Claim, lo acepta, elige la regla, explica el resultado y autoriza la acción, el proceso se derrumba en una única generación opaca. Una narrativa post hoc no es un registro de provenance.

La generación puede ser probabilística. La aceptación de Facts, la completitud y la autoridad para actuar deben gobernarse por separado.

La garantía estadística no puede explicar mi caso

La refutación más sólida es práctica. Las organizaciones no exigen una traza completa de derivación a cada responsable humano de una decisión. Supervisan resultados agregados, controles de calidad y auditorías por muestreo. ¿Por qué no gobernar los modelos del mismo modo?

La garantía estadística es útil y a menudo suficiente para mejorar un sistema. Sin embargo, no puede responder a la pregunta que formula una persona dentro de un resultado controvertido:

¿Cuál fue la premisa en mi caso?

La exactitud agregada no revela qué registro era erróneo, qué Claim se aceptó, qué política se aplicó ni qué prueba nueva podría sustentar una apelación. La garantía a escala poblacional y la impugnabilidad de cada caso resuelven problemas distintos.

Esa distinción define el alcance. Projection Engineering no es para todos los sistemas de IA. Es para sistemas que toman decisiones impugnables: crédito, remuneración, elegibilidad, desalojo, seguros, autorización médica y acciones similares en las que una persona debe poder inspeccionar e impugnar el conjunto de premisas. El Marco de Gestión de Riesgos de IA del NIST trata la rendición de cuentas y la transparencia como propiedades de todo el ciclo de vida, mientras que el Reglamento (UE) 2024/1689 exige el registro de eventos en los sistemas de alto riesgo.

Para la generación de bajo riesgo que nadie necesita impugnar, esta maquinaria puede ser excesiva. El alcance forma parte de la ingeniería.

El contrato mínimo

Un sistema que afirme practicar Projection Engineering debería poder responder afirmativamente a todo lo siguiente:

  1. ¿Distingue los registros originales de los Claims derivados y adjunta a cada Claim la fuente, el momento y el historial de transformación?
  2. ¿Descompone los Claims compuestos en proposiciones que puedan impugnarse por separado y registra quién formuló las cuestiones y por qué?
  3. ¿Conserva los Claims en conflicto y las alternativas rechazadas en lugar de eliminarlos?
  4. ¿Distingue false, unknown y not found, y exige un contrato de completitud antes de convertir la ausencia en negación?
  5. ¿Puede rastrear un Accepted Fact hacia atrás hasta las pruebas, la política, la autoridad y la versión, y una fuente invalidada hacia delante hasta las conclusiones afectadas?
  6. ¿Puede reproducir el GAF exacto y la instantánea de reglas utilizados en una decisión y obtener la misma conclusión bajo el mismo cierre?
  7. ¿Puede conservar un juicio humano recurrente como una política ratificada con alcance, excepciones y momento de entrada en vigor?
  8. ¿Están separadas la aceptación del Claim, la evaluación mediante reglas y la autoridad para actuar, con un procedimiento para reabrir una decisión pasada en lugar de borrarla?

Si alguna respuesta es negativa, el sistema está ascendiendo silenciosamente un Claim a Fact en algún lugar.

Por qué esta es una nueva disciplina de ingeniería

Los componentes ya existen: provenance, gestión de pruebas, grafos de argumentación, sistemas de mantenimiento de la verdad, event sourcing, motores de reglas, registros de auditoría, determinación jurídica de los hechos, metrología y razonamiento de mundo cerrado.

Los componentes no son una frontera de responsabilidad. Las bases de datos y ETL existían antes de que Data Engineering se consolidara como campo. Los servidores y scripts de despliegue existían antes de DevOps. Un campo se forma cuando fallos recurrentes dispersos por las organizaciones se reúnen bajo un rol responsable, una clase de entregables y métodos de verificación repetibles.

Actualmente ningún rol se hace cargo de esta pregunta de principio a fin:

¿En qué momento, por autoridad de quién y bajo qué política un registro de la realidad se convirtió en un Accepted Fact utilizable en una decisión?

Los ingenieros de datos se ocupan de los pipelines. Los ingenieros de conocimiento se ocupan de la representación. Los ingenieros de ML se ocupan de los modelos. Los expertos del dominio explican las reglas. Los operadores gestionan las excepciones. Entre ellos, la aceptación de hechos se disuelve en código de limpieza, prompts, lógica de aplicación, inferencia de modelos y hábitos no documentados.

Projection Engineering no afirma que todos sus componentes sean novedosos. Propone una nueva disciplina de ingeniería porque la propia frontera necesita un responsable, un entregable y una forma determinista de comprobar si se cumplieron sus promesas.

Volver a abaratar la verificación

El mundo abierto nunca se detiene. Llegan nuevos registros, cambian los testimonios, se recalibran los sensores y se modifican las políticas. Un sistema que espere a tener la realidad completa nunca actuará. Un sistema que oculte la incertidumbre actuará sin rendir cuentas.

Projection Engineering elige un contrato más limitado:

  • Conservar los Claims en lugar de borrar el desacuerdo.
  • Decir Accepted Fact siempre que Fact signifique una premisa autorizada.
  • Conectar cada aceptación con pruebas, política, autoridad, tiempo y alcance.
  • No convertir nunca unknown en false sin un contrato de completitud.
  • Congelar el mundo de decisión y las reglas realmente utilizados.
  • Reproducir la conclusión a partir de las mismas entradas cerradas.
  • Conservar el juicio recurrente como una política explícita y ratificada.
  • Reabrir las decisiones cuando cambian las pruebas en lugar de reescribir el pasado.

No es dueña de la verdad, no elimina el sesgo ni vuelve infalibles a las máquinas. Hace que el mundo limitado utilizado para una decisión sea lo bastante visible como para inspeccionarlo, impugnarlo, reproducirlo y repararlo.

Las matemáticas adquirieron poder social no porque respondieran todas las preguntas, sino porque quienes no habían presenciado una derivación podían inspeccionar qué se seguía de las premisas declaradas. La metrología hizo que las mediciones tuvieran peso al rodear los números de trazabilidad. El derecho hizo posible juzgar sin reproducir el pasado al separar las alegaciones de las premisas aceptadas.

La IA ya tiene aritmética. Lo que le falta es la institución alrededor de esa aritmética.

El objetivo de Projection Engineering es sencillo:

Volver a abaratar la verificación.

La realidad nos da Claims.

Las decisiones requieren Accepted Facts.

Projection Engineering proyecta Claims en un Graph of Accepted Facts auditable.

Artículos relacionados

  • La verdad no se descubre — por qué la realidad abierta nos da Claims mientras que los mundos institucionales acotados pueden producir hechos operativos
  • De Claims a GAF — la arquitectura técnica para proyectar Claims en un grafo auditable
  • La fluidez no es la verdad — por qué el lenguaje persuasivo debe sustituirse por pruebas observables y comprobaciones

Referencias