Introducción

Hay seis palabras que un niño de cinco años usa con la soltura de un experto: quién, qué, dónde, cuándo, cómo y por qué.

Las pronuncia mucho antes de que en la escuela le expliquen qué es un verbo. Las usa cuando todavía confunde el ayer con el mañana, cuando ignora que hay océanos al otro lado del mundo, cuando los números mayores que diez le suenan a magia.

Las usa porque esas preguntas son las piezas con las que el cerebro empieza a armar la realidad.

Lo notable no es que el niño las use. Es que nunca deja de usarlas.

Cambian los temas: de quién rompió el florero pasamos a quién firmó el contrato. La forma de la pregunta no cambia, ni en toda una vida ni en toda la historia.

Son el armazón estable bajo la variedad infinita de lo que queremos saber.

Una intuición que la industria olvidó

Ahora traslada la escena a una oficina, un martes por la tarde.

Una desarrolladora intenta que el sistema de facturación de una clínica converse con la plataforma estatal de salud. Tiene delante todo lo que necesita: sabe qué se le diagnosticó al paciente, quién lo atendió y cuándo.

El problema no son los datos. Es que cada sistema los nombra a su manera. Uno exige una estructura rígida; el otro habla otro dialecto.

Y se le va la tarde escribiendo traductores a mano, solo para que dos bases de datos se pongan de acuerdo sobre un hecho que, para aquel niño de cinco años, sería elemental.

Ese desgaste no es un gaje del oficio. Es el síntoma de una falla honda en cómo la industria modeló la información durante décadas.

Mira el mismo hecho clínico, un diagnóstico, tal como lo guardan tres sistemas que deberían entenderse:

{
  "dx_p": "I48.0",
  "f": "04/03/26",
  "cod_pac": 88213
}

{
  "diagnostico_principal": "Fibrilación auricular",
  "fecha_dx": "2026-03-04",
  "id_paciente": "VEGA-771"
}

{
  "finding": "atrial_fibrillation",
  "observed_at": 1741046400,
  "subject": "pat/771"
}

Si los tres sistemas dijeran de antemano qué pregunta responde cada campo, traducir dejaría de ser un proyecto.

No haría falta que dx_p y finding se conocieran entre sí. Bastaría con que los dos admitieran que responden a la misma pregunta: «¿cuál es el diagnóstico?».

Esa es, en una línea, la apuesta del libro.

Y que quede dicho desde ya: lo que está en juego no es ordenar el diagnóstico de una paciente como Gonzales. Es poder preguntar por toda la clínica a la vez (cuántos casos como el suyo, qué condición encabeza el mes) sin rearmar nada.

Ese salto de uno a todos es el que recorre el libro.

La tesis

Quizá notes un desplazamiento respecto de las seis preguntas con las que abrimos. Es deliberado.

Al exigirles precisión, dos preguntas que parecían una sola se separan. Y una que parecía pregunta resulta ser otra cosa:

De esas siete, seis fijan la posición de un hecho: quién, qué, dónde, cuándo, cuánto, cuál. La séptima, cómo, pone los enlaces que lo amarran todo.

Por eso conviene pensar cada hecho no como una fila de una tabla, sino como un punto en un espacio de coordenadas.

No hay trucos ocultos ni capas de complejidad de adorno.

Pero pasa lo que pasa con los cambios de perspectiva de verdad: cuando llevas la premisa hasta sus últimas consecuencias, el panorama entero cambia.

Cambia cómo diseñas una base de datos. Cambia cómo construyes un agente de inteligencia artificial. Cambia cómo conectas sistemas que hoy no saben hablarse, y hasta cómo le explicas un negocio nuevo a un programador que recién empieza.

Lo hemos puesto a prueba. Funciona. Este libro te enseña la ingeniería exacta que hay detrás.

Por qué hace falta un libro entero

Si la idea central cabe en un párrafo, la pregunta es legítima: ¿hace falta un libro entero?

Sí, y por una razón concreta. En software, entre enunciar una propuesta y poder usarla en producción hay un abismo.

Para cruzarlo, una arquitectura como esta necesita cinco cosas. Cada una ocupa una parte del libro:

Qué es, exactamente, WQuestions

A lo largo del libro construirás conmigo una arquitectura llamada WQuestions.

No es otra base de datos rígida. Es un protocolo de normalización semántica: un motor que toma las preguntas de siempre y las convierte en los ejes de un espacio geométrico. Un mapa de coordenadas para el conocimiento.

Y como es un estándar para que los sistemas se entiendan, y no una taxonomía impuesta desde arriba, no compite con las ontologías que ya existen. Las hace dialogar.

Si todas las aplicaciones del mundo estructuraran su información sobre los ejes de las preguntas, un agente de IA tendría que aprender a hablar una sola vez.La apuesta del libro

Por qué este libro aparece ahora

Si hubiéramos propuesto esta arquitectura hace cinco años, nadie la habría adoptado. Faltaba una pieza: algo capaz de traducir con soltura entre un modelo de datos y el lenguaje de las personas.

Hoy esa pieza existe. Son los grandes modelos de lenguaje. Su capacidad para invocar herramientas por su cuenta (function calling) reescribió las reglas de la integración.

Cuando un agente moderno necesita registrar una venta o leer un dato hospitalario, los cables ya están tendidos: domina JSON, valida esquemas, entiende tipos.

Lo que le sigue faltando a la industria es un vocabulario común que viaje por esos cables. Hoy cada API expone su dialecto privado, y el agente gasta tiempo y tokens aprendiendo un idioma nuevo por cada herramienta.

El costo de no tener ese vocabulario crece más rápido de lo que parece.

La tesis de este libro es que las preguntas son, por su propia naturaleza, ese idioma común. Y el momento tecnológico para implementarlo es ahora.

Para quién está escrito

Escribí el texto apuntando a tres lectores a la vez. Si el equilibrio es el correcto, cada uno encontrará lo suyo sin estorbar a los demás.

Para que las tres lecturas convivan, cada capítulo está estratificado: abre con una escena accesible y va ganando densidad.

Si solo buscas la visión estratégica, el primer tercio basta. Si buscas el sustento formal, sigue hasta las cajas de decisión. Si quieres ver código aplicado, tu lugar es la Parte V.

El recorrido

El desarrollo del modelo se reparte en seis bloques:

• Parte I · El problema. La torre de Babel de los datos: la información existe, pero está atrapada en esquemas que no se hablan. Lo ilustramos con el elefante en la habitación oscura (cada sistema palpa una parte y la nombra distinto) y apostamos a que la solución es anterior y más simple que cualquier base de datos.
• Parte II · Las siete coordenadas. Diseccionamos quién, qué, dónde, cuándo, cuánto, cuál y cómo (su carga semántica, sus trampas) y cerramos mostrando por qué son estas preguntas y no otras.
• Parte III · Cómo funcionan juntas. El ensamblaje: cómo un evento se vuelve la pieza mínima, cómo los ejes al cruzarse forman una geometría que se puede consultar, cómo se enlaza la causa con el efecto y cómo se reconoce a una misma persona (la María de la tienda y la de la clínica) aunque cada sistema le ponga otro identificador.
• Parte IV · Del lenguaje a los hechos. El puente entre la ambigüedad del lenguaje y la rigidez de los datos: el papel del verbo, el diseño del lexicon y los problemas lingüísticos difíciles.
• Parte V · En la práctica. La sala de máquinas: ocho dominios industriales enteros, del banco a la clínica y de la municipalidad a la operación minera, más cuatro escenarios elegidos para que el modelo crujiera (música, química, fútbol y contratos).
• Parte VI · IA, futuro y cierre. Cómo WQuestions potencia a los LLMs, qué aplicaciones desbloquea, la prueba más exigente (describirse a sí mismo), la seguridad del grafo compartido y los retos pendientes.

Una nota sobre el método

Empecemos.