> ## Documentation Index > Fetch the complete documentation index at: https://docs.basemode.ai/llms.txt > Use this file to discover all available pages before exploring further. # Tiers and scoping > The global and workspace tiers, how they merge into one view at query time, how base decides which workspace you are in, and why one project's context does not reach another. base keeps two tiers. The global tier at `~/.base-gbl/` loads everywhere. A workspace tier at `{workspace}/.base/` belongs to one registered project and loads only there. At query time both load into one store and you search across them together. The split maps onto a real distinction. Global is for what is true of you wherever you work: how you like code written, how you want to be talked to. Workspace is for what is true of one project: its conventions, its decisions, its people. ## How a workspace is found base walks up from the directory you are in and takes the first ancestor containing a `.base/` directory. That is the workspace, and it is the only one that loads. So the answer to "will base show me things from a different project" is no, and the reason is path resolution rather than filtering. Project B's graph is never opened while you are standing in project A. Nothing is loaded and then hidden. `base scaffold` is what creates the `.base/` directory and registers the workspace globally. ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base scaffold base scaffold ~/projects/billing-service ``` ## Writing outside a workspace Outside any registered workspace, base refuses to write rather than guessing a tier: ``` no .base/ directory found — refusing to write outside a workspace. Use --global (-g) for the global tier, or run `base scaffold` to create a workspace. ``` This is deliberate and it is a change worth knowing about if you used an earlier version. base used to fall back to the global tier silently, which meant a handoff filed from the wrong directory resurfaced at the start of every unrelated project, forever, with no obvious cause. Global is now something you opt into by passing `-g`, and that flag routes the write to `~/.base-gbl` explicitly rather than by accident. Verified from source at `4866996`, the commit the shipped 0.13.2 binary was built from. ## The `-g` flag, and where it goes Six commands carry `-g` / `--global`: `rule`, `decision`, `handoff`, `fork`, `learn` and `changes`. On the four that have subcommands it belongs on the command itself, **before** the verb: ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base rule -g add --domain writing --text "Prefer short sentences" base handoff -g list base learn -g --text "Prefer short sentences" --domain writing ``` `base graph apply-ops` takes `--global` in long form only. Nothing else has one, so for every other command the tier is decided by where you are standing. Check `base help ` rather than assuming. `--global` resolves to one fixed location, `~/.base-gbl/.base`, and is never searched for. That is worth stating because it briefly was not: on a machine that had only ever run `base install`, the directory did not exist yet, and the resolver walked up past it and took the *workspace* tier instead, so every `-g` command reported success against the wrong graph. Fixed at `4866996`, the commit the shipped 0.13.2 binary was built from, with regression tests on both tiers. The workspace tier keeps the walk, and keeps refusing when the walk finds nothing. There is no known-correct location to fall back to, so guessing one would be worse than the error. ## How the two tiers merge Global loads first, then the workspace graph overlays it by name into one in-memory store. A single query spans both, and rules from both tiers can arrive in the same turn. On a conflict, the workspace wins. The configuration files follow the same pattern. `base.toml`, `domains.toml` and `commands.toml` each layer workspace over global by name, and a workspace `base.toml` inherits everything from the global one unless it overrides a key explicitly. Reads reflect the merge. `base domain list`, `base handoff list` and `base fork list` all show both tiers together, with the tier each entry lives in. Writes mostly do not: they go to the tier you are standing in, or to global if you passed `-g`. ## One project's context reaching another There is one path by which it happens deliberately: `base project peer` adds a link so a project also surfaces in another workspace. ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base project peer billing-service --workspace platform ``` That adds a link rather than copying anything. The project still lives in one place, and an edit from either workspace edits the same project. `--remove` takes the link back off. To move a project outright, `base project move` re-homes it into another workspace's graph and takes its tasks, domain, decisions, rules and notes with it. It prints the plan and changes nothing until you pass `--yes`. ## Next Every file each tier holds, and which of it is machine-local. Every project, milestone, task, goal, reminder and entity command.