Compound software

Atelier is built on a simple promise: adding a new building block never breaks an existing composition. As the platform's catalog of entities, widgets, actions, and views grows, the applications you've already assembled keep working — unchanged.

This is what makes Atelier a compound platform. Every capability you add compounds with the ones already in place, instead of competing with them.

Three guarantees that compound

Atelier delivers this promise through three independent, composable registries. Each one decouples what you build from how it renders, fires, or aggregates — so growth is always additive.

Any entity renders in any widget

The surface plane compiles a page definition into an ordered list of declarative blocks, and a single, presentation-only renderer dispatches each block to the right widget. Entities and widgets are connected by an explicit binding, never hard-wired to each other.

Because dispatch happens over a registry of known, validated widget keys, a new widget is simply a new registry entry. It slots in alongside the existing ones and cannot disturb the pages that were already rendering. One entity can appear as a table on one surface, a map on another, and a detail card on a third — no new code per combination.

Any action fires from any surface

An action placement projects an action onto a surface — as a button, a form, or an inline control. Crucially, the availability check that decides whether a control is shown reuses the exact same authorization gates that govern whether the action can actually run.

That means a control you see is a control you're permitted to use: visibility and permission can never drift apart. Adding a new placement is a single declarative row; the underlying action and its rules stay exactly as they were.

Any aggregate is a view; any view is a surface

Every aggregate — counts, tallies, group-bys, KPIs — is defined as a declarative view, the one sanctioned aggregate primitive. The same view powers staff analytics dashboards and citizen-facing public feeds alike.

A new metric is a view plus a surface to show it on. There are no bespoke, one-off endpoints to write, secure, and maintain — which means there's nothing custom to break as the catalog expands.

Why the catalog grows safely

Three structural choices make additive growth the default, not the exception:

Principle	What it means for you
Declare, don't code	Every primitive is a declared row with a registry key — not a bespoke component. New capabilities are rows and registry entries, not new wiring.
A clean authoring/render seam	Authoring and rendering meet at a stable contract: declarative blocks plus registry keys. The renderer stays presentation-only; editing and authoring metadata live in a separate layer keyed to the same registry — the same pattern used by leading visual-authoring platforms.
Additive-only schema evolution	The underlying data model never deletes a column. Schemas only ever gain fields, so older compositions keep reading exactly what they always read.

Fork a template, extend it freely

This is the structural reason tenancy works the way it does in Atelier. You start from a template application and fork it into your own copy. From there you extend that copy — new entities, widgets, actions, and views — with confidence.

Because every extension is an additive registry entry or additive row over an additive-only schema, the platform's own future additions can never collide with yours, and your customizations can never break the template's evolution. The catalog grows on both sides, independently, and everything keeps composing.

That's compound software: a platform where every block you add makes the next one easier, and nothing you've already built gets left behind.