Lexicon
The inorigo® platform and metagraph paradigm introduce terms that may differ in meaning or scope from their use in other data management contexts. This lexicon defines terminology used across inorigo® documentation, covering platform-specific and metagraph concepts.
This Resource hub article is a stub. If you need further support regarding the subject, contact the inorigo® helpdesk.
Add-on
This refers to a module or component that is not included in the inorigo® core and requires separate installation.
Metagraph Builder is a part of the inorigo® core package, but the Access manager is an add-on.
Association
This is the legacy name for the data type Instance Node.
Also See: Instance Node
Association Definition
This is the legacy name for the data type Definition Node.
Also See: Definition Node
Attribute
Attribute icon
In the metagraph model, an attribute is a named property defined on a definition node. It describes a characteristic that instances of that definition can hold a value for — such as a name, a date, or a numeric quantity.
When working with a model it is important to know that you can chose to define the attributes on the defintion node itself, or create a definition that holds the attribute and then implement it as an attribute. If the attribute will be reused for many defiintion, this is a much more sustainable way to model.
The common primitive attribute types include
- String — text values of arbitrary length
- Integer — whole numbers
- Decimal — floating-point or fixed-precision numeric values
- Boolean — true/false
- Date — calendar date without time
- DateTime — calendar date with time
Attributes will be inherited to their children in a classification structure.
The definition node wheel has the attribute diameter.
Attribute value
An attribute value is the data stored on a specific instance node for a given attribute. Where the attribute defines the name and type, the attribute value is the actual content — the string, number, date, or other primitive that the instance holds for that property.
An attribute value is always scoped to an instance, it does not exist at the definition level The value must conform to the type declared by the attribute. IE if an attribute is of the Interger type, the attribute value must be a whole number.
The attribute "Release Date" (Date) defined on the defintion node "Album" holds the attribute value 1967-05-27 on a the instance node "Sgt Pepper's Lonley Heart Club Band".
Calculated Column
A Calculated Column is a column in a Knowledge Set whose value is derived from an expression rather than read directly from a source. It is defined within the Knowledge Set Builder and evaluated at query time, allowing values to be computed from existing columns — such as combining fields, performing arithmetic, or applying conditional logic.
A Calculated Column does not store data; it produces a value on demand based on the current state of the underlying sources.
Also see: Knowledge Set
A Calculated Column can for example compute the average of several numeric columns and round the result to one decimal place — producing a derived value without storing any data. For example,
$ROUND($AVG($PACK({Q1},{Q2},{Q3},{Q4})),1)computes the average of four quarterly values and rounds the result to one decimal place.
Classification
A classification relation is the relation type used to build taxonomies in the metagraph. It expresses that one definition node is a more specific kind of another — establishing a parent-child hierarchy between concepts.
The relation is bidirectional: traversed downward it reads Classifies, traversed upward it reads Is a kind of.
A Vehicle classifies Bicycle — a Bicycle is a kind of Vehicle.
Component
Refers to a contained (typically non-unique) part of a module or application. A Filter component, Search bar component, List component, Data Grid component, etc.
The Knowledge graph is a component that visualizes the connections between selected objects in the filter components as a tree of nodes and edges, sorted in columns.
Connector
A connector is a specialized type of Add-on that simplify data exchange between inorigo® and other IT systems.
inorigo® provides connectors to most common databases, such as PostgreSQL, MongoDB and Amazon Redshift.
Creator
A creator is one of three defined user roles in inorigo®. Creators design the Metagraph model and build solutions for operators using modules in the inorigo® platform.
The Workbench is the landing page for creators and developers.
Data Context
A Data Context is an isolated partition of the inorigo® database. Each Data Context maintains its own version of the model and its data, while inheriting from the Generic Data Context — the default partition present in all inorigo® installations. You can change between availble data context from the Launcer menu in the Workbench.
A Data Context does not replace the Generic Data Context but extends it, allowing the model to diverge independently without affecting the base. This makes it possible to maintain separate states of the model within a single installation.
Data Contexts are a legacy feature of the inorigo® platform. They are still supported and in use, but must be configured from the Model Builder > Administer Context.
It is possible to configure so that an user has another default data context than the Generic Data Context or is limited to a specifict data context.
Data contexts can be likenend to branches in a version control system
Data Grid
Data Grid is a spreadsheet-like interface for viewing and editing multiple entities simultaneously. It appears in two distinct contexts in inorigo®:
Data Grid for Applications
A component used within inorigo® applications, configured through a Recipe that defines which attributes are visible and editable. It is the primary interface for operators working within a governed, purpose-built application.
Also see: Recipe
Data Grid for Core
A standalone tool available from the workbench, where entities are retrieved through a query and presented in an editable grid without prior Recipe configuration. Data Grids for Core are temporary and not saved between sessions. It is intended for creators who need to perform quick bulk edits directly against the metagraph, without the overhead of building an application.
Definition Node
Definition Node icon
A definition node is a Data Type in inorigo®. Definition nodes are the most common entities in metagraph modeling. It is a typed node that defines what something is. It sits at the schema level, while an instance node represents an actual occurrence of that definition node.
Definition nodes were previously known as Association Definition. A collection of definition nodes can be referred to as "definitions".
Think of the definition nodes as the blueprint. "Person" would be a definition node, while "George Duke" is an example of an instance node.
Also see: Instance Node
Dependencies
An entity may have multiple dependencies on other entities. This can be very important to consider when, for instance synching entities in the Synch Tool or deleting entities. inorigo® provides tools like the Dependency Graph and Synch Tool to help visualize how different entities depend on each other.
You must include all required dependencies in the Synch tool before merging a pull request. (Otherwise the model can break).
Developer
A developer is one of three defined user roles in inorigo®. Developers leverage inorigo’s® web services, such as REST and GraphQL, to build tailored solutions.
The Workbench is the landing page for creators and developers.
Edge
An edge is a connection between two nodes in the metagraph. It represents a typed relation — defined at the definition level and instantiated between specific instance nodes. Edges in inorigo® are bidirectional, meaning the connection can be traversed in either direction.
Also see: Relation
An edge is distinct from an attribute — it connects nodes rather than holding a scalar value on one.
Entity
An entity is any discrete data object in the inorigo® platform. The term is not bound to a specific level of the metagraph model. It encompasses definition nodes, instance nodes, resources, and data sources alike. It is used broadly across node and object types, rather than for one specific kind.
A project group can contain almost any type of of entity, instance nodes, definition nodes, knowledge sets.
Generic Type
Generic Type is a legacy Data Typethat used to work in conjunction with Generic Unit and Specific Unit. It is no longer in use but may occur in older models.
Generic Unit
Generic Unit is a legacy Data Typethat used to work in conjunction with Generic Type and Specific Unit. It is no longer in use but may occur in older models.
Hypernode
A Hypernode is an uniquw concept of inorigo® and metagraph modelling. It is a node that functions as an edge, connecting multiple other nodes simultaneously. While a conventional edge connects exactly two nodes, a Hypernode can connect three or more, representing multi-dimensional relationships that pairwise edges cannot express.
Unlike a hyperedge in hypergraph theory, which encapsulates a set of connected nodes, a Hypernode is represented as a node in its own right. This means it can carry attributes, be queried, and be governed like any other node in the metagraph, making complex relationships both more maintainable and easier to reason about.
When designing a metagraph, hypernodes are created as definition nodes.
The Hypernode Manufacturing connects three nodes simultaneously: Activity, Product, and Organization.
In practice this means Manufacturing isn't just a label on a line between two things. it's a node that captures the fact that a specific Activity produces a specific Product within a specific Organization, all in a single structure. You can then add attributes directly to that relationship: for example a start date, a production volume, or a status, none of which would have a natural home on any of the three connected nodes individually.
ID
An ID in inorigo® is a universally unique identifier (UUID) assigned to every entity in the platform. It serves as the stable, system-level identity of a node, relation, attribute, or any other platform object, independent of its name or any other human-readable property.
UUIDs are generated automatically and do not change. They are the primary means by which entities are referenced in the API and in integrations.
You can usually copy the ID by right-click an entity and select Copy ID.
ID's persists even if the entity is renamed or moved. They consist of a sequence of characters and numbers for example: bfg26b7f-c8bd-1065-941a-b0b4008f0449
Instance Node
Instance Node icon
An instance node is a specific occurrence of a definition node. Where the definition node defines the concept, its name, attributes, and relationships, the instance node represents an actual entity of that type, holding concrete attribute values and participating in specific edges.
Instance nodes were previously known as Associations . A collection of instance nodes can be referred to as "instances".
Also see: Attribute Value, Defintion Node
For example, if Album is a definition node, then a specific album, such as Dark Side of the Moon, is an instance node of that definition.
Knowledge Set
A Knowledge Set is a denormalized flat table derived from one or more sources in the metagraph model. Sources, including any entities of the inorigo® model, external data sources, and other Knowledge Sets, can be filtered and joined together to produce a flat, queryable structure.
Knowledge sets are created through the Knowledge Set Builder.
Knowledge Sets serve as the primary interface between the metagraph model and external tools, consumed via API or used as data sources within inorigo® applications.
Launcher Menu
The Launcher Menu is a persistent navigation element present in the toolbar across inorigo's® modules and tools. It provides access to the full list of available tools and modules in the installation, and contains a submenu for switching between Data Contexts.
Note that the Launcher menu is not availble in the Portal or the legacy tools, Model Builder and Application Builder.
System Management is accessed from the Launcher Menu
Metagraph
A metagraph is the core data structure of the inorigo® platform. It is a graph-based model in which both nodes and edges can carry attributes. This makes it possible to represent not just connections between entities, but the properties of those connections as well.
The metagraph operates on two levels: a definition level, where concepts, attributes, and relations are modelled, and an instance level, where actual entities and their data reside. This separation allows the model to be queried, traversed, and extended without conflating structure with content.
The term distinguishes the inorigo® model from conventional graph databases and relational schemas — it is not simply a graph of data, but a graph that describes and contains its own model.
A metagraph can answer questions that cross organizational boundaries — connecting assets, people, processes, and documents in a single traversal, without requiring data to be moved or restructured first.
Nested Unit
A Nested Unit is an extension within a Recipe that brings in attributes from a definition related to the root data source. Where the root of a Recipe exposes the attributes of one definition, a Nested Unit allows attributes from a connected definition to be included alongside them — in the same data grid or input modal.
Nested Units are configured in the Application Builder and rendered within data grids and input modals.
See also: Recipe
For example, a Recipe rooted in Order could include a Nested Unit for Customer, surfacing the customer's name and contact details in the same interface without requiring a separate view.
Operator
An operator is one of three defined user roles in inorigo®. Operators view and interact with the applications, solutions, and model diagrams that are created for them. Typically, governing and analyzing the data and metadata of their specific domain.
Operators are often the domain experts and knowledge workers of an organization.
Presentation
Presentation Name is the human-readable label used to identify an entity in the platform interface. For definition nodes, the Presentation Name is always the value of the mandatory Name field. For instance nodes, it is derived from the Presentation Expression defined on their parent definition node.
Presentation Expression is an expression defined on a definition node that determines how its instance nodes are identified in the interface. It typically references attribute values on the instance node.
Most commonly {Name} is used to give the instance node the presentation name defined by its name attribute.
If no Presentation Expression is defined, the platform falls back to a default representation listing the definition name followed by its attribute values, for example: Definition=Car, Brand=Volvo, Model=240.
{First Name} + " " + {Surname} for a Person definition would render each instance's full name as its Presentation Name. (Given that First Name and Surname are attributes on Person).
Recipe
A Recipe is a configuration that controls how attributes are presented and interacted with in an inorigo® application. It defines which attributes should be displayed, which are editable, and which are hidden — scoped to a specific data source and its context.
Recipes are used in two primary contexts: data grids, where multiple entities are displayed and edited in a table, and input modals, where a single entity is created or edited through a traditional form-based interface. In both cases, recipes adapt the interface to what is relevant for a given use case, without requiring custom code.
A Recipe can also include nested units: Extensions that bring in attributes from related definitions beyond the root data source, allowing connected data to surface in context.
Recipes are configured through the Application Builder.
A Recipe configured for Bicycle might display Model, Frame Size, and Weight as editable fields, while keeping internal fields such as ID and Created By hidden.
Relation
A relation is the typed meaning carried by an edge. Where an edge is the structural connection between two nodes, the relation defines what that connection signifies — the nature of the relationship between the two entities.
inorigo® includes several built-in relation types:
- Classifies / Is a kind of: used in classification structures and taxonomies, where one definition node categorizes another.
- Implements / Implemented by: used to express that one node realizes or is realized by another
- Consists of / Is a part of: used in compositional structures, such as product hierarchies
Custom relation types can also be defined to meet domain-specific modeling needs.
Note that relations are bidirectional by nature. Each relation type has a forward and inverse label depending on the direction of traversal.
Also see: Edge
Animal classifies Dog — a Dog is a kind of Animal.
Traversed the other way: Animal classifies Dog.
In the metagraph this is represented by a single bidirectional edge between the two definition nodes, typed by the classification relation.
Specific Unit
Specific Unit is a legacy Data Typethat used to work in conjunction with Generic Type and Generic Unit. It is no longer in use but may occur in older models.
Taxonomy
A taxonomy is a hierarchical classification structure in the metagraph, built using the Classifies / Is a kind of relation. It organises definition nodes into parent-child hierarchies, where each child is a more specific kind of its parent.
Taxonomies are a primary tool for structuring the definition level of the metagraph — enabling consistent categorisation, inheritance of meaning, and controlled traversal across a domain.
Also see: Classification
For example: Vehicle → Land Vehicle → Bicycle → Mountain Bike.
© 2026 Inorigo AB. All rights reserved.