---
title: Service System Plane
description: Connect an exact lenso.system.v2 mixed topology without turning Console into a deployment plane.
---

The Service System Plane describes how one Lenso app's Host, Provider Services,
Autonomous Services, Modules, Workloads, contracts, and management adapters fit
together. The current mixed-topology contract is `lenso.system.v2`.

This topology is not a service mesh, business request router, process launcher,
or production deployment record. It is the exact graph Console validates when
connecting a System.

## Composition and topology have different jobs

| Contract | Responsibility |
| --- | --- |
| `lenso.app.json` | The application composition and lock: app revision, content digest, immutable Module Releases, dependencies, and implementation bindings. |
| `lenso.system.v2` | The connected topology: stable object identities, ownership, contracts, Workloads, Adapters, and relationships. |
| Management Binding | The exact Console authority and supported target-owned management paths for that topology. |

The topology is derived from the composed app and its running targets. It does
not widen the App Composition or select a production target.

## Mixed topology

System v2 keeps each kind explicit:

- a **Host** owns linked Modules and Provider runtime coordination;
- a **Provider** keeps compatibility/process metadata in `lenso.service.v1`,
  serves exact `lenso.module-release.v1` releases through `lenso.provider.v1`
  at `/lenso/provider/v1`, and may be implemented in Rust or TypeScript;
- an **Autonomous Service** uses Rust `lenso.service.v2` and owns its runtime
  and Service Store;
- a **Module** keeps its business identity across linked or service-backed
  delivery;
- a **Workload** names one executable part of a Service;
- contract relationships name exact Producers, Consumers, versions, and
  tenancy requirements;
- a management **Adapter** exposes only declared target-owned operations.

See [Service Capability Tiers](/docs/autonomous-services) before choosing a
Service kind. TypeScript does not provide Autonomous Service parity.

## Follow the public lifecycle

### Compose

Materialize the runnable Support Desk foundation:

```sh
lenso app compose ./support-desk --blueprint support-desk --apply
```

The blueprint contains `auth`, `notification-worker`, and `support-api`. The
pack-backed Support Ticket and Story topology is exercised by the
[product acceptance](/docs/examples), which registers its service-backed
Provider before startup.

### Run locally

Start the composed Host and auto-start Provider Services. Add the existing
Console checkout to run the connected local path:

```sh
cd ./support-desk
lenso dev up --console-root ../lenso-console
```

The lower-level `lenso system dev` command is a System Sandbox. It does not
start the composed Host or Console and does not connect Console; in App
Composition mode it does start the selected service-backed Provider workloads
and the Local Control Adapter inside the bounded sandbox run.

### Connect

With `--console-root`, `lenso dev up` creates loopback-only signed enrollments,
assembles `.lenso/console-connect.json`, and applies the exact connection before
reporting the System ready. For a separately prepared local bundle, use:

```sh
LENSO_CONSOLE_TOKEN='<operator-session-token>' \
  lenso console connect \
  --console-url http://127.0.0.1:3030 \
  --bundle .lenso/console-connect.json
```

Console checks each active enrollment, topology digest, Management Binding,
and advertised Core contract before storing the connection. The local path
accepts loopback targets only; it is not a remote production self-service path.
The bundle may also carry an exact Console Composition artifact effect. Tokens
and signing material are never printed or stored in the bundle.

### Status

Read the connected graph through Console or:

```text
GET /api/console/v1/system
```

System, Service, Module, Surface, and Adapter projections report `connected`,
`unavailable`, `incompatible`, or `unmanaged` with a direct reason. Workload
operational state is separate. An unavailable Local Control Adapter reports
Workload observation as `unknown` and rejects mutation without queueing or
fallback.

## Business traffic stays outside the System Plane

A Module Surface calls its generated client through Surface Gateway. Console
Service rechecks the Console actor, exact connected System, artifact digests,
contract digest, and allowed operation IDs, then calls the declared Business
API without exposing target credentials to the browser.

Autonomous Service Data Plane calls use direct HTTP/gRPC or Event Contracts.
They do not pass through Console, and established Service-local execution does
not depend on System Plane availability.

## Console authority stays narrow

Console may connect the exact topology, report direct state, load eligible
Module Surfaces, and invoke supported target-owned operations. It does not:

- create, adopt, delete, release, deploy, roll back, or repair production
  Workloads;
- select a production target;
- mutate a Service Store directly;
- give the browser Service or Adapter credentials;
- turn topology status into a second application-wide score.

Production delivery remains repository-, platform-, and operator-owned. The
System Plane can describe the resulting objects without becoming their runtime
owner.

Continue with [Lenso Console](/docs/runtime-console) for authentication,
Surfaces, and Workload Control, or [Examples](/docs/examples) for the integrated
Support Desk acceptance.