The mental model

Atelier is built on two ideas that shape everything else you do with it.

Declare, don't code. You describe what your application is made of — its data, its rules, its screens — as structured declarations. You don't write per-application backend code to make those things work.

Generate, don't build. From those declarations, Atelier produces the running experiences — the staff console, the public portal, and the APIs that back them — automatically. There is no separate build step where someone hand-codes the UI or the endpoints for each new application.

Everything else in Atelier is a consequence of these two ideas.

Four primitives you declare

An Atelier application is described entirely with four declared primitives. Each one answers a different question, and together they cover the whole surface of an application.

Primitive	Answers	Plane
Entity	What exists	Data
Action	What can happen	Execution
Surface	What is experienced	Surface
Identity & policy	Who may do what	Governs all three

Entity — what exists

An entity is a type with a schema: its fields, its relationships to other entities, declarative links, and the states it can move through. Entities are the data plane — the nouns of your application. A request, an asset, a proposal, a vote are all entities you declare.

Action — what can happen

An action is a gated, audited mutation. Each action declares its parameters, the criteria that must hold for it to run, the edits and records it produces, and the side effects it triggers. Actions are the execution plane — the verbs of your application. "Acknowledge", "assign", "approve", "close" are all actions, each one validated, recorded, and able to fan out to downstream effects.

Surface — what is experienced

A surface projects your entities and actions into something a person can see and use: lists, detail pages, dashboards, public-facing pages, and the placement of action controls within them. Surfaces are composed from widgets, layouts, and data bindings. They turn the underlying data and behavior into a usable interface without anyone writing screen code.

Identity & policy — who may do what

Authorization in Atelier is declared as data, not coded as branching logic. You declare access rules that reference entity fields, organizational structure, and membership-aware policy templates. Atelier compiles those rules into row-level filters applied at every read and write. This primitive governs all three planes at once: the same policy decides which records appear in a list, which detail pages open, and which actions a given person can take.

Authorization is fail-closed by construction. When no rule grants access, access is denied; the default is deny, never allow.

Capabilities that ride along

Three more declared capabilities build directly on the four primitives, so you get them by declaring rather than coding:

• Notifications — declare events, the rules that subscribe to them, and the templates that render them. Adding a new notification is a declaration, not a code change.
• Durable execution — declare that an action runs as a durable, long-running workflow rather than a simple synchronous mutation, with reliable execution and retries handled for you.
• Reports & analytics — declare aggregate views over your entities and surface them as reports and dashboards, including for public audiences.

Three experiences Atelier generates

From your declarations, Atelier generates the running application — with no per-application code.

• The staff console — a full operational back office with lists, detail pages, and dashboards, driven entirely by your surface and entity declarations.
• The public portal — citizen- and customer-facing pages generated from your public surface declarations and served through a strict, read-only public reader.
• The APIs — the entity, action, and public-read APIs that back both experiences, each request scoped to the caller's resolved tenant.

The staff console and the public portal are both driven by a single shared renderer. The renderer is presentation-only: it takes a list of declarative block descriptors and dispatches each one to the right widget through a registry. Each host — staff or public — drives that renderer through its own security-scoped data provider, so the same components render everywhere while every request stays governed by policy and isolated to its tenant.

Template and fork

You don't start every application from a blank page. Atelier lets you build a template application — a complete, declared set of entities, actions, surfaces, and policies — and then fork it onto each tenant. A new deployment inherits the template's full behavior, then diverges only where it needs to. This is how Atelier delivers many tailored applications from one well-designed starting point.

The one sentence to remember

The declarations are the runtime contract. There is no hidden code path and no derived cache standing between what you declare and what runs. The action engine reads your action declarations on every request; the renderer reads your surface declarations; the authorization layer reads your policy rules. When you change a declaration, you change the running application — directly, predictably, and with nothing to rebuild.