Synap Dashboard home page
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 likeinst_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.
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 and the Use-Case Markdown authoring guide.Scope ladder
Your scope ladder is the set of named levels your customers and users nest into, and it is what decides who can read whose memories. The default is the familiarClient → Customer → User chain, and most accounts never need anything else.
The Scope Ladder page, under Instances in the sidebar, shows the ladder your account is actually using: each level, its permanent key, and how many entries sit at it. From there you can rename a level, review the ladder Synap suggests from your use-case file along with the reason for each rung, accept it, add a level with a preview of how many records the change would move, and check what a specific request would resolve to before your application sends it.
The page keeps two states apart on purpose: whether anyone has accepted the ladder, and whether nested scoping is switched on for your instances. A ladder can exist while nothing uses it.
See Scope Ladder for the walkthrough, and Scope ladder for the concept behind it.
Sensitive data
The Sensitive data page shows what Synap has detected in your traffic, by field type, and lets you decide what happens to each kind: keep it, store a placeholder instead of it, or do not store it at all. Nothing you set there changes what your application reads back unless you pick one of the two settings that say so, and nothing takes effect until a person approves it. The same page carries a test box for checking a change against sample text before committing to it, the audit trail of everything that has happened to your sensitive data, and the place to describe field types Synap does not ship. See Sensitive data and data controls for the step-by-step, and Sensitive Data Protection for the concepts behind it.Next steps
Customized Memory Architectures
How Synap derives an instance’s memory configuration from your use-case file.
Use-Case Markdown
Author the file Synap uses to configure and regenerate memory behaviour.
Sensitive Data & Data Controls
Decide what happens to sensitive values in your content, and test it before approving.
Scope Ladder
See how your customers and users nest, rename a level, or add one.
First Integration Guide
Connect your application to a dashboard-provisioned instance using the SDK.
Production Checklist
Review everything you need before going live.