> ## 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. # Scope Ladder > The Scope Ladder page in the Dashboard shows how your customers and users nest, which is what decides who can read whose memories. See your levels, rename them, review what Synap suggests and why, accept a ladder, add a level with a preview of what moves, and check what a specific request would resolve to. This page is about the Dashboard screen. For what a level is, which direction a read travels, and what you can reach today, read [Scope ladder](/concepts/scope-ladder) first. Open the Dashboard and go to **Instances**, then **Scope Ladder**. It sits next to **Visibility** because both answer the same question: Visibility controls what one instance can read from another, and Scope Ladder controls who can read what inside one. ## One ladder for the whole account Your ladder belongs to your account, not to an instance. Every instance you run shares the same levels, and there is no way to give two instances different ones. That is deliberate, and it follows from how people and organisations are identified. A customer id means the same customer everywhere in your account, and a user id means the same person, whichever instance sent the request. Two instances writing about customer `acme` are writing about one customer, not two. If those instances disagreed about what the levels are, the same records would be filed under different level names depending on which instance wrote them, and a read from one instance would not find what the other stored. Your memory would split in half with nothing to tell you it had. Your instances still keep their own memory settings. What they cannot keep is their own ladder. The one part of this that IS per instance is the switch. Nested scoping can be on for one instance and off for another, which is what makes a careful rollout possible: turn it on for a test instance, watch it, then turn it on for the rest. The shape is shared; when each instance starts using it is not. ## Reading your ladder The main panel lists your levels in order, top rung first, indented so the nesting reads as nesting. Each row shows three things: * the **name**, which is what you call that level * the **key** in small type beside it, which is what stored memories resolve through * how many **entries** are filed at that level right now The name is an editable field. The key is shown and never editable, because every memory already filed under it would stop resolving. A row can carry a badge, and it tells you what that level needs rather than that it is unreachable. A level outside the standard three is not named by `customer_id` and `user_id`, so a call has to name it in a scope path instead. * **needs a scope path** means your traffic is already on an SDK that can send one. Name the level in the path and you can read and write at it. * **needs SDK 0.4.6+** means we have not seen a capable SDK in your recent requests. Upgrade, then the level becomes reachable. See [What you can reach today](/concepts/scope-ladder#what-you-can-reach-today). ### Two banners worth reading Above the list, the page states two things that are easy to assume and easy to get wrong. **Whether the ladder has been accepted.** An unaccepted ladder is a draft. Nobody has agreed to it, so your account is still filing and reading memories the default way and nothing on the page is affecting your data. Once someone accepts, the banner names who accepted it and when. **Whether nested scoping is switched on.** A ladder can exist while nothing uses it, which looks configured and behaves exactly as it did before. The banner says which of the two you are in: off, on for all your instances, or on for some number of them with the rest still reading the previous way. These are separate states. Accepting a ladder does not switch nested scoping on, and this page has no control that switches it on. It reports the state. Ask us to change it. ## Renaming a level Type a new name in any row and a bar appears with **Save names**. Only the rows you actually edited are sent, so an untouched level keeps its name and the audit line does not claim you renamed something you left alone. Renaming is the one action here with no consequences. It changes what a level is called. It does not move a memory, and it does not change who can read what. ## What we suggest, and why Lower down, a panel shows the ladder Synap would suggest for your account, read out of your use-case document. Every rung carries the reason it was proposed and quotes the line in your document it came from, so you can judge the reasoning instead of taking it on trust. Where the suggestion is unsure, it says so. Anything Synap is not confident about is listed under **things we were not sure about** as a question, rather than added to your ladder. A level decides who can read whose memories, so it is never inferred from prose that did not ask for one. If your use-case document did not say how your users are grouped, the panel says that plainly and shows the standard three rungs instead of a shape invented for you. Every account is given a ladder at signup, so most of the time this panel is advisory only and the thing you can act on is a rename: it offers to call your existing levels what it suggests calling them. Accepting a whole ladder only appears for an account that has none. ## Accepting a ladder If your account has no ladder, the same panel becomes actionable. You can retype any name you disagree with first, then use **Use this ladder**. Accepting creates the levels and records who accepted and when. It does not move any memory you have already stored, and it does not switch nested scoping on by itself. Renaming stays free afterwards. Removing does not: a level can never be deleted once it exists, only retired. ## Adding a level **Add a level** opens the only control on the page that moves stored records, so it is the only one that will not act on a single click. You give the level a name, such as Team or Branch or Region, and one line describing what it holds. The permanent key is derived from the name and shown to you, so you are not asked to invent a stable identifier for a thing you are still naming. Pick which existing level the new one sits above. A new level has to land between two existing ones, so on the standard ladder that means above Customer or above User. Adding one re-files everything currently beneath that point. The list also offers a position at the very bottom, under your last level. Do not use it. Nothing is allowed to sit below the level that identifies a person, so that choice is refused when you commit it. Before anything happens, the page tells you how many entries and how many memories inserting the level there would re-file, and what your levels would read as afterwards. Nothing has changed at this point. The commit carries back the same number you were shown. If your structure changed while you were reading the preview, the change is refused rather than applied against a count nobody saw. Existing memories do not immediately carry the new level as one of their ancestors, so a query asking for everything beneath it is incomplete until Synap finishes stamping them. Ordinary retrieval is not affected. Ask us to run the backfill after you add a level. ## Checking a request **Check a request** lets you stand somewhere on the ladder and see what you can see. Enter the customer id and user id your application would send, and the page shows the chain of levels that request reads from, in order. It previews only. Nothing is created and nothing is changed by typing here, so checking an id that does not exist yet will not quietly register it. If the ids do not resolve, the panel says so and explains why rather than returning an empty chain. If nested scoping is off for that instance, it tells you the chain is the shape you would get once it is switched on. ## Coverage A panel near the bottom compares how many of your groups are on the ladder against how many exist. When they match, it says so in one line. When they do not, it reports the number of memories sitting in groups Synap has no record of creating. Those cannot be placed automatically, and re-running a backfill will not change it. The number is stated as a count of memories rather than a percentage, because a small percentage of a large account is still a lot of memories. ## What this page will not do Being clear about this is more useful than making the page sound finished. | | On this page | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | See your levels, their keys and their counts | Yes | | Rename a level | Yes | | Review the suggested ladder and its reasoning | Yes | | Accept a suggested ladder | Only if your account has none | | Add a level, with a preview of what moves | Yes, if your integration can address one | | Check what a request resolves to | Yes | | Delete a level | Never; a level can only be retired | | Switch nested scoping on or off | No, it reports the state only | | See which SDK versions your requests come from | Yes, and whether the oldest can address a new level | | Send a scope path from an SDK | Reads from Python 0.4.6 or JS 0.4.4, writes on `memories.create` from Python 0.4.8 or JS 0.4.7, see [What you can reach today](/concepts/scope-ladder#what-you-can-reach-today) | | Run the backfill after adding a level | No, ask us | ## Next steps What a level is, which direction a read travels, and where your ladder came from. What `customer_id` and `user_id` do on every request.