Skip to content

Case Study: Mapping the public Dollhouse Research portfolio into AILIS

This case study maps the current public Dollhouse Research portfolio into the AILIS layer model. The placements are editorial rather than official, but they are concrete enough to show how one research organization spans multiple layers of the stack.

Research home

Dollhouse Research

The public projects in this case study share one research home, but they do not all live at the same layer. Some are platform, some are protocol, and some are user-facing applications.

Observed pattern Most public Dollhouse Research work begins around L8 and stretches upward through L16.
  1. L0-L7 mostly depend on external model and infrastructure ecosystems.
  2. DollhouseMCP appears to span the widest range of AILIS layers.
  3. MCP-AQL clusters most strongly in L10-L15.
  4. Applied products surface at L16 but lean on lower shared layers.

Portfolio view

The first read is by project rather than by layer. That makes it easier to see that the public Dollhouse Research portfolio is not one thing. Some pieces are platform, some are protocol, some are generators and adapters, and some are applications sitting on top.

Core platform

DollhouseMCP server

The broadest public stack component: MCP capability exposure, agent tooling, memory, approvals, safety controls, and end-user product behavior.

  • L8
  • L10
  • L11
  • L12
  • L13
  • L14
  • L15
  • L16

Strongest anchors: tool invocation, discovery, routing and policy, memory, governance, application UX.

Catalog product

Dollhouse Collection

A public catalog and activation surface for personas, tools, and artifacts. It reads as a product at L16, but it likely depends on retrieval, manifests, and capability metadata underneath.

  • L9
  • L11
  • L16

Strongest anchors: discovery, metadata, catalog UX, installation and activation flows.

Protocol layer

MCP-AQL spec

The clearest protocol-centered piece in the portfolio. It looks less like an application and more like a proposal for semantic operations, introspection, routing signals, and transport-aware behavior on top of MCP.

  • L10
  • L11
  • L12
  • L13
  • L15

Strongest anchors: operation semantics, registry and introspection, routing cues, protocol control, conformance.

Reference runtime

MCP-AQL adapters and reference implementations

The adapter and example layer is where the spec becomes executable. These pieces seem especially useful for testing the boundary between invocation, discovery, transport, and policy.

  • L10
  • L11
  • L12
  • L13
  • L15

Strongest anchors: CRUDE-style operations, runtime introspection, transport contracts, enforcement edges.

Generator tooling

MCP-AQL generator and validator-style tooling

Generation and validation tooling might sit slightly differently from the reference adapters. They look less like end-user applications and more like infrastructure for producing, checking, and governing protocol artifacts.

  • L11
  • L12
  • L13
  • L15

Strongest anchors: manifest generation, policy shaping, conformance checking, schema and transport expectations.

Applied workflow

Elemental Surveys and other research applications

Public applied systems from Dollhouse Research likely show up as L16-first products, but they also reveal what is happening in context construction, orchestration, memory, and governance under the surface.

  • L8
  • L12
  • L14
  • L15
  • L16

Strongest anchors: workflow design, prompt assembly, human review paths, stateful sessions, application logic.

Companion app

Merview and adjacent public utilities

These are less about protocol invention and more about what people actually do with artifacts, reviews, drafts, or outputs once the lower layers have done their job.

  • L15
  • L16

Strongest anchors: reviewability, rendering, artifact handling, end-user workflow surfaces.

Layer view

The second read turns the same portfolio back into the layer model. This view makes it easier to see where the strongest Dollhouse Research examples cluster across the stack.

L0-L7

Mostly external substrate

The current public Dollhouse Research portfolio does not differentiate itself primarily at the facilities, runtime, model compilation, quantization, or inference-engine layers. That is useful signal in itself.

  1. L0-L2Infrastructure foundationNo strong public-first Dollhouse footprint today; these layers are mostly inherited from providers, devices, and external runtimes.
  2. L3-L7Model and inference stackPossible indirect influence through model choice, adapters, and serving assumptions, but not where the public portfolio seems to lead.
L8-L10

Where public stack behavior starts to become visible

This band is where Dollhouse systems stop looking like generic AI consumption and start looking like opinionated application interfaces.

  1. L8Context Construction & PromptingDollhouseMCP personas, skills, activation patterns, and research workflows such as Elemental Surveys likely express themselves here.
  2. L9Knowledge & RetrievalDollhouse Collection and related portfolio surfaces fit here where search, artifact lookup, grounding context, and installation metadata become useful.
  3. L10Tool & Function InvocationDollhouseMCP server capabilities, MCP-AQL semantic operations, and adapter runtimes look like especially strong examples at this boundary.
L11-L15

Where the portfolio may be most differentiated

A large share of the visible Dollhouse Research distinctiveness lives here rather than in model weights or generic application chrome.

  1. L11Addressing & RegistryDollhouse Collection metadata, MCP-AQL introspection, adapter manifests, and capability discovery are strong examples at this layer.
  2. L12Routing, Planning & PolicyMCP-AQL semantic routing, DollhouseMCP approval paths, and workflow selection logic appear to cluster in this layer.
  3. L13Transport & Flow SemanticsMCP-AQL transport rules, reference adapters, streaming behavior, and execution lifecycle semantics make this layer more concrete.
  4. L14Session, Identity & MemoryDollhouseMCP memory features, session continuity, user-scoped behavior, and stateful applied workflows seem like natural examples here.
  5. L15Governance, Safety & SchemaDanger-zone controls, review and approval logic, generator validation, and schema or conformance tooling are strong portfolio-specific examples.
L16+

Where people experience the portfolio directly

This is the layer most visible to outside users: sites, workflows, utilities, and research applications that make the lower layers legible through an actual product surface.

  1. L16Application & Domain LogicDollhouse Collection, Elemental Surveys, Merview, and the user-facing surface of DollhouseMCP all look like natural examples in this layer.

Implications for the atlas

This case study suggests a simple editorial rule for the layer pages: only add named Dollhouse Research examples where the public portfolio adds concrete examples.

  • It shows that a real portfolio can span many layers without collapsing the model.
  • It highlights that the current public Dollhouse Research work is strongest in the application-interface and orchestration bands.
  • It might give the AILIS layer pages more concrete examples without turning them into branded marketing pages.
  • It creates a path for future case studies from other ecosystems, which is probably the healthier long-term move.

That would make L10, L11, L12, L14, L15, and L16 the strongest candidate pages for brief named examples, while leaving L0-L7 mostly grounded in broader ecosystem references.