← AIML Website

ARCHITECTURE / FIRST DRAFT

One application. Multiple interfaces.

app_template already separates TypeScript models, feature services, React views, and Cloudflare API handlers. An AIML adapter can be an additional projection of the same authorized application state.

TypeScript domain models + services
  ├─ React components → JavaScript + HTML
  └─ explicit AIML adapter → validated JSON

Authenticated API → authorized state → AIML blocks
User intent + permitted blocks → proposed view
Validated view → browser renderer
Confirmed capability → original application API

What the adapter preserves

The records API in app_template requires a user and tenant context and filters records by organization and owner. Those checks belong to the server on every request. The semantic representation must include only data that user is authorized to receive.

What can be generated

TypeScript schemas can generate input/output contracts and capability descriptions. Content mappings, business meaning, side effects, and confirmation policy require explicit authoring. Arbitrary React components and application logic cannot be faithfully converted into a semantic protocol by a generic TypeScript compiler.

First experiment

The Studio uses an illustrative records document and renders reader/workspace layouts. It exercises the representation boundary without connecting to a real tenant database. The next increment should adapt one authenticated records feature end to end, then compare task completion and source fidelity across views.

Project boundaries

aimlwebsite hosts the protocol, schemas, examples, and Studio. aibrowser is the Chromium consumer. Publisher sites can host artifacts independently; protocol documentation retrieval should use pinned versions and integrity checks rather than search results as executable instructions.