Appearance
Diagnostics
Atelier's core promise is simple: declare an application, and it comes up fully configured on any fresh environment — no hand-wiring, no manual reconciliation. Diagnostics is the capability that proves that promise on demand. It turns every guarantee the rest of the platform makes into something the platform actively checks, so a misconfiguration fails fast and loud instead of slipping through.
You get three layers of assurance, working together:
- Authoring-time guards catch declaration mistakes before anything is provisioned.
- Provisioning validation stands up a clean environment and confirms it self-provisioned correctly.
- In-product health checks continuously verify a live application against its own declarations.
All of it runs from the same declarations every other subsystem reads — so the moment you declare a vertical, it is automatically in scope for every check.
Authoring-time guards
Before an application is ever provisioned, Atelier validates your declarations against a catalog of structural rules. These guards run during the build and surface problems while they are cheap to fix:
- Staleness detection — confirms the compiled application definition matches its source declarations.
- Route collision detection — flags any two surfaces that would claim the same portal route across the fleet.
- Type collision detection — flags duplicate entity-type names that would clash.
- Dependency ordering — verifies declared dependencies resolve in a valid order.
Guards are defined once, centrally, so every application benefits automatically. Adding a new authoring rule extends the same validation pass for the whole fleet.
Provisioning validation
Atelier can stand up a completely isolated environment — its own database, ontology, identity, and authorization stores — and assert that it self-provisioned with zero hand-seeding. This "from-clean" discipline is how the platform proves repeatability: a brand-new application bootstraps itself end to end, and the validation suite confirms the result.
Validation asserts concrete, tenant-isolated guarantees, including:
- Each application carries its own authorization rules, scoped to its own namespace.
- Authorization namespaces are isolated — one application's rules never leak into another's, and a namespace that should hold nothing denies everything by construction (deny-all is the floor).
- Tenant-level access — citizen and member read/write policies provision correctly per application, with no manual reconcile or backfill.
Because the environment is fully isolated, you can validate a change in confidence before it ships, knowing the result reflects a true from-clean provision rather than residue from a previous run.
In-product health checks
Every running application exposes a Diagnostics view that runs the platform's own checks against the live configuration, per declared vertical. The exact checks an operator sees in the UI are the same ones the platform runs headless during validation — there is no second, divergent code path.
These checks confirm the application is wired correctly across planes, covering things like:
- Identity and access clients are present and connected.
- Public surfaces and their placements resolve.
- Public read grants match the declared public row gate, including operator and value shape.
- Runtime public routes actually return for anonymous/citizen access: entity feeds, map feeds, calendar feeds, layers, forms, portal pages, and page templates.
- Entity types are fully declared with no orphans.
- Actions declare valid create and update shapes.
- Workflow-mode submission contracts only reference registered functions from callable roles; data roles such as
bindings,attachments,reference, andaudit_policyare validated as contract data, not as functions. - Notification events have at least one subscriber.
- Analytics surfaces resolve against real data.
Diagnostics are exit-coded, not advisory: green means every check passed, a non-zero result means a specific check failed or the application is not yet provisioned, and an unreachable environment is reported as exactly that. A regression surfaces as a hard failure with a named cause — never a silent skip.
Headless fleet diagnostics stream one result per application while they run. This is intentional: the full catalog can be large, and a slow vertical must be visible as "the run is currently on this app", not as a silent process with no diagnosis trail. The final summary remains exit-coded and suitable for CI.
Self-healing reconcilers
Alongside read-only checks, Atelier ships idempotent reconcilers that converge an application's state to its declared intent — reconciling navigation, role tiers, access policies, service principals, and portal configuration. Reconcilers follow a strict contract:
- Dry-run by default — they report what would change before changing anything.
- Convergent — re-running on an already-healthy application is a no-op.
- Tenant-scoped — a reconciler never touches another tenant's data.
Built to grow
Diagnostics is a platform capability, not per-application boilerplate. Because every check reads the same declarations you already author, extending it is a single, central change:
- Add a new health check, and it appears in both the in-product Diagnostics view and headless validation at once.
- Add a new authoring guard, and it protects every application in the fleet.
- Add a new provisioning assertion, and it runs against every from-clean stand-up.
- Add a new reconciler, and it inherits the dry-run, convergent, tenant-scoped contract by construction.
The result: as your platform grows, its ability to prove itself grows with it. Every new capability arrives with the checks that keep it honest.