Data Products are supply. Use Cases are demand.
Legra connects them. Demand becomes an executable package. Supply becomes a governed product. Both are Use Cases; the stereotype selects the role.
The package-manager benchmark for business capability
A Data Product installs like a dependency. Meaning, ownership, authority, terms, provenance, and value travel with it.
Explore the universal package modelOne model, complementary roles
Governed supply
A Data Product is a supply-side Use Case.
- Purpose and outcomes
- Data and semantic models
- Interfaces and ports
- Provenance and quality
- Ownership and policies
- Offers and terms
Machine-readable demand
Ordinary Use Cases express executable demand.
- Desired outcomes
- Personas and Stories
- Required concepts and data
- Policies and authority
- Tests and acceptance criteria
- Composed sub-use-cases
One stable Use Case identity
Data Products add a DPROD projection. Apps add an experience. The Use Case identity stays the same.
Three contracts cooperate.
Product interface contract
Describes a Data Product port: what is consumed, in which shape, through which interface.
Bilateral Data Contract
Binds provider and consumer to rights, duties, service levels, delivery conditions, and prices.
Story invocation contract
Defines the typed inputs, outputs, persona, and behavior of one unit of business work.
The route runs from catalog to proven outcome.
01
Publish supply
A provider releases a Data Product with its ports, quality, policies, and offer.
02
Express demand
A consumer models outcome, people, data, behavior, and tests as a Use Case.
03
Discover and match
The Use Case Exchange matches demand to products and services by meaning.
04
Agree and authorize
The parties fix interfaces, rights, delivery terms, authority, and price.
05
Integrate and execute
Legra adopts the signed package on a governed branch and invokes its Stories.
06
Prove the outcome
The journal ties results to actors, inputs, authority, costs, and value flows.
Model the inspectable. Govern the code.
Concepts, rules, shapes, policies, Stories, and tests live as graph knowledge. Existing code joins through typed Story boundaries.
One business contract, replaceable implementations
The Story holds meaning, inputs, outputs, authority, and tests in the graph. The implementation behind it evolves.
Explore executable boundaries