Application Boundary Architecture

This page explains how a Cerebel connects to outside systems without letting transport or device concerns leak into the runtime.

The key idea is that a Cerebel may be deployed behind different application implementations depending on the host system. A CLI application, an HTTP service, a robotics gateway, or another host-specific boundary can all sit in front of the same runtime as long as they preserve the same normalized interaction contract.

Why an application layer exists

External tools and devices should not talk directly to substrates.

Instead, they connect through adapters to an application layer. The application layer validates and normalizes incoming requests, propagates runtime metadata such as interaction and session identifiers, and delegates to RAS for routing into the active runtime.

That split protects the runtime from transport-specific complexity while keeping the system open to multiple deployment shapes.

Layer model

The outside-world boundary is easiest to reason about as four cooperating layers.

Adapter layer

Adapters translate tool-native or transport-native data into normalized interaction requests and translate normalized responses back into tool-native outputs.

Examples include CLI adapters, HTTP adapters, websocket adapters, and device-gateway adapters.

Adapters may maintain connection state and apply local safety checks for physical commands, but they do not own domain reasoning or substrate orchestration.

Application layer

The application layer is the boundary implementation for a specific host system.

Its responsibilities are:

1. Accept normalized requests from adapters.
2. Validate and enrich boundary metadata.
3. Apply authorization or boundary policy.
4. Delegate interaction and lifecycle calls to RAS.
5. Return normalized responses to the adapter.

This layer should remain thin. It is an integration boundary, not a second decision-making runtime.

RAS layer

RAS is the control plane.

It is responsible for boot orchestration, runtime routing, readiness and degraded-state handling, and the interaction seam that chooses suitable runtime participants for a request.

RAS should not absorb transport logic or hardware protocol concerns.

Domain runtime layer

The runtime holds the functional participants that perform the work.

In the target architecture, that includes sensory laminae for ingestion, motor laminae for rendering, Cerebellum for timing and correction, and PFC or another decision authority for domain reasoning.

Canonical request path

The normalized path is:

1. A tool event arrives at an adapter.
2. The adapter converts it into a normalized interaction request.
3. The application layer validates the request and delegates to RAS.
4. RAS routes the request to suitable sensory, coordination, and decision participants.
5. The runtime produces a normalized interaction response.
6. The application layer returns that response to the adapter.
7. The adapter renders output or sends tool-specific commands.

This path is the same whether the caller is a person typing in a terminal or a physical device sending telemetry.

Multiple application implementations

The architecture assumes there may be several application-layer implementations for the same Cerebel.

Examples:

1. A CLI application for local operator workflows.
2. An HTTP application for service integration.
3. A robotics gateway for device-heavy environments.
4. A multimodal host application that coordinates speech, text, and vision inputs.

These applications may differ in transport, deployment model, and security policy, but they should all preserve the same boundary contract into the runtime.

Relationship to sensory-motor architecture

The application layer sits outside the sensory-motor cortex family.

The sensory-motor laminae are runtime participants that translate between external modalities and internal working representations. The application layer does not replace them. It provides the stable outside-world seam that feeds them.

This preserves a clean division of labor:

1. Adapters handle transport and device specifics.
2. The application layer handles boundary normalization and policy.
3. RAS handles orchestration and routing.
4. Runtime substrates and laminae handle perception, coordination, reasoning, and action rendering.

Rule of thumb

Tools execute outside the runtime.

Adapters bridge tools to the application boundary.

RAS orchestrates.

Substrates and laminae coordinate and translate inside the runtime.

Related references

1. Cerebrum System Architecture
2. Substrate Launch and Modulation Model
3. Application Boundary Contract
4. RAS Bridge Contract