Introducción

Existen 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 aprender en la escuela qué cosa es un verbo o un adjetivo. Las usa cuando todavía confunde el ayer con el mañana, cuando ignora que existen océanos al otro lado del mundo y cuando los números mayores que diez le suenan a magia. Las usa, en suma, porque esas preguntas son las piezas con las que el cerebro humano empieza a ensamblar la realidad para que tenga sentido.

Lo notable no es que el niño las use, sino que nunca deja de usarlas. Cambian los temas (pasamos de preguntar quién rompió el florero a preguntar quién firmó el contrato), pero la forma de la pregunta permanece idéntica a lo largo de toda una vida y a lo largo de toda la historia. Son, podríamos decir, invariantes: el armazón estable bajo la infinita variedad de lo que queremos saber.

Una intuición que la industria olvidó

Ahora traslademos 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 toda la información necesaria: sabe qué se le diagnosticó al paciente, quién lo atendió y cuándo. El problema no son los datos, sino que cada sistema los nombra a su manera. Uno exige una estructura rígida; el otro habla un dialecto distinto. Y se le va la tarde escribiendo traductores a mano (puentes, scripts, exportaciones a medida) 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 arquitectónica profunda en cómo la industria modeló la información durante décadas. Observa 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 declararan de antemano qué pregunta responde cada campo, la traducción dejaría de ser un proyecto y pasaría a ser una obviedad. No haría falta que dx_p y finding se conocieran entre sí: bastaría con que ambos admitieran que están respondiendo a la pregunta «¿cuál es el diagnóstico?». Esa es, enunciada en una línea, la apuesta del libro.

Que quede dicho desde ya: lo que está en juego no es ordenar el diagnóstico de un paciente como Vega, sino 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 pequeño 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) y la séptima, cómo, aporta los enlaces que amarran todo: los predicados. 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 innecesaria. Pero, como ocurre con los verdaderos cambios de perspectiva, cuando tomas esta premisa y la llevas hasta sus últimas consecuencias, el panorama entero cambia: cambia cómo diseñas una base de datos, cómo construyes un agente de inteligencia artificial, cómo conectas sistemas que hoy no saben hablarse, e incluso cómo le explicas un negocio nuevo a un programador que recién empieza. Lo hemos puesto a prueba. Funciona. Y el propósito de este texto es mostrarte la ingeniería exacta detrás de ese funcionamiento.

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? Sí, por una razón concreta. En ingeniería de software, entre enunciar una propuesta y poder usarla en producción hay un abismo. Para cruzarlo, una arquitectura como esta necesita cinco cosas, y cada una ocupa una parte del libro:

Qué es, exactamente, WQuestions

A lo largo del libro construirás conmigo una arquitectura llamada WQuestions. Conviene pensarla no como otra base de datos rígida, sino como un protocolo de normalización semántica: un motor que toma las preguntas cotidianas y las convierte en los ejes formales de un espacio geométrico. Es un mapa de coordenadas para el conocimiento. Al plantearlo como un estándar de interoperabilidad (y no como una taxonomía que se impone desde arriba) deja de competir con las ontologías existentes y empieza a hacerlas 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

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

Diseñé el texto apuntando a tres lectores simultáneos. Si el equilibrio es el correcto, cada uno encontrará valor sin estorbarse con el de los demás.

Para que las tres lecturas convivan, cada capítulo está estratificado: abre con una escena accesible y aumenta su densidad hacia el final. Si solo buscas la visión estratégica, el primer tercio basta; si buscas el sustento formal, sigue hasta las cajas de decisión de diseño; 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 unidad atómica, cómo la intersección de los ejes crea una geometría consultable, cómo se enlaza la causalidad, cómo se reconoce a una misma entidad (el Juan de la tienda y el de la clínica) aunque cada sistema le ponga un identificador distinto, y cómo todo esto se apoya en la tecnología que ya conoces: objetos, bits, grafos y cadenas de bloques.
• 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 completos (del banco a la clínica con su historia clínica, hospitalización y farmacia; de la municipalidad y sus trámites a la minera con su comisionamiento, mantenimiento y punchlists) y cuatro escenarios de alto estrés técnico (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

La arquitectura se expone con la convicción de quien la ha puesto a prueba, y se defiende con argumentos, no con adjetivos.

Empecemos.