Use Case Exchange
Legra treats every reusable business capability as a Use Case. A Use Case can define its purpose, desired outcomes, personas, concepts, required data, Stories, workflows, policies, tests, dependencies, implementations, rights, and economic terms in one governed semantic package.
Its stereotype identifies the role it plays:
| Stereotype | What it represents |
|---|---|
| Use Case | Business demand or a reusable capability |
| App | A Use Case with a dedicated frontend or other application experience |
| Data Product | A data-supply Use Case with a DPROD-conformant product projection |
| Transform | A reusable transformation with typed inputs and outputs |
| API service | A callable capability exposed through typed Story contracts |
Apps and Data Products are therefore not separate proprietary package types. They are recognizable views over the same Use Case model.
One Store for reusable capability
The Use Case Exchange is federated. Publishers make signed package releases discoverable from their own sovereign workspaces. Catalogs index those public descriptions and offers, but do not take ownership of the source package or the workspace that adopts it.
The Store provides familiar views over the exchange:
- Apps with dedicated interfaces;
- Data Products that supply governed data and rights;
- Automations and transforms that perform reusable work;
- APIs and services backed by typed Stories; and
- all Use Cases organized by outcome, persona, concept, industry, publisher, price, compatibility, and trust evidence.
Each package page shows the information needed before adoption: business purpose, outcomes, personas, included Stories, dependencies, data requirements, requested permissions, tests, provenance, publisher, rights, price, and available implementations.
Apps are application-stereotyped Use Cases
An App’s Use Case Tree representation is its business definition. It explains why the App exists, which outcomes it should produce, who participates, which Stories provide its behavior, and how success is tested. Its dedicated frontend and remaining code implement that definition.
This makes an App inspectable and composable beyond its user interface. Humans and agents can reason about the same outcomes, personas, policies, tests, and Stories that the frontend uses.
Data Products are data-supply Use Cases
A Data Product uses the same Use Case structure for purpose, outcomes, personas, Stories, workflows, dependencies, and tests. It additionally exposes a DPROD-conformant description of its datasets, input and output ports, ownership, policies, service levels, offers, and contracts.
DPROD remains the interoperable product surface. The Use Case package provides the broader business and operational context behind it.
Adopt through a governed branch
Enabling a package is a controlled workspace change, not an opaque remote installation.
Legra resolves the selected release, dependencies, rights, permissions, and complete bounded token price before adoption. It then cherry-picks the package onto a non-default workspace branch, runs its validation and tests, and makes the resulting changes available for review. Only an authorized merge activates the capability on the target branch.
Updates follow the same process. A workspace can pin a release, explicitly adopt a later version, customize locally, or fork the package under a new identity with derivation provenance. A publisher cannot silently mutate an adopter’s workspace.
Value follows actual use
Package publication does not itself prove value. When an adopted Use Case or App performs work, its task and journal evidence retain the Use Case, Story, implementation, release, publisher offer, inputs, and measured outcome.
The resulting token price can independently compensate:
- the Use Case or App creator;
- Data Product and rights holders;
- compute, storage, custody, transport, and service providers;
- the Operator assembling the offer; and
- the NetworkOperator performing network admission, evidence, billing, and settlement.
The canonical composition is the data-logistics pricing formula:
See the Data Economy guide for the visual formula and an explanation of each independently attributable component.
Any component can be explicitly priced at zero. Software capabilities are not hidden behind feature tiers, and adopting an App never transfers ownership of the adopter’s workspace data to its publisher.
Related documentation
- Agent Guardrails — constrain agent execution to personas, Use Cases, Stories, branches, and token budgets.
- Branching — review package adoption and updates before merge.
- Events with Provenance — retain business and execution evidence.
- DPROD Assessment — see how Data Product projections align with the OMG standard.
- Use Case Tree Method Assessment — see how Legra operationalizes reusable Use Cases.