AAA³: três planos, um mesmo projeto

§Definição

AAA3 significa AI-Addressable Application — Three-Plane Architecture. Os três A dizem que uma inteligência artificial pode operar a aplicação de ponta a ponta escrevendo um documento; o 3 diz como ela é construída para que isso seja possível: em três planos que operam sobre o mesmo projeto.

AAA3

O nome oficial e técnico. É o que se usa em URLs, buscas, código e documentação.

AAA³

Grafia visual opcional, para títulos e diagramas.

AI-Addressable Application

O sentido dos três A: uma aplicação que pode ser operada escrevendo seu documento, sem manipular sua interface.

Three-Plane Architecture

O sentido do 3: um plano humano, um plano declarativo e um plano de execução.

A definição é uma proposta de Iván Braida no contexto de SyncThinkDesign, desenvolvida tecnologicamente na Braidata. O sentido do 3 foi formalizado em 28 de outubro de 2026; até então, o termo era usado internamente apenas como AI-Addressable Application. Formalizá-lo não altera nenhum contrato JSON nem identificador existente. AAA não é usado como nome independente.

§Os três planos

1 · Plano humano

A interface visual pela qual uma pessoa cria, consulta e modifica o projeto.

2 · Plano declarativo

O documento JSON canônico: estruturado, versionado, validável e legível tanto por pessoas quanto por programas e modelos de linguagem. É a fonte de verdade do estado declarativo do projeto.

3 · Plano de execução

O motor, o runtime e as APIs que interpretam o documento e produzem comportamento ou resultados reais.

§Três planos. Um mesmo projeto.

Uma aplicação AAA3 permite que seus três planos operem sobre uma representação coerente do mesmo projeto. O documento canônico é a fonte de verdade do estado declarativo; a interface permite manipulá-lo e o motor o interpreta para executá-lo. Os planos podem evoluir tecnicamente cada um por si — uma nova interface, um motor mais rápido, uma nova versão do formato — desde que respeitem o mesmo contrato.

Nenhum dos planos precisa de uma IA. Uma pessoa pode usar a aplicação sem nenhuma; uma IA externa, qualquer uma, pode operá-la escrevendo ou modificando o documento, sem manipular visualmente a interface e sem que a aplicação dependa de um modelo integrado. A IA é um cliente possível do plano declarativo, não um componente da arquitetura.

Caminhos, não uma sequência

As relações interface ↔ documento ↔ motor não formam uma cadeia obrigatória. Uma aplicação AAA3 admite, quando aplicável, os seguintes caminhos:

• Pessoa → interface → documento.
• IA externa → documento.
• Script → documento.
• Documento → motor → execução.
• Motor → resultados e diagnósticos.
• Resultados → revisão humana ou automatizada → evolução do documento.

Estado declarativo e estado de execução

Os resultados de uma execução não fazem parte automaticamente do documento. O runtime pode manter estado transitório — uma posição de câmera, uma partida em andamento, um cálculo intermediário — que não é persistido. O que precisa voltar ao documento volta por regras explícitas, com a mesma validação que qualquer outra escrita. Sem essa separação, executar um projeto o modificaria em silêncio, e o documento deixaria de ser uma descrição legível e comparável do que foi decidido.

§Invariantes

Estes seis invariantes dizem o que uma aplicação precisa cumprir para ser considerada AAA3, como cada um é verificado e em que estado está hoje o nosso ecossistema. Distinguimos o que está implementado (com evidência verificável), o que é parcialmente verificável e o que continua sendo um objetivo de arquitetura.

§O que o AAA3 acrescenta a uma aplicação com interface e backend

Quase toda aplicação tem uma interface, um formato de dados e um servidor ou motor. Ter os três não a torna AAA3. O que distingue a arquitetura são quatro garantias que uma aplicação tradicional normalmente não oferece, e os problemas que essas garantias resolvem. São invariantes propostos: a matriz de conformidade indica quais cada aplicação cumpre hoje.

Nenhuma dessas ideias é nova isoladamente. Os formatos de documento abertos, a infraestrutura como código e o software local-first já tratam uma representação declarativa como fonte de verdade. O que o AAA3 propõe é reuni-las em um conjunto explícito de invariantes a serviço de um objetivo concreto: que uma aplicação possa ser operada de ponta a ponta por uma pessoa, um script ou qualquer modelo de linguagem, sem depender de um modelo integrado. Se isso é uma contribuição arquitetural ou uma síntese útil de ideias conhecidas, cabe a outros julgar.

§Matriz de conformidade

Revisamos o código e a documentação de cada aplicação do ecossistema. Sim significa que há evidência verificável: um teste automatizado ou código compartilhado que conferimos. Parcial indica uma regra escrita sem teste, ou evidência que cobre apenas uma parte. Não significa que não encontramos evidência. Ter interface, JSON e API não basta para marcar um plano ou um invariante.

§Relação com SyncThinkDesign

AAA3 e SyncThinkDesign têm identidades independentes. STD estuda e propõe a evolução contínua de sistemas por meio de processos sincronizados que se influenciam reciprocamente; o AAA3 aplica alguns desses princípios à arquitetura de aplicações. A sincronização entre os três planos permite que as decisões de autoria, a representação estruturada e o comportamento do sistema se retroalimentem, mas a arquitetura não implementa por si só todos os princípios de STD.

Os três planos também não correspondem um a um aos quatro processos. Capturar, Idear, Executar e Otimizar podem acontecer em qualquer plano: uma pessoa ideia na interface, um modelo ideia escrevendo o documento, o motor executa, uma revisão otimiza. Forçar uma equivalência esconderia justamente o que é interessante: que os processos atravessam os planos.

§O ecossistema atual

Hoje o ecossistema tem um orquestrador e vários provedores. O orquestrador é o Experience Creator, publicado como Alterverse: um editor de experiências 3D interativas e peças audiovisuais. Um projeto do Experience Creator pode declarar os recursos de que precisa — um mundo, uma textura, uma interface, uma peça musical — como pedidos a outros provedores, cada um escrito no formato nativo do provedor. Um resolvedor, que roda no editor ou na linha de comando, os produz. Cada aplicação tem seus próprios três planos; o contrato braidata.aaa3.*.v1 conecta seus planos de execução.

§O contrato entre aplicações

// pedido (resumido)
{
  "contract": "braidata.aaa3.request.v1",
  "requestId": "music",
  "operation": "audio.render",
  "spec": { /* documento nativo do provedor, sem 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": "…" }]
}

§Como é construído

Boa parte do código do AAA3 é escrita com agentes de programação de IA, sob direção e revisão humanas; o histórico de cada repositório registra isso commit a commit. Mencionamos isso porque faz parte do experimento: se H5 for verdadeira, é em projetos como este que deveria aparecer primeiro. E porque deixa uma pergunta que ainda não sabemos responder bem: como atribuir o trabalho de forma justa quando parte dele é produzida por um agente.

§O que o AAA3 não resolve

• Não capta sinais do mundo. As observações ainda são inseridas à mão.
• A correspondência entre interface e documento (invariante I) não é testada automaticamente em nenhuma aplicação.
• Os armazenamentos de saídas são memórias limitadas de cada provedor; uma instância nova pode ter esquecido um resultado e o cliente precisa pedi-lo de novo.
• Os repositórios são privados. Este site documenta a arquitetura e o contrato para que possam ser discutidos, mas o código ainda não pode ser auditado de fora.

§Referências

• 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.

§Histórico