Service System Plane

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 before choosing a Service kind. TypeScript does not provide Autonomous Service parity.

Follow the public lifecycle

Compose

Materialize the runnable Support Desk foundation:

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, 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:

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:

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:

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 for authentication, Surfaces, and Workload Control, or Examples for the integrated Support Desk acceptance.