> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.cessy.ai/core-concepts/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cessy.ai/_mcp/server.

# Platform Model

> Understand how Cessy turns event-sourced business models into builder workflows, runtime contracts, agents, and custom pages.

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 design-time surfaces. Runtime REST, GraphQL, MCP, webhooks, subscriptions, and custom pages exist to keep integrations aligned with the published DomainConfig.

> Understand how Cessy turns event-sourced business models into builder workflows, runtime contracts, agents, and custom pages.

## Docs

- [DomainConfig](https://docs.cessy.ai/core-concepts/domain-config.md): Learn how DomainConfig drives commands, events, projections, policies, permissions, agents, triggers, adapters, and pages.
- [Runtime Model](https://docs.cessy.ai/core-concepts/runtime-model.md): See how published DomainConfigs become REST, GraphQL, MCP, webhooks, subscriptions, projections, and custom pages.
- [Agents And Channels](https://docs.cessy.ai/core-concepts/agents-and-channels.md): Understand how builder agents, runtime agents, channels, DMs, entity threads, and attention levels fit together.
- [Environments](https://docs.cessy.ai/core-concepts/environments.md): Use runtime environments to separate production traffic, previews, test runs, and agent validation.