Service Capability Tiers

Choose the current Provider or Autonomous Service tier without overstating language support.

Lenso keeps two out-of-process Service Capability Tiers distinct. They solve different ownership problems and use different runtime contracts.

Service Capability Tiers

The tier describes Service responsibility; it does not replace Module identity. A Support Ticket Module can move from linked delivery to Provider delivery and, later, into an Autonomous Service without renaming its business contracts.

Provider tier

A Provider exports one or more Modules to a Host. The Host authenticates calls, applies capability policy, schedules runtime functions, owns retries and queues, dispatches outbox events, and records Runtime Stories. The Provider implements the declared Module operations without becoming a peer Host runtime.

Use Rust or @lenso/service-kit for this tier. A compatibility lenso.service.v1 manifest describes Service packaging and local process startup. It is not the runtime Module discovery or digest authority. The live lenso.provider.v1 descriptor at /lenso/provider/v1 identifies one exact Service Release and its exported lenso.module-release.v1 releases, then provides the locked invocation, recovery, and acknowledgement boundary.

The Host verifies the Service Release, Module Release, Manifest, export, and contract digests before activating a Provider export. The generated TypeScript Service Kit and current CLI scaffold serve this exact Provider runtime while the Host retains queues, retries, effects, and Runtime Story ownership.

Provider is usually the right first process boundary when one team needs a separate implementation but the application still owns coordination.

Autonomous Service tier

The Rust lenso-autonomous-service runtime validates lenso.service.v2 and starts a Service-owned runtime graph. Current Rust framework capabilities include:

• generated direct HTTP/gRPC clients and servers from versioned contracts;
• business events with Service-owned Inbox and transactional Outbox handling;
• versioned durable workflows, timers, retries, child workflows, and compensation;
• Workload identity with SPIFFE production adapters and deterministic local identities;
• signed delegated context for actor, tenant, deadline, causation, and idempotency propagation;
• service-owned storage, migrations, health, operation records, and local Story segments.

Business traffic goes directly between Services through declared contracts. It does not pass through Console or a Host Provider proxy. System Plane outage does not stop Service-local execution.

Language support is explicit

TypeScript does not provide Autonomous Service parity.

@lenso/service-kit currently supports the Provider tier only. It does not implement the lenso.service.v2 runtime, Service Store, durable workflow runtime, Workload identity, delegated context verification, direct contract runtime, or Service-owned System Plane operations. Use Rust when those Autonomous Service capabilities are required.

This is a support boundary, not a roadmap promise. Do not label a TypeScript Provider as Autonomous merely because it runs in a separate process.

Move a boundary only for a concrete reason

Choose the Autonomous Service tier when at least one boundary is real:

• independent team or release cadence;
• isolated data authority;
• a distinct trust boundary;
• independently operated reliability or scaling;
• runtime behavior that must continue independently of the Host.

Otherwise keep the Module linked or use the Provider tier. Both preserve a clear later migration path without paying autonomous operational cost early.

Continue with Service System Plane for mixed topology composition or Examples for the Support Desk public lifecycle.