Skip to main content
Core’s architecture is organized into two layers. Each layer has a clear responsibility, and the dependency flows strictly in one direction — the interface layer depends on the data layer, never the reverse.

​
The Two Layers

​
Data Layer — What Exists, Who Can Act, and What Can Happen

The data layer is Core’s semantic foundation. It defines every entity the platform knows about, every operation that can be performed, every authorization rule that governs those operations, and every cross-cutting concern that applies across the system. This layer is interface-agnostic: it can be rendered as a web app, exposed as an API, or consumed by an AI agent. Objects represent domain entities. They carry metadata (title, icon, routing) and opt into platform features through capabilities (search, activity log, media attachments, soft delete). Interfaces add semantic meaning — a CustomerObject maps specific properties to platform-level functions like CRM features, while a DocumentObject enables file management behaviors. Actions represent operations. Each action declares typed parameters, authorization rules, and an execution handler. An action that takes an Order as a parameter is an Order action — there’s no separate registration step. Actions expose a machine-readable schema used by the form builder, API validation, and AI tool discovery. Workflows handle background processing: multi-step jobs, retries, and long-running operations on objects. They are always triggered explicitly — dispatched from an action or from a model observer reacting to property changes. Connectors bridge external systems. They manage credentials and provide a standardized client interface for calling external APIs. A Connector has two sides: an outbound side (calling the external API from actions and workflows) and an inbound side via Connector Importers. Connector Importers are the ETL sub-system of a Connector. They extract data from an external system, transform it into the platform’s data shape, and load it into the local database as Resource Objects — a special object type that mirrors external records (invoices from Fortnox, contacts from HubSpot, products from Business Central). Resource Objects are read-only projections of external data; mutations flow back through the Connector’s outbound API calls. Authentication covers system users (service accounts) and end-users, with optional auto-registration for portal scenarios. Authorization & Policies enforce object-level permissions (view, viewAny, update, delete), checked automatically for all standard operations. Notifications provide multi-channel delivery (email, SMS) with object references.

​
Interface Layer — How It Looks and Feels

The interface layer renders the data layer into user-facing experiences. Core owns the rendering centrally — client applications configure and extend, but don’t build from scratch. Layouts define application shells (navigation, sidebars, chrome). Pages define page-level templates: a TablePage renders an object index with filters derived from the schema; an ObjectPage renders a detail view with properties, actions, workflows, and activity. Data tables and Forms are higher-level components that derive their columns, filters, and fields from object schemas and action parameters. All interface components are backend-defined by default. Custom React is an escape hatch, not the starting point.

​
The Five Domain Primitives

A typical domain feature uses all five primitives working together: 
Object: Order
  ├── Schema: order_number, status, total_amount, customer (Properties)
  ├── Capabilities: search, activity log, soft delete
  ├── Actions: ApproveOrderAction, CancelOrderAction, SendInvoiceAction
  └── Workflows: InvoiceSyncWorkflow (triggered by ApproveOrderAction)
The schema provides validation rules to actions, column definitions to the table, and formatted values to the activity log — all from a single definition. Actions call workflows. Workflows write back to objects. The platform wires the rest.

​
Objects — the nouns

An Object is a domain entity: a customer, an order, a product, a case. Objects carry metadata (title, icon, routing URL) and declare which platform capabilities they opt into — search indexing, activity logging, media attachments. Objects are the anchors of the domain model. Everything else — actions, properties, workflows — is defined in terms of objects.

​
Actions — the verbs

An Action is a typed operation against one or more objects. Actions declare their own parameters, authorization rules, validation, and execution logic. An action that takes an Order parameter is automatically an Order action — there is no separate registration step. Actions are the primary way users mutate data. They also expose a machine-readable schema used by the form builder, API endpoints, and AI tool discovery.

​
Properties — the data shape

A Property is a typed, semantic descriptor for a piece of data. It knows its label, type, validation rules, how to format its value for humans, and how to serialize for frontend components. Properties work in two modes:
  • Standalone — created from a raw value, useful for display anywhere
  • Schema-bound — defined in a model’s schema, where they also drive validation, table columns, and inline editing

​
Workflows — background processes

Workflows orchestrate multi-step background jobs. They persist state to the database, track progress, support retries, and can report status in real time. Workflows are always triggered explicitly — dispatched from an action or from a model event.

​
Connectors — external data

Connectors bridge external systems through ETL importers that project external records as read-only Resource Objects inside the platform.

​
Design Principles

Describe what, not how. Core models domain concepts at a semantic level. The platform controls rendering and UX. This enables AI and API interfaces without additional work. Extension points over customization. Client applications extend Core through defined mechanisms (custom properties, custom pages, custom capabilities) — never by reaching into platform internals. Objects own their surface area. An object declares its own actions, capabilities, schema, and policies. The platform queries the object, not the other way around. No global indexes, no magic scanning. Explicit over implicit. Actions don’t emit events automatically. Workflows are dispatched explicitly. Side effects are visible in the code that triggers them. Schema-driven UI. Properties, action parameters, and object metadata provide enough information to auto-render tables, forms, detail pages, and API documentation. Custom UI overrides the default — it doesn’t replace the mechanism.

​
Feature Maturity

Every major primitive is versioned and tracked by maturity stage.
StageMeaning
StableProduction API. Versioned. Breaking changes require a major version bump and deprecation period.
ExperimentalArchitecture defined, implementation in progress. API may change between minor versions.
PlannedConcept documented, no implementation yet.

​
Current Status

PrimitiveStage
ObjectsExperimental
ActionsExperimental
Properties & SchemasExperimental
WorkflowsExperimental
Data TablesExperimental
FormsExperimental
Layouts & PagesExperimental
ConnectorsPlanned
Connectors — ImporterExperimental
Object InterfacesPlanned
NotificationsPlanned
Core does not yet have a stable v1. All APIs are subject to change between minor versions. Follow the upgrade guide when updating Core in your project.

​
Further Reading

Objects

The domain entity model, capabilities, and interfaces.

Actions

Typed operations, parameter schemas, and authorization.

Pages

Page templates and extension points for UI.