> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.cessy.ai/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cessy.ai/_mcp/server. # Publish And Operate > Promote a validated Cessy model, verify generated contracts, and operate the published runtime safely. Publishing moves builder intent into runtime behavior. Treat it as a controlled release, even when the change is small. ## Operate interface language The primary Operate shell, home, inbox, conversations, and channel navigation are available in English and German. Change the interface language from the account controls; Cessy keeps the same route and remembers the choice across authentication and Operate pages. Localization applies only to Cessy interface copy. App names, channel names, messages, document values, domain-model labels, and other user-authored content remain exactly as entered. ## Before publishing Check the workspace or draft: * validation passes * open errors are understood and intentionally deferred * command and event names still express the business language * projections support the needed read paths * permissions match expected actors * policy side effects are visible and expected * adapters and credentials target the right environment * custom pages still call generated runtime surfaces For AI-assisted work, ask the Design MCP reviewer to summarize the diff and remaining risk before promotion. ## Promotion Use a changeset for scoped design work: 1. create or update the workspace 2. validate the workspace 3. create the changeset 4. review validation output 5. promote to the target environment with explicit approval Record the workspace id, changeset id, target environment, and validation id in the handoff. ## After publishing Run a runtime smoke test: ```bash curl https://your-instance.com/api/rest///openapi ``` Then execute one representative command and read one projection that should show the resulting state. ## Projection rebuilds Rebuild projections when projection definitions change, after event import, or during recovery work. Do not rebuild casually in production without understanding the event volume and downstream expectations. For a failed shadow rebuild, wait for that attempt to settle and inspect its status before starting a serial retry against the same runtime source. The live collection stays authoritative until the replacement is ready. Cessy rechecks readiness after dropping or renaming the temporary collection; a retry does not require waiting for a cache timeout or changing the projection definition. If the same missing-relation error recurs, retain the failure evidence for platform investigation instead of starting repeated rebuilds. In the Design Release v2 Alpha cohort, a new projection can publish without a rebuild only when every event it handles is also introduced by the same exact Candidate. Cessy commits that event/projection pair inside the existing atomic Domain release, and the projection consumes future events normally. Changes to an existing projection, removals, existing-event projections, and ambiguous history remain blocked until rebuild or migration support is available. ## Operational checks After publish, inspect: * Activity for command, event, policy, and webhook traces * Data Explorer for projection state * error logs for validation, policy, adapter, webhook, or auth failures * runtime agents or custom pages touched by the change An attempt-zero `recovery_progress_exhausted` is a bounded progress failure, not proof that a policy handler ran or that external effects are absent. Use `list_policy_reconciliation_work` to inspect the exact work/version/runtime assessment. A null `safeDecision` forbids replay; do not repeatedly reconcile or reissue the source command. Queue deduplication alone is not execution proof. If a smoke test fails, fix the model or permissions before asking external consumers to adapt.