Admin Documentation

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

For detailed technical reference, see Meta Model and Core Entities.

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: Entity Type, Property Type, Relationship Type, their inheritance, and base traits (has_rel, has_prop, etc.).
• Data model
  • Domain types for the application (e.g. document, part, life_cycle_status).
  • Defined by Elevating Patterns (e.g. life-cycle types), app developers, and customers (no-code / low-code modeling).
• 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.

Entities and Metadata

Everything in the system is an entity—whether a type (e.g. entity_type) or a domain instance (e.g. part, document).

Every entity has at least the following metadata:

Field	Description
id	System-generated UUID of this entity version.
type_id	UUID of the entity's Entity Type.
root_id	Stable UUID across the entity's full history.
@key	Default is id; can be set by a Key Script (e.g. business key).
@self	System-generated key from <type_name>/@key.
@label	Default is @self; can be set by a Label Script.
previous	UUID of the previous version (for history).
created_by	User who created or last modified the entity.
created_on	Timestamp of creation or modification.
package_name	Name of the package the entity belongs to.

These fields support versioning and history (root_id, previous), human-readable keys in the UI (@key, @label), and package assignment for deployment and governance.

Entity Types

An Entity Type describes a class of objects (e.g. user, document, part) and is the central element for modeling domain objects.

Main attributes:

• Name — Technical name (regex: [a-zA-Z0-9_]+). A customer prefix (e.g. xy_document) is recommended for namespacing.
• Label / Plural Label — Human-readable display name (single or multi-language), used in the UI.
• Description — Longer description for admins and power users.
• Icon — Name of an icon from the Lucide icon library for UI display.
• Key Script (optional) — Low-code Lua script that computes @key. Properties used in the script should be unique to avoid collisions.
• Label Script (optional) — Low-code Lua script that computes @label.

An Entity Type also defines properties via has_prop relationships to Property Types, relationships to other Entity Types via Relationship Types, and Traits and Life-Cycle Maps that control behavior and state.

info

Entity Types can change over time. Multiple versions of an Entity Type may exist concurrently.

Property Types

Property Types define reusable attributes that can be used on many Entity Types (e.g. system_name, regex, required).

Supported property type kinds:

• String (string_property_type) — Plain text, often with regex.
• Rich Text (rich_text_property_type) — Structured/formatted text.
• Multi Language Text (multi_lang_property_type) — Text in multiple languages.
• Integer (int_property_type) — Whole number.
• Float (float_property_type) — Decimal number.
• Entity (entity_property_type) — Reference to another entity.
• Bool (bool_property_type) — True/false.
• Datetime (datetime_property_type) — Timestamp.
• BLOB (blob_property_type) — Binary data (e.g. files).

Reuse is done via has_prop:

• Define the Property Type once (e.g. system_name with a regex).
• Attach it to multiple Entity Types via has_prop; each attachment can override label, description, required, and uniqueness in that context.

Reuse existing Property Types where possible and set context-specific options (required, unique) on the has_prop relationship.

Relationship Types and has_prop

Relationship Types describe edges between entities (e.g. has_prop, domain relations). They typically have a source Entity Type and a target Entity Type (e.g. a Property Type).

The has_prop Relationship Type:

• Links an Entity Type to a Property Type.
• Defines the context in which that Property Type is used: whether the field is required, unique, and which label is shown in the UI (these are properties on the has_prop edge).

Using has_prop consistently keeps the data model coherent and allows one Property Type definition to be reused in many contexts.

Life-Cycle Maps

Life-Cycle Maps define states and transitions for an entity:

• Status — e.g. Draft, In Review, Released, Archived.
• Transitions — Allowed state changes.
• Start status — Initial state for new entities.
• Flags — e.g. is_readonly.

Life-cycle configuration is managed per Entity Type: define or adjust statuses and transitions, enforce allowed transitions for governance, and optionally tie read/write permissions to status (depending on configuration).

Entity History

History is represented by root_id and previous:

• Each change creates a new entity version.
• previous points to the prior version.
• root_id remains stable across all versions.

The API exposes history via:

• @history — Access older versions (commits) of an entity.
• @incoming / @reference — Query which entities reference a given entity.

These endpoints support auditing and impact analysis (which entities reference this one).

Data Model, Graphs, Sub-Graphs, and the API

The platform API is graph-oriented:

• Sub-graph GET — The depth query parameter loads a complete sub-graph of outgoing relationships from a starting entity. This avoids REST round-trips to load related data; care must be taken to avoid over-fetching (GraphQL is planned for more targeted queries).
• Sub-graph POST/PUT — Hierarchical structures can be written in a single request, reducing HTTP overhead and round-trips.

Use depth deliberately when designing API usage; monitor performance and data volume for large sub-graph operations.

Deployment Architecture (Microservices)

The platform is built as a microservice architecture:

• Frontend — User and admin UI.
• API Microservice — REST endpoints for entities, sub-graphs, history, 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).

---

For deeper technical detail, see Meta Model, Core Entities, and the API documentation.