---
title: Runtime Stories
description: Follow one business flow through the receipt-bound Story Module Surface.
---

A Runtime Story is the operator-readable record of one correlated business
flow. In the current product model, Stories are contributed by the exact
`lenso/platform-story` Module Release and rendered by its `console_ui_esm`
Surface inside Console.

Stories are not a top-level Console workspace, an application-wide score, or a
browser shortcut to Host administration routes.

## Composition ownership

The Support Desk product acceptance selects `lenso/platform-story` through its
checked-in capability pack. The runner builds the matching Console artifact,
then puts the exact Module Release digest, UI artifact digest, contract digest,
and Surface Grant in the connected `lenso.system.v2` topology.

Console loads the Story Surface only when those identities agree with the
connected app receipt. Changing a UI build, Module Release, or Business API
contract requires a newly matching composition and connection.

## Browser boundary

The Story Surface uses the injected typed Host API and a generated client
through same-origin Surface Gateway:

```text
Story console_ui_esm Surface
  -> generated client
  -> Console Surface Gateway
  -> declared Story Business API
```

For every request, Console Service rechecks:

- the authenticated Console actor;
- the exact connected System;
- Module and Module Release identity;
- UI artifact and contract digests;
- the allowed operation ID in the Surface Grant;
- target Module authorization.

Service bearer tokens stay on the server. The browser receives neither Service
credentials nor a generic endpoint for arbitrary records.

## What a Story shows

A Story groups records by stable correlation and causation identities. The
Surface can present:

- a business title and direct status;
- the initiating actor and tenant context allowed by policy;
- related Module, Service, event, function, and workflow nodes;
- causal edges and a time-ordered activity list;
- direct failure details without inventing a second app-wide health score.

Technical logs and traces remain owned by their runtime. A Story links the
business flow without replacing those tools or redefining Service ownership.

## Authoring guidance

Module authors should:

- keep business operation IDs and capability names stable;
- give user-facing operations clear display names;
- propagate actor, tenant, correlation, causation, deadline, and trace context;
- use declared events, functions, or workflows for follow-up work;
- keep secrets, tokens, and sensitive payloads out of Story records.

The Provider tier remains Host-owned and can be Rust or TypeScript. An
Autonomous Service owns its Rust runtime and Store; it propagates the same
bounded context over direct HTTP/gRPC, Event Contracts, or Durable Workflows.
See [Service Capability Tiers](/docs/autonomous-services).

## Connection and operational state

The Story Module and Surface have connection projections such as `connected`,
`unavailable`, `incompatible`, or `unmanaged`, each with a direct reason.
Workload operational state is separate.

If Console or the Story Surface is unavailable, the view is unavailable;
established business execution continues in its owning Host or Autonomous
Service. Console does not become a data plane dependency.

## Product acceptance

Run the product-level black-box path from `lenso-examples`:

```sh
pnpm acceptance:support-desk
```

The real browser loads both Support Ticket and Story Surfaces without manual
enablement, exercises ticket operations through Surface Gateway, and verifies
that the exact receipt, actor, tenant, contract, and operation identities stay
bound throughout the flow.

Continue with [Lenso Console](/docs/runtime-console) for System connection and
Surface loading, or [Module Console UI](/docs/console-packages) for artifact
authoring.