Platform Model | Cessy Builder Docs

Cessy has one central idea: the business model is the source of truth. Builders describe decisions, facts, reads, automations, permissions, and interfaces. Cessy turns that model into the runtime app.

Core objects

Object	Meaning
App	A configurable business application owned by a tenant.
DomainConfig	The complete design-time model for commands, events, projections, policies, permissions, agents, triggers, adapters, and pages.
Workspace	An isolated design area for draft changes.
Changeset	A reviewable package of workspace changes that can be validated and promoted.
Environment	A runtime target such as production, preview, or test.
Runtime	The generated command, projection, event, API, MCP, webhook, subscription, and page behavior for a published config.

Event-sourced shape

Cessy apps are not table-first CRUD apps. They are event-sourced systems:

commands request business decisions
deciders validate the current event history and emit events
events record facts that already happened
projections build read models from events
policies react to events and orchestrate follow-up work

That shape keeps business history inspectable and lets the runtime generate stable contracts from the same model.

Builder UX principle

The Builder UI should make the model understandable to a human: decision flows, command names, event names, projection questions, policy side effects, and permission boundaries should be visible before implementation details.

Design MCP gives AI builders the same context programmatically. A good agent first reads the model and reference material, then proposes scoped changes through a workspace.

Runtime principle

External clients should integrate with published runtime contracts, not with design-time internals. Runtime REST, GraphQL, MCP, webhooks, subscriptions, and custom pages exist to keep integrations aligned with the published DomainConfig.