The plane model

Atelier describes an entire application as data. To keep that data coherent, every configuration row is positioned along two independent axes at once. They answer different questions and should always be read together:

• The provisioning axis — who owns this row, and does each application get its own copy of it?
• The functional axis — which part of the system does this row belong to?

Think of them as latitude and longitude. A single row always has a position on both, and the two never collapse into one.

The provisioning axis — shared, template, or per-application

The provisioning axis governs tenancy: what is shared across every application on the platform, what serves as the starting point for a new application, and what each application owns privately once it is live.

Layer	Holds	Copied per application?
Shared vocabulary	Entity types and schema, platform-level definitions, the notification-event catalog, the surface and page-template registries, and the organization tree	No — one definition, shared by everyone
Template	A complete, working example application: its entities, actions, placements, notification rules and templates, and presentation config	It is the source that new applications copy from
Application	The same kinds of rows, copied and re-linked when an application is provisioned	Yes — created at provisioning time

The key idea: this distinction is data, not special-case code. A row's layer is simply a property of the row. When you provision a new application, Atelier copies the template's configuration in a single pass and rewires the copies to belong to the new application. From that moment on, an administrator edits their own copy using the same authoring tools — there is no separate "template editor" and "tenant editor." Every authoring surface automatically reads and writes the rows that belong to the caller's application.

Only the rows meant to be owned per-application are copied. Shared vocabulary and platform infrastructure are deliberately left out of the copy, so every application stays anchored to one canonical set of definitions. Cross-application authoring is gated and tenant-isolated by construction.

The functional axis — data, execution, and surface

The functional axis describes what a row is for. Atelier divides every application into three planes, each owning one clear concern.

Plane	Owns	The question it answers
Data	Entities, properties, relationships, and states	What exists?
Execution	Actions, preconditions, edits, and side effects	What can happen?
Surface	Widgets, layouts, data bindings, and interaction patterns	What does someone experience?

• The data plane is the shape of your domain — the records, their fields, how they relate, and the states they move through.
• The execution plane is everything that acts on that data — the operations a user or the system can perform, the conditions that must hold first, and the effects that follow (notifications, downstream updates, durable workflows).
• The surface plane is everything a person sees and touches — the pages, the widgets that render and edit records, and the way they are arranged. One shared renderer drives every surface, so a widget behaves identically wherever it appears.

How the two axes compose

Because the axes are independent, every row carries a coordinate on each — and that is what makes the model so flexible.

• An action lives on the execution plane. Before provisioning it belongs to the template; after provisioning, an identical action belongs to the application. Same functional role, different owner.
• A portal page lives on the surface plane and is owned per application. The page-template shape it builds on lives on the surface plane too, but in shared vocabulary — one template shape, reused everywhere.
• An entity type lives on the data plane and stays in shared vocabulary — schema is never copied, because every application speaks the same data language. Only its configuration (placements, dashboards, access rules) is owned per application.

The clean rule:

The provisioning axis tells you whether a row is copied when a new application is created. The functional axis tells you which subsystem the row belongs to.

This separation is what lets Atelier run thousands of distinct applications from one platform. The underlying engine concerns itself only with ownership; all of the richer "what is this and what does it mean" semantics live one layer up, where your configuration does. You declare the shape of your domain once, and the plane model keeps every piece in its proper place — shared where it should be shared, private where it should be private, and cleanly owned by the right subsystem throughout.