AAA³ · definición v0.3 · estado a octubre de 2026
AAA³: tres planos, un mismo proyecto
Una arquitectura donde la interfaz humana, la representación declarativa y el motor de ejecución pueden evolucionar sin perder coherencia sobre el mismo proyecto.
Definición
AAA3 significa AI-Addressable Application — Three-Plane Architecture. Las tres A dicen que una inteligencia artificial puede operar la aplicación de punta a punta escribiendo un documento; el 3 dice cómo está construida para que eso sea posible: en tres planos que operan sobre el mismo proyecto.
AAA3- Nombre oficial y técnico. Es el que se usa en URLs, búsquedas, código y documentación.
- AAA³
- Representación visual opcional, para títulos y diagramas.
- AI-Addressable Application
- El significado de las tres A: una aplicación que se puede operar escribiendo su documento, sin manejar su interfaz.
- Three-Plane Architecture
- El significado del 3: plano humano, plano declarativo y plano de ejecución.
La definición es una propuesta de Iván Braida en el contexto de SyncThinkDesign, desarrollada tecnológicamente en Braidata. El significado del 3 se formalizó el 28 de octubre de 2026; hasta entonces el término se usaba internamente solo como AI-Addressable Application. Formalizarlo no cambia ningún contrato JSON ni ningún identificador existente. AAA no se usa como nombre independiente.
Los tres planos
- 1 · Plano humano
- La interfaz visual con la que una persona crea, consulta y modifica el proyecto.
- 2 · Plano declarativo
- El documento JSON canónico: estructurado, versionado, validable y legible tanto por personas como por programas y modelos de lenguaje. Es la fuente de verdad del estado declarativo del proyecto.
- 3 · Plano de ejecución
- El motor, el runtime y las APIs que interpretan el documento y producen comportamiento o resultados reales.
- Plano humanoPersona → Interfaz → Validación
- Plano declarativoIA externa · Script → Validación → Documento canónicomismas reglas para todos · fuente de verdad · versionado
- Plano de ejecuciónDocumento canónico → Motor · runtime · APIs → ResultadosEstado transitorio: no se persiste sin regla explícitaResultados → revisión humana o automatizada → Validación
Tres planos. Un mismo proyecto.
Una aplicación AAA3 permite que sus tres planos operen sobre una representación coherente del mismo proyecto. El documento canónico es la fuente de verdad del estado declarativo; la interfaz permite manipularlo y el motor lo interpreta para ejecutarlo. Los planos pueden evolucionar técnicamente por separado —una interfaz nueva, un motor más rápido, una versión del formato— siempre que respeten el mismo contrato.
Ninguno de los planos necesita una IA. Una persona puede usar la aplicación sin ninguna; una IA externa, cualquiera, puede operarla escribiendo o modificando el documento, sin manejar visualmente la interfaz y sin que la aplicación dependa de un modelo integrado. La IA es un cliente posible del plano declarativo, no un componente de la arquitectura.
Caminos, no una secuencia
Las relaciones interfaz ↔ documento ↔ motor no son una cadena obligatoria. Una aplicación AAA3 admite, cuando corresponde, estos caminos:
- Persona → interfaz → documento.
- IA externa → documento.
- Script → documento.
- Documento → motor → ejecución.
- Motor → resultados y diagnósticos.
- Resultados → revisión humana o automatizada → evolución del documento.
Estado declarativo y estado de ejecución
Los resultados de una ejecución no son, automáticamente, parte del documento. El runtime puede mantener estado transitorio —una posición de cámara, una partida en curso, un cálculo intermedio— que no se persiste. Lo que sí debe volver al documento lo hace por reglas explícitas, con la misma validación que cualquier otra escritura. Sin esta separación, ejecutar un proyecto lo modificaría en silencio, y el documento dejaría de ser una descripción legible y comparable de lo que se decidió.
Invariantes
Estos seis invariantes dicen qué tiene que cumplir una aplicación para considerarse AAA3, cómo se comprueba cada uno y en qué estado está hoy nuestro ecosistema. Distinguimos lo implementado (con evidencia que se puede revisar), lo parcialmente verificable y lo que todavía es un objetivo de arquitectura.
| Invariante | Qué exige | Cómo se verifica | Estado en el ecosistema |
|---|---|---|---|
| I · Correspondencia | Toda operación de autoría de la interfaz tiene una representación documentada en el modelo canónico. | Una prueba que recorra los controles de la interfaz y compruebe que cada uno escribe un campo, y que todo campo tenga un control o se declare como solo editable en el documento. | Objetivo de arquitectura. Es una regla escrita en SketchLab, Mapping Studio y Experience Creator; ninguna aplicación la prueba de forma automática. |
| II · Independencia | Ni el documento ni el motor requieren una IA embebida para funcionar. | Revisar las dependencias de ejecución y usar la aplicación completa sin ningún proveedor de IA configurado. | Implementado en las seis aplicaciones revisadas. En SketchLab existe una integración con IA, opcional y desactivable. |
| III · Interoperabilidad | Una especificación válida puede importarse y ejecutarse mediante interfaces documentadas. | Que alguien ajeno al proyecto produzca un documento válido y lo ejecute por la API o la línea de comandos, sin usar la interfaz. | Implementado en los cuatro proveedores (contrato braidata.aaa3.*.v1) y en Experience Creator (resolutor por línea de comandos). Parcial en Stellar Map. |
| IV · Consistencia | Modificar el proyecto desde la interfaz o desde un cliente externo respeta las mismas reglas de validación. | Comprobar que la interfaz y los clientes externos usan el mismo código de validación, y que un mismo documento es aceptado o rechazado igual por ambos caminos. | Implementado por código compartido en Experience Creator, Scene Creator, SketchLab y FrameLab. Parcial en Soundcrafter (dos motores). Sin verificar en Stellar Map. |
| V · Reproducibilidad | Se pueden identificar las condiciones necesarias para reproducir un resultado: versiones, recursos, parámetros y semillas cuando corresponda. | Registrar esas condiciones junto al resultado y repetir la ejecución para comparar. No exige determinismo absoluto donde hay procesos que no lo son. | Parcialmente verificable. Probado en SketchLab y FrameLab; parcial en el resto (ver matriz). |
| VI · Portabilidad | El documento puede transportarse entre instancias compatibles, con sus dependencias externas declaradas. | Exportar, importar en otra instancia y comparar; listar lo que el documento necesita fuera de sí mismo (recursos, servicios, bibliotecas). | Parcialmente verificable. La ida y vuelta sin pérdida está probada en SketchLab, Scene Creator y Stellar Map; las dependencias externas están documentadas solo en parte. |
Qué agrega AAA3 a una aplicación con interfaz y backend
Casi cualquier aplicación tiene una interfaz, algún formato de datos y un servidor o un motor. Tener las tres cosas no la convierte en AAA3. Lo que distingue a la arquitectura son cuatro garantías que una aplicación convencional no suele dar, y los problemas que esas garantías resuelven. Son invariantes propuestos: la matriz de conformidad indica cuáles cumple hoy cada aplicación.
| Garantía | En una aplicación convencional | En AAA3 | Problema que resuelve |
|---|---|---|---|
| El documento es un contrato público | El modelo de datos es interno —una base de datos, un estado en memoria— y cambia sin aviso. | El documento canónico está documentado, versionado y se puede validar fuera de la aplicación. | Que un tercero, un script o un modelo produzcan proyectos válidos sin acceso al código. |
| Correspondencia (I) | Hay operaciones que solo existen como clics o como estado de la interfaz. | Toda operación de autoría tiene un campo en el documento. | Que una IA no tenga que manejar la interfaz visualmente, con la fragilidad que eso implica. |
| Una sola validación (IV) | La interfaz y la API validan por separado y con el tiempo divergen. | La interfaz y los clientes externos pasan por el mismo validador. | Que un documento aceptado por un camino no sea rechazado, o interpretado de otra forma, por el otro. |
| Separación de estados | Lo que se decide y lo que el motor calcula se mezclan en el mismo almacenamiento. | El runtime puede tener estado transitorio, pero solo reglas explícitas lo convierten en documento. | Que ejecutar no cambie el proyecto en silencio, y que el documento siga siendo legible y comparable. |
Ninguna de estas ideas es nueva por separado. Los formatos de documento abiertos, la infraestructura como código y el software local-first ya tratan una representación declarativa como fuente de verdad. Lo que AAA3 propone es reunirlas en un conjunto explícito de invariantes con un propósito preciso: que una aplicación pueda operarse de punta a punta por una persona, un script o cualquier modelo de lenguaje, sin depender de un modelo integrado. Si eso es una contribución arquitectónica o una síntesis útil de ideas conocidas es algo que tendrán que evaluar otros.
Matriz de conformidad
Revisamos el código y la documentación de cada aplicación del ecosistema. Sí significa que hay evidencia revisable: una prueba automatizada o código compartido que comprobamos. Parcial significa una regla escrita sin prueba, o evidencia que cubre solo una parte. No significa que no encontramos evidencia. Tener una interfaz, un JSON y una API no basta para marcar un plano o un invariante.
| Aplicación | Humano | Declarativo | Ejecución | I | II | III | IV | V | VI |
|---|---|---|---|---|---|---|---|---|---|
| Experience Creator | Sí | Sí | Sí | Parcial | Sí | Sí | Sí | Parcial | Parcial |
| Scene Creator | Sí | Sí | Sí | Parcial | Sí | Sí | Sí | Parcial | Parcial |
| SketchLab | Sí | Sí | Sí | Parcial | Sí | Sí | Sí | Sí | Parcial |
| FrameLab | Sí | Sí | Sí | Parcial | Sí | Sí | Sí | Sí | Parcial |
| Soundcrafter | Parcial | Sí | Sí | No | Sí | Sí | Parcial | Parcial | Parcial |
| Stellar Map | Sí | Sí | Parcial | Parcial | Sí | Parcial | No | Parcial | Parcial |
| Aplicación | Contrato | Evidencia principal | Brecha principal |
|---|---|---|---|
| Experience Creator | experiencecreator.project.v1 | Esquema Zod en @experience-creator/schema; el editor y el resolutor por línea de comandos importan el mismo @experience-creator/core; la paridad interfaz ↔ JSON es una regla escrita del contrato; el estado del editor no se guarda en el documento. | La paridad no tiene prueba automática. La captura en tiempo real no es reproducible cuadro a cuadro; la exportación offline sí apunta a serlo. |
| Scene Creator | glbforge.scene v2.5 | La API usa normalizeDoc, el núcleo y el exportador del editor; la ida y vuelta cleanDoc → importar → cleanDoc es idempotente; 14 pruebas cubren la API y su uso desde Experience Creator. | Las referencias idb: y las rutas locales necesitan el navegador. La reproducibilidad del GLB byte por byte no está documentada. |
| SketchLab | braidata.sketchlab.v1 (y braidata.mappinglab.v2) | Interfaz, línea de comandos, API y pruebas usan lib/sketchlab/core.js; exportar → importar → exportar se verifica; la semilla se prueba de punta a punta; la IA integrada es opcional. | sketch.html carga p5 desde jsDelivr salvo en modo offline; sketch.png necesita Chromium en el servidor. |
| FrameLab | proyecto type: "framelab", versión 1.0 | La API ejecuta en jsdom los mismos módulos de validación y exportación que el navegador, sin reimplementarlos; una prueba comprueba que la misma solicitud produce el mismo outputId. | No hay regla escrita de paridad interfaz ↔ documento ni prueba de ida y vuelta del proyecto. |
| Soundcrafter | braidata.alsopack.v2 | API con 12 pruebas; los pedidos son idempotentes; la interfaz importa, valida, renderiza y exporta el documento. | Hay dos motores con validadores distintos —el del navegador en JavaScript y el de la API en Python— y no encontramos una prueba de equivalencia. La interfaz no edita todo el documento. |
| Stellar Map | starmap.v1 | Esquema JSON generado y probado; exportar → importar → exportar es estable byte por byte. | No expone el contrato braidata.aaa3.*.v1. No verificamos que su API de mapas use el mismo validador que el editor. Guardar el layout como estado transitorio fuera del documento está propuesto en su documentación, no implementado. |
Que la conformidad con los invariantes pueda comprobarse con pruebas comunes a todas las aplicaciones, empezando por la correspondencia (I) y la consistencia (IV), que hoy son las más difíciles de demostrar.
Relación con SyncThinkDesign
AAA3 y SyncThinkDesign tienen identidades independientes. STD estudia y propone la evolución continua de sistemas mediante procesos sincronizados que se influyen entre sí; AAA3 aplica algunos de esos principios a la arquitectura de aplicaciones. La sincronización entre los tres planos permite que las decisiones de autoría, la representación estructurada y el comportamiento del sistema se retroalimenten, pero la arquitectura no implementa por sí sola todos los principios de STD.
Los tres planos tampoco corresponden uno a uno con los cuatro procesos. Capturar, Idear, Ejecutar y Optimizar pueden ocurrir en cualquier plano: una persona idea en la interfaz, un modelo idea escribiendo el documento, el motor ejecuta, una revisión optimiza. Forzar una equivalencia ocultaría justamente lo interesante: que los procesos atraviesan los planos.
| Principio de STD | Qué materializa AAA3 | Qué requiere además | Estado |
|---|---|---|---|
| F2 Sincronización | Los tres planos actúan sobre el mismo proyecto: un cambio en el documento llega a la interfaz y al motor sin esperar una fase; entre aplicaciones, un cambio de origen regenera lo que lo consume (I5). | Mecanismos de propagación (M5) cuando intervienen varias personas o aplicaciones. | Materializado en parte |
| F3 Evolución orgánica y continua | El documento puede cambiar por partes y regenerarse sin rehacer el resto (I4). | Historial del documento para seguir su evolución (M1). | Materializado en parte |
| F6 Validación continua | Donde se cumple el invariante IV, toda escritura pasa por el mismo validador; hoy está verificado en cuatro de las seis apps. | Criterios sobre qué comprobar más allá de la forma (M4). | Materializado donde se cumple IV |
| F12 El diseño como evolución | El documento declara explícitamente qué puede cambiar en el sistema. | Decidir quién puede cambiar qué y qué se protege (M6). | Materializado en parte |
| F4 Emergencia | La ejecución busca reproducibilidad; si hay emergencia, ocurre en el ciclo de autoría (Q6). | Estudiar cómo evolucionan los documentos (Q1). | Abierto |
| F8 Captura permanente | Casi nada: AAA3 no observa el mundo. | Instrumentar el uso real del sistema. | No cubierto |
| F9 y F10 Silos y mentalidad | Nada por sí misma. | Organización del trabajo, no arquitectura. | Fuera de alcance |
El ecosistema actual
Hoy el ecosistema tiene un orquestador y varios proveedores. El orquestador es Experience Creator, que se publica como Alterverse: un editor de experiencias 3D interactivas y piezas audiovisuales. Un proyecto de Experience Creator puede declarar los recursos que necesita —un mundo, una textura, una interfaz, una pieza musical— como pedidos a otros proveedores, cada uno escrito en el formato nativo de ese proveedor. Un resolutor, que corre en el editor o en la línea de comandos, los produce. Cada aplicación tiene sus propios tres planos; el contrato braidata.aaa3.*.v1 conecta sus planos de ejecución.
| Proveedor | Qué hace | Operaciones | Estado |
|---|---|---|---|
| Scene Creator | Mundos 3D a partir de un documento de escena; exporta GLB con un núcleo real, sin navegador. | scene.glb | Funciona; acepta entradas encadenadas (texturas incrustadas en el GLB). |
| SketchLab | Bocetos generativos p5.js definidos por braidata.sketchlab.v1, con parámetros, semilla y lotes. | sketch.html, sketch.png, sketch.validate | Funciona. sketch.png necesita Chromium en el servidor; sin él responde 501. |
| FrameLab | Interfaces HTML (HUD, menús) con exportación idéntica a la del navegador. | ui.html | Funciona; usa los módulos de exportación reales dentro de jsdom. |
| Soundcrafter | Música a partir de un proyecto braidata.alsopack.v2: audio WAV y partitura. | audio.render | Funciona con límites: en servidores sin estado el render corre dentro de la petición, hasta 20 s de audio. |
El contrato entre aplicaciones
Cada aplicación del ecosistema tiene un formato JSON canónico y versionado. La regla de que la interfaz solo edita ese documento está escrita en SketchLab, Mapping Studio y Experience Creator; en las demás se observa en el código, pero no está documentada como regla.
Ninguna aplicación necesita un modelo de IA para funcionar, ni en tiempo de ejecución ni en el formato. Cualquier modelo puede escribir el documento desde fuera (lo llamamos BYO-AI: trae tu propia IA).
Todo proveedor expone el contrato braidata.aaa3.*.v1 bajo /api/aaa3: GET manifest (público), POST run, GET jobs/{requestId}, GET outputs/{outputId} y PUT inputs/{sha256} para encadenar.
// pedido (abreviado)
{
"contract": "braidata.aaa3.request.v1",
"requestId": "music",
"operation": "audio.render",
"spec": { /* documento nativo del proveedor, sin reinterpretar */ },
"inputs": [{ "name": "albedo", "sha256": "…", "mimeType": "image/png" }]
}
// resultado
{
"contract": "braidata.aaa3.result.v1",
"status": "succeeded",
"diagnostics": [],
"outputs": [{ "outputId": "<sha256>", "kind": "audio", "mimeType": "audio/wav", "url": "…" }]
}Los pedidos son idempotentes. La identidad de un pedido es el hash del proveedor, la operación, la especificación, los parámetros y el contenido de sus entradas: pedir lo mismo dos veces devuelve el mismo resultado sin volver a producirlo.
Los pedidos se encadenan por contenido. Una entrada viaja como sha256; si el proveedor no la tiene, responde missing_inputs, el cliente la sube y reintenta una vez. Si un recurso de origen cambia, cambia el hash de todos los pedidos que lo consumen y se regeneran.
La aprobación humana se registra como un pin sobre el hash aprobado. Un pedido fijado no se regenera ni forzando la ejecución; si su especificación cambió, el resolutor conserva lo aprobado e informa la diferencia. Solo una persona quita un pin. Es un mecanismo de gobernanza de AAA3, no un principio de SyncThinkDesign.
Las aplicaciones buscan reproducibilidad (invariante V), no determinismo absoluto. En SketchLab, la semilla controla randomSeed, noiseSeed y Math.random, y las pruebas de extremo a extremo comprueban que el mismo documento produce la misma imagen; en FrameLab, una prueba comprueba que la misma solicitud produce el mismo resultado. En el resto la reproducibilidad es parcial.
Cómo se construye
Buena parte del código de AAA3 se escribe con agentes de programación de IA, bajo dirección y revisión humana; el historial de cada repositorio lo registra commit por commit. Lo mencionamos porque es parte del experimento: si H5 es cierta, es en proyectos como este donde debería notarse primero. También porque deja una pregunta que todavía no sabemos responder bien: cómo atribuir con justicia el trabajo cuando parte de él lo produce un agente.
Lo que AAA3 no resuelve
- No captura señales del mundo. Las observaciones siguen entrando a mano.
- La correspondencia entre interfaz y documento (invariante I) no se prueba de forma automática en ninguna aplicación.
- Los almacenes de salidas son memoria acotada en cada proveedor; una instancia nueva puede haber olvidado un resultado y el cliente debe volver a pedirlo.
- Los repositorios son privados. Este sitio documenta la arquitectura y el contrato para que puedan discutirse, pero el código no puede auditarse desde fuera todavía.
Publicar la especificación de AAA3 —los tres planos, los invariantes y el contrato braidata.aaa3.*.v1— como documento independiente y versionado, para que alguien pueda implementar una aplicación conforme sin leer nuestro código.
Referencias
- Kleppmann, M., Wiggins, A., van Hardenberg, P., & McGranaghan, M. (2019). Local-first software: You own your data, in spite of the cloud. Onward! 2019, ACM.
- Morris, K. (2016). Infrastructure as Code: Managing Servers in the Cloud. O'Reilly Media.
Historial
| Versión | Fecha | Cambio |
|---|---|---|
| 0.1 | 2026-10-27 | Descripción del ecosistema como AI-Addressable Application: contrato, proveedores y encadenamiento. |
| 0.2 | 2026-10-28 | AAA3 pasa a presentarse como una implementación de SyncThinkDesign con identidad propia. |
| 0.3 | 2026-10-28 | Definición formal: AI-Addressable Application — Three-Plane Architecture. Tres planos, seis invariantes con su estado, garantías frente a una aplicación convencional y matriz de conformidad de seis aplicaciones. Sin cambios en contratos ni identificadores. |