Knowledge design · Publisher: Legra
Define what your knowledge means, how it connects, and which rules it must satisfy.
For people who build and maintain shared business vocabularies. Manage concepts, relationships, taxonomies, and shapes as workspace knowledge. Give applications a common reference without requiring every workspace to disclose its data.
↓ is a kind of
↓ has policyholder
Constraint: Policyholder required.
The business results these modelling activities are intended to support.
People working with a policy need to know what its holder, type, and relationships mean. Define those concepts explicitly so teams can interpret connected information using a common reference. Different business viewpoints can remain distinct while their relationships are made clear.
A team receiving policy records needs to know which information is required. Express those requirements as shapes, then use platform validation to identify records that fail them. The intended result is a clear explanation of what must be corrected before publication.
Define concepts → Organize categories → Describe relationships → Set constraints. Ontologies describe meaning; taxonomies organize categories; shapes express requirements.
Propose a model change on a branch. Inspect the differences and review them with the people who depend on the model. Publish the agreed change while retaining its identity and history.
An insurance team adds a policy type beneath an existing category. It defines the policyholder relationship and makes that information required. A sample record without a holder reveals a validation violation. The team corrects the record and reviews the proposed model before publication.
Composable Business links these concepts to business actions. Data validation checks requirements; Deductive AI derives supported implications.
Static editorial description. Legra is pre-MVP; package releases and access requirements are not published here. Explore how the registry works.