AAA³: three planes, one project

§Definition

AAA3 stands for AI-Addressable Application — Three-Plane Architecture. The three A's say that an artificial intelligence can operate the application end to end by writing a document; the 3 says how it is built to make that possible: in three planes that operate on the same project.

AAA3

The official, technical name. It is the one used in URLs, searches, code and documentation.

AAA³

Optional visual form, for titles and diagrams.

AI-Addressable Application

What the three A's mean: an application that can be operated by writing its document, without handling its interface.

Three-Plane Architecture

What the 3 means: a human plane, a declarative plane and an execution plane.

The definition is a proposal by Iván Braida in the context of SyncThinkDesign, developed technologically at Braidata. The meaning of the 3 was formalized on 28 October 2026; until then the term was used internally only as AI-Addressable Application. Formalizing it changes no existing JSON contract or identifier. AAA is not used as a name on its own.

§The three planes

1 · Human plane

The visual interface through which a person creates, inspects and modifies the project.

2 · Declarative plane

The canonical JSON document: structured, versioned, validatable and readable by people as well as by programs and language models. It is the source of truth for the project's declarative state.

3 · Execution plane

The engine, runtime and APIs that interpret the document and produce actual behavior or results.

§Three planes. One project.

An AAA3 application lets its three planes operate on a coherent representation of the same project. The canonical document is the source of truth for the declarative state; the interface lets people manipulate it and the engine interprets it in order to run it. The planes can evolve technically on their own —a new interface, a faster engine, a new version of the format— as long as they respect the same contract.

None of the planes needs an AI. A person can use the application without any; an external AI, any AI, can operate it by writing or modifying the document, without handling the interface visually and without the application depending on a built-in model. AI is one possible client of the declarative plane, not a component of the architecture.

Paths, not a sequence

The relations interface ↔ document ↔ engine are not a required chain. An AAA3 application supports, where relevant, these paths:

• Person → interface → document.
• External AI → document.
• Script → document.
• Document → engine → execution.
• Engine → results and diagnostics.
• Results → human or automated review → evolution of the document.

Declarative state and execution state

The results of a run are not automatically part of the document. The runtime may keep transient state —a camera position, a game in progress, an intermediate computation— that is not persisted. Whatever does need to go back into the document does so through explicit rules, with the same validation as any other write. Without this separation, running a project would silently modify it, and the document would stop being a readable, comparable description of what was decided.

§Invariants

These six invariants say what an application must meet to count as AAA3, how each one is checked and where our ecosystem stands today. We distinguish what is implemented (with evidence that can be reviewed), what is partially verifiable and what is still an architectural goal.

§What AAA3 adds to an application with an interface and a backend

Almost any application has an interface, some data format and a server or an engine. Having all three does not make it AAA3. What sets the architecture apart are four guarantees a conventional application does not usually give, and the problems those guarantees solve. They are proposed invariants: the conformance matrix shows which ones each application meets today.

None of these ideas is new on its own. Open document formats, infrastructure as code and local-first software already treat a declarative representation as the source of truth. What AAA3 proposes is to bring them together into an explicit set of invariants with a precise purpose: that an application can be operated end to end by a person, a script or any language model, without depending on a built-in model. Whether that is an architectural contribution or a useful synthesis of known ideas is for others to judge.

§Conformance matrix

We reviewed the code and documentation of each application in the ecosystem. Yes means there is reviewable evidence: an automated test or shared code we checked. Partial means a written rule without a test, or evidence that covers only part. No means we found no evidence. Having an interface, a JSON file and an API is not enough to mark a plane or an invariant.

§Relation to SyncThinkDesign

AAA3 and SyncThinkDesign have independent identities. STD studies and proposes the continuous evolution of systems through synchronized processes that influence one another; AAA3 applies some of those principles to application architecture. Synchronization between the three planes lets authoring decisions, structured representation and system behavior feed back into one another, but the architecture does not on its own implement every principle of STD.

Nor do the three planes map one to one onto the four processes. Capture, Ideate, Execute and Optimize can happen on any plane: a person ideates in the interface, a model ideates by writing the document, the engine executes, a review optimizes. Forcing an equivalence would hide precisely what is interesting: that the processes cut across the planes.

§The current ecosystem

Today the ecosystem has one orchestrator and several providers. The orchestrator is Experience Creator, published as Alterverse: an editor for interactive 3D experiences and audiovisual pieces. An Experience Creator project can declare the assets it needs —a world, a texture, an interface, a piece of music— as requests to other providers, each written in that provider's native format. A resolver, running in the editor or on the command line, produces them. Each application has its own three planes; the braidata.aaa3.*.v1 contract connects their execution planes.

§The contract between applications

// request (abridged)
{
  "contract": "braidata.aaa3.request.v1",
  "requestId": "music",
  "operation": "audio.render",
  "spec": { /* the provider's native document, not reinterpreted */ },
  "inputs": [{ "name": "albedo", "sha256": "…", "mimeType": "image/png" }]
}

// result
{
  "contract": "braidata.aaa3.result.v1",
  "status": "succeeded",
  "diagnostics": [],
  "outputs": [{ "outputId": "<sha256>", "kind": "audio", "mimeType": "audio/wav", "url": "…" }]
}

§How it is built

A good share of AAA3's code is written with AI coding agents, under human direction and review; each repository's history records it commit by commit. We mention it because it is part of the experiment: if H5 is true, projects like this are where it should show first. Also because it leaves a question we still cannot answer well: how to attribute work fairly when part of it is produced by an agent.

§What AAA3 does not solve

• It does not capture signals from the world. Observations are still entered by hand.
• Correspondence between interface and document (invariant I) is not tested automatically in any application.
• Output stores are bounded memory on each provider; a fresh instance may have forgotten a result and the client has to ask again.
• The repositories are private. This site documents the architecture and the contract so they can be discussed, but the code cannot be audited from outside yet.

§References

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

§History