AILIS
AILIS (AI Layer Interface Specification) is an OSI-inspired proposal for describing AI systems with a shared, layered vocabulary.
It is published as an open draft and designed for critique, iteration, and practical use.
Current Position
- Status: Early public draft (
0.1) - Core framing: 16 layers + cross-cutting control, observability, and security planes
- Contribution model: RFC-style proposal flow with open feedback
The Layer Model (At a Glance)
AILIS breaks the AI stack into practical architectural zones:
- L0-L2 Infrastructure Foundation Facilities and power, compute fabric, system and driver runtime
- L3-L7 Model and Inference Stack ML graph/compilation, numeric/quantization, tokenization, model parameters, inference/decoding
- L8-L10 AI Application Interface Context construction, retrieval/knowledge, tool and function invocation
- L11-L15 Orchestration Layers Registry, routing/policy, transport semantics, session/identity/memory, governance/safety/schema
- L16 Application and Domain Logic Product behavior and end-user workflow design
Why The Extra Detail Helps
Most architecture discussions fail because teams use the same word for very different layers.
AILIS helps separate those concerns so teams can answer practical questions early:
- Is this a routing problem, or a tool invocation problem?
- Is this a session memory issue, or a model behavior issue?
- Are we debating protocol semantics, or product UX?
Example Layer Mapping (Portfolio Snapshot)
| Project Area | Primary AILIS Focus |
|---|---|
| DollhouseMCP element runtime | L11-L16 orchestration, governance, and app behavior |
| MCP-AQL protocol surface | L11-L15 routing, transport, and safety semantics |
| Bridge integration runtime | L13-L15 transport, session identity, and policy |
| Collection workflows | L11-L16 capability distribution and operational composition |
Why It Exists
Most AI diagrams collapse too much into a few broad boxes.
AILIS pushes for enough granularity to discuss real interoperability questions, especially where teams usually struggle:
- capability registry and addressing
- routing and policy decisions
- transport and lifecycle semantics
- session and memory portability
- governance and safety boundaries
Why It Belongs in Dollhouse Research
Dollhouse projects are built around composable systems, so architecture language matters.
AILIS gives the portfolio a way to:
- describe where a tool or protocol sits in the stack
- reason about integration boundaries before implementation
- identify crowded vs under-served layers
- keep protocol and product decisions legible for collaborators
How It Connects To The Portfolio
AILIS is not a runtime dependency for DollhouseMCP, but it is a useful architecture lens:
- MCP-AQL maps strongly to tool invocation, routing, transport, and governance layers
- DollhouseMCP elements and ensembles map to composition and orchestration concerns
- Bridge maps to transport, session, and operational control boundaries
That framing helps teams discuss design decisions with shared terms instead of project-specific jargon.
How To Use It Today
- Map your system by primary and secondary layers
- Mark missing interfaces or weak boundaries
- Use the map to decide where to build, integrate, or standardize next
- Revisit your map after each release to track architecture drift