Introduction

Declare the interesting 20%, Atelier generates the rest

Atelier is a platform for building civic and operational software by declaring it, not coding it. You describe an application — its data, the actions that can happen to it, the screens that render it, the notifications it sends, who is allowed to do what, and the public portal it serves — and Atelier generates the running, multi-tenant product: a staff admin console, a citizen-facing portal, and the APIs behind both.

That description is data, not code. You express it as a single declarative sheet, or edit it live in the same authoring surfaces your team uses every day. There is no build step to wire up, no glue code to maintain — when the declaration changes, the running application changes with it.

This mirrors the philosophy of our sibling platform Martha for AI agents — we handle the production-readiness so you can focus on the part that's unique to you. Where Martha's primitives are workflows, integrations, document processing, and delivery, Atelier's primitives are Entities, Actions, Surfaces, and Identity. Atelier also builds on Martha directly: long-running submissions and durable, workflow-mode actions execute on Martha's durable-execution engine.

Compound software

The core promise is compound software: a growing catalog of building blocks — entity types, widget kinds, action shapes, notification channels, analytical views — that you combine freely, where new pieces add to the catalog without breaking what already composes.

• Any entity can render in any widget.
• Any action can fire from any surface.
• A new deployment comes up fully configured by forking one complete, worked example, then diverging by editing its own copy.

The unit of leverage is the declaration. Author it once against a template, and every application forked from that template inherits a working product — console, portal, APIs, authorization, and notifications included — and can then evolve independently.

How Atelier is organized

Atelier is built around one shared data substrate and three ways of thinking about what you declare.

The ontology engine

At the foundation is a schema-evolving data engine built on Postgres with spatial and time-series extensions. Entity types, fields, declarative links between entities, and analytical views are all defined as data and take effect immediately — no migrations to write, no redeploys to run. Every application's data is tenant-isolated by construction, and all reads flow through one consistent, cursor-paginated API.

Three planes

Everything you declare falls into one of three planes — a simple mental model for what an application is:

Plane	Question it answers	What you declare
Data plane	What exists?	Entity types, fields, links, views
Execution plane	What can happen?	Actions and their effects
Surface plane	What is experienced?	Pages, portal pages, public surfaces, widgets

Notifications, identity and authorization policy, and reports layer onto these planes. The single artifact that expresses all of them together is the declarative sheet, applied through a safe, ordered pipeline: parse, validate, diff, then apply.

Template-and-fork tenancy

Atelier separates a shared vocabulary (the catalog of types and registries) from a template (one complete, forkable worked example) and from each tenant (an independent copy). Standing up a new tenant is a one-shot fork that copies the template into a self-contained application, rewiring its internal references so it runs on its own. Each tenant then edits its own copy — using the very same authoring surfaces that produced the template — so every customer gets a working app on day one and can diverge whenever they need to.

Capabilities you get

• Declare-not-code. Define data, behavior, screens, and policy as a single editable description; Atelier runs it.
• Generate-not-build. A staff console, a citizen portal, and the supporting APIs are produced from your declaration.
• An action engine. Model what can happen to your data — from simple state changes to durable, long-running workflows — and fire those actions from any surface.
• A surface and widget catalog. Compose pages from a shared set of widget kinds. Any entity can be rendered by any compatible widget, all driven by a single shared renderer so the console and portal stay visually consistent.
• Live authoring surfaces. Edit entities, actions, notifications, dashboards, and policy in-product, with live preview that matches what ships.
• Notifications as configuration. Subscribe to events and author message templates as data — add a new notification without touching code.
• Durable workflows. Long-running submissions and processes execute reliably on a durable-execution backend.
• Analytics and a citizen portal. Define aggregates and KPIs as views, surface them in dashboards, and expose public-facing tallies and forms through a built-in citizen portal.
• Authorization as data. Access policy is declared, not branched in code, and is fail-closed by construction — every read and write resolves the caller's grants and compiles them into the query itself, so data a caller isn't entitled to is never returned.

Where to go next

Continue with the conceptual guides to see how each plane works in practice, how the declarative sheet is structured, and how to author your first application.