> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maximem.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Dashboard
> The Synap Dashboard is the web management interface for your deployment. Create and manage instances, generate API keys, and inspect the memory architecture Synap generates for each agent.
The Dashboard at [synap.maximem.ai](https://synap.maximem.ai) is the **control plane** for Synap: it's where you create instances, configure how they remember, and provision the API keys your application uses. The **data plane** (ingesting memories and retrieving context) happens through the [Synap SDK](/sdk/initialization), not here.
Most of the Dashboard is self-explanatory once you're in it. This page orients you to the main areas; follow the in-app prompts for the rest.
Access is governed by three roles. **Owners** and **Admins** can create and edit instances, upload use-case files, and generate API keys. **Members** have read-only access. Owners additionally manage the team.
## Managing instances
An **instance** is the fundamental deployment unit: an isolated memory agent with its own storage namespaces, memory configuration, scope hierarchy, and API keys. Each one is identified by an ID like `inst_a1b2c3d4e5f67890`.
From the **Instances** page, Owners and Admins can **Create Instance**. Creation asks for a name, a user relationship (`b2c`, `b2b`, `internal`, or `agent_to_agent`), an optional agent type, and (recommended) a **Use-Case Markdown** file describing what the agent does. That file is what Synap uses to generate the instance's memory architecture; download the in-form template to author it. For B2C agents, the customer and user collapse to the same entity.
A new instance starts in **initializing** while Synap allocates storage and applies the initial configuration, then moves to **active** once the first SDK connection lands. Other lifecycle states (`inactive`, `suspended`, `deleting`) are shown on the instance, with the available actions for each.
Everything for a single instance lives on its **detail page**: status and metrics, the memory configuration, analytics, and the **Instance Settings** where you rename it, edit metadata, re-upload the use-case file, and manage API keys.
API keys (prefixed `synap_`) are shown only once. Copy the key when you generate it and store it as your `SYNAP_API_KEY`. To rotate, generate a new key first, switch your environment over, then revoke the old one. Multiple keys can be active at once, so there's no downtime.
## Memory configuration
Every instance has a **Memory Architecture Configuration (MACA)** that Synap derives from its Use-Case Markdown. It shapes which memory categories are extracted, how retrieval ranks and combines results across the fast vector + graph layers, how memories are scoped (user, customer, client, or world), and how long they're retained.
The Dashboard surfaces MACA for **inspection only**. Open the **Memory Configuration** tab on the instance detail page to confirm what Synap configured and to see the history of past regenerations. It is not an authoring surface.
To change behaviour, edit your Use-Case Markdown and re-upload it from **Instance Settings → Use-Case**. Synap regenerates the MACA from the new file; the previous versions are preserved (rollback is a Synap-side operation today, available via support). Regeneration affects only new requests. In-flight conversations finish under the settings they started with.
For how MACA is derived and what each section governs, see [Customized Memory Architectures](/concepts/memory-architecture) and the [Use-Case Markdown](/concepts/memory-architecture#the-use-case-file) authoring guide.
## Next steps
How Synap derives an instance's memory configuration from your use-case file.
Author the file Synap uses to configure and regenerate memory behaviour.
Connect your application to a dashboard-provisioned instance using the SDK.
Review everything you need before going live.