Admin Documentation

This section describes how to manage and configure the Elevating Patterns platform. The platform is graph-oriented: product data is modeled as a graph, not as tables. Core concepts such as entities, properties, relationships, lifecycle, and history reflect this model.

Meta Model, Data Model, and Data

The platform separates three layers:

• Meta model -- Provided by Elevating Patterns and not editable by customers. Defines the building blocks: EntityType, PropertyType, RelationshipType, their inheritance, and base relationships (has_rel, has_prop, etc.). See The Meta Model.
• Data model -- Domain types for the application (e.g. document, part, life_cycle_status). Defined by Elevating Patterns (e.g. lifecycle types), app developers, and customers (no-code / low-code modeling). See Entity Types, Property Types, and Relationship Types.
• Data -- Concrete entity instances of those types (e.g. a part with material number, name, etc.).

tip

Meta model → describes how models are built. Data model → describes which domain objects exist. Data → the concrete instances of those objects.

What's in This Section

Page	Description
The Meta Model	Core principles: immutability, versioning, key spaces, and entity addressing
Entity Types	Defining entity types, their properties, relationships, and inheritance
Property Types	All property type variants, BLOB handling, and enum properties
Relationship Types	Typed connections between entities, edge properties, and sub key spaces
Lifecycle	Lifecycle maps, statuses, and transitions
Traits	Dynamic mixins that can be attached to any entity instance
Lists, Enums & Virtual Properties	Ordered sub-entity lists, enum types, and computed properties
Lua Scripting	Scripting reference for keys, labels, virtual properties, and actions
Actions & Hooks	Callable actions and lifecycle hooks
REST API Reference	Complete HTTP API: authentication, CRUD, batch operations, blob storage
Built-in Reference	Quick-reference tables of all built-in system types
OpenAPI Specification	Interactive OpenAPI 3.0 reference

Deployment Architecture

The platform is built as a microservice architecture:

• Frontend -- User and admin UI.
• API Microservice -- REST endpoints for entities, sub-graphs, history, and incoming relationships; enforces permissions and roles; dispatches actions.
• Core Microservice -- Manages meta and data model; persistence across supported database types.
• Business-logic microservices -- Domain logic (hooks), typically implemented in Python, C++, Rust, Go, etc., invoked via actions from the frontend or API.

Action flow:

1. A frontend control triggers an action in the context of an entity.
2. The API checks permissions and roles, resolves the action definition and target hook.
3. The API sends a request to the appropriate microservice (context and optional new properties).
4. For synchronous actions, the result is returned to the API and then to the UI.

Integrations (Push and Pull)

Integrations with third-party systems typically follow two patterns:

• Push -- The platform sends data to the external system (e.g. via POST). Data is serialized for the target; mapping can be done on the platform side, the target side, or both.
• Pull -- The platform fetches data from the external system (GET). The response is deserialized and mapped; suitable for sync and scheduled updates.

When administering integrations, consider which flows are in use (push, pull, or both), where mappings are defined, and how errors and retries are handled (monitoring, logging, dead-letter queues).