---
title: "Production launch checklist"
description: "A practical launch gate for identity, configuration, persistence, knowledge, feedback, observability, and rollback before exposing a mordn agent to real users."
---

Use this checklist after the [Quickstart](/docs/quickstart) works locally and
before routing real users to your agent. The goal is not just a successful chat
turn — it is a release you can identify, observe, improve, and roll back.

> **Identity is the hard launch gate**
>
> `getChatUserId` must resolve identity from a verified server session. Never copy
> a user id from `X-User-Id`, the request body, URL parameters, or other client
> input. A production launch is blocked until two different signed-in users cannot
> read, continue, delete, or attach files to each other's conversations.

## 1. Separate preview from production

- Create a **test** key for local and preview deployments.
- Create a distinct **live** key for production.
- Store both in server-only environment variables; never expose either key to a
  Client Component or `NEXT_PUBLIC_*` variable.
- Confirm the dashboard's **Preview** usage reflects Playground testing and the
  **Production** view contains only end-user traffic.

> **Note**
>
> The dashboard issues a hidden preview key for its own Playground. User-managed
> keys remain one-time secrets: copy them when created and rotate rather than
> trying to recover them later.

## 2. Publish a known configuration

In the agent **Playground**:

1. Choose the production model.
2. Review the system prompt, greeting, output limit, appearance, and enabled
   features in the generated configuration view.
3. Test representative happy paths, refusals, ambiguous questions, and tool
   failures.
4. Save a version, then publish that exact version.
5. Keep the previous known-good version available for rollback.

Do not treat an unsaved browser draft as deployed configuration. Save creates an
immutable version; publish deliberately promotes one version to production.

## 3. Verify persistence and ownership

Run these checks with two separate test accounts:

- A conversation survives refresh and can be resumed by its owner.
- A user cannot load a conversation id owned by the other account.
- Delete removes only the authenticated user's targeted conversation.
- Attachments use private storage and short-lived signed URLs.
- Revoking a key prevents new requests made with that key.

See [Authentication](/docs/guides/authentication),
[Persistence & history](/docs/guides/persistence), and
[Attachments](/docs/guides/attachments) for the underlying contracts.

## 4. Wire the improvement signals

A production assistant needs both answer-quality and coverage signals:

- Enable `feedback` on `<ChatWidget>`.
- Wire `onFeedback: createHostedFeedback({ apiKey })` in the server handler.
- If the agent should answer from your content, configure hosted retrieval and
  ingest the authoritative sources under **Knowledge**.
- Ask questions that should and should not be answerable. Confirm citations render
  for grounded answers and weak retrieval appears under **Usage & cost →
  Unanswered questions**.
- Review recurring misses before adding an answer. End-user questions are input,
  not trusted documentation.

See [Feedback](/docs/guides/feedback) and
[Knowledge / RAG](/docs/guides/knowledge).

## 5. Exercise failure paths

Before launch, intentionally test:

- Invalid or revoked API key.
- Model or upstream provider failure.
- Knowledge service unavailable.
- File upload rejected by type or size.
- Network interruption during streaming.
- A tool request that fails or requires human approval.

The UI should explain the failure without losing the conversation, leaking a
secret, or exposing another user's data. For streaming-specific checks, use
[Streaming reliability](/docs/guides/streaming-reliability).

## 6. Confirm the operating loop

After a small internal release, verify the dashboard supports the full loop:

1. **Observe** message volume, spend, feedback, and unanswered questions.
2. **Investigate** the relevant conversation metadata without exposing message
   content in the control plane.
3. **Improve** the system prompt, model, tools, or knowledge.
4. **Test** the change in Preview.
5. **Publish** a new version deliberately.
6. **Rollback** if production signals regress.

## Launch record

Record these values in the release or deployment note:

| Field | Record |
| --- | --- |
| Agent id | The dashboard agent identifier |
| Published version | Version number and label |
| Environment | Preview or production |
| Key label | Identifier only — never the secret |
| Model | Exact provider/model id |
| Knowledge sources | Count and last successful ingestion time |
| Validation owner | Person who ran the two-user isolation test |
| Rollback version | Previous known-good version |

A launch is ready when identity isolation passes, a known version is published,
feedback and usage arrive in the correct environment, and the team knows which
version to restore if quality or reliability regresses.