Authoring

Authoring is where an application stops being an idea and becomes rows of configuration that the platform renders, runs, and serves. Atelier gives operators a suite of visual editors — no code, no deploys — and guarantees the platform's core promise at the data layer: what you author is what your tenants get.

Every other capability in Atelier — the action engine, notifications, presentation, the citizen portal, durable workflows — is declared through these editors. You describe the application you want; Atelier generates and runs it.

What you author

The authoring suite is a catalog of focused editors, each responsible for one part of an application:

Editor	What it controls
Application hub	App identity — label, icon, color, navigation order, enablement, and which capabilities are switched on. The unit you fork to a tenant.
Entity bindings	Which data types an application surfaces, and how each binding behaves — visibility, role-based visibility, and ordering.
Presentation	How records appear: list columns, filters, search fields, default ordering, and per-field display.
Dashboards	Chart and metric layouts, authored against a live preview that renders exactly as the deployed dashboard will.
Action editor	The operations users can perform, their parameters, the fields they create or edit, and the side effects they trigger.
Notification rules	Who gets notified when an event fires — recipients, channels, and the template to use.
Notification & report templates	The subject and body of every message and document, with live preview.
Portal authoring	Citizen-facing pages — routes, layouts, and embedded content — compiled and published on save.
Branding & campaigns	Live, tenant-owned presentation that takes effect immediately.

The application hub is the home base: a list-and-create surface plus a tabbed detail view for each application that links out to every deep editor. It orients you across the whole application without trapping editing state in one giant form.

The template-and-fork model

Atelier separates authoring from running tenants with a deliberate two-plane model.

You author against a template — a master copy of an application that no live tenant reads directly. When the application is ready, you fork it onto a tenant: a one-shot, full-catalog copy that carries the application identity, its entity bindings, actions and their side effects, presentation, dashboards, notification configuration, and portal pages into that tenant's own space.

This gives you three properties that matter:

• Edit in confidence. Authoring changes land on the template, not on live tenants, so work-in-progress never leaks into production.
• Tenants own their copy. After a fork, a tenant administrator opens the same editors and refines their configuration — same tooling, no special cases.
• Isolation by construction. Every tenant reads only its own configuration. A tenant that hasn't forked an application simply sees nothing for it — never another tenant's data.

Because each tenant edits its own copy with the same editors, there is exactly one way to author anything in Atelier, whether you're a platform operator shaping a template or a tenant administrator tuning a live deployment.

Live preview that matches production

Authoring surfaces preview through the same renderer that powers the deployed experience. The dashboard editor, for example, resolves your draft layout through the identical data pipeline and chart components your tenants will see — so the preview is the result, not an approximation. One renderer drives both the editor and the running application, which means there's no second code path to drift out of sync.

Authorization is built in

Authoring respects tenant boundaries automatically. Operators act only within the scope their administrator grants them:

• A platform operator can author across the applications and tenants they're entitled to manage.
• A tenant administrator authors within their own tenant.

These boundaries are fail-closed by construction: when authorization can't be confirmed, the edit is refused rather than allowed. Tenant isolation is enforced on every read and every write, so authoring is safe to hand to operators without bespoke guardrails.

Every change is audited

Each authoring change records an audit entry against the tenant it targets — what changed, who changed it, and on whose behalf. Auditing runs alongside the edit and never blocks it, giving you a complete, queryable history of how an application's configuration evolved.

Extending the suite

The authoring catalog is built to grow:

• New editor for an existing data type — add a focused editing surface; no backend work is needed when the type is already served.
• New hub tab — drop in a tab to expose an additional facet of an application's configuration.
• New tenant author — granting a tenant administrator their scope is all it takes to unlock authoring for that tenant; nothing is hardcoded per tenant.
• New live editor — surfaces like branding and campaigns edit a tenant's own live configuration directly.
• Whole-application round-trip — export an entire application as a portable definition and re-import it elsewhere, reusing the same materialization the fork uses.

What stays guaranteed

• An application's identifying code is fixed after creation — references stay stable for the application's lifetime.
• The set of emittable events is curated by the platform; operators subscribe to events rather than inventing them, so notifications always reference something real.
• Publishing a citizen page keeps the page and its access rules in lockstep, compiled together on save and fail-closed.
• A tenant only ever reads its own configuration — isolation holds with no fallback to anyone else's rows.