---
title: Context Scopes
description: Bound shared agents, memory, resources, policies, and background work to the audience that is actually authorized to use them.
slug: context-scopes
path: /context-scopes
section: Platform
availability: approved-partner-preview
nav_order: 10
canonical_url: https://developers.basaltnotes.com/context-scopes
markdown_url: https://developers.basaltnotes.com/context-scopes.md
mirror_url: https://basaltnotes.com/developers/context-scopes
---
# Context Scopes

A Basalt Context Scope is the shared intelligence and authorization boundary used by Product Runtime, Agent Studio, and scoped background automation.

A Context Scope is **not** another vault, note store, memory store, or content mirror.

```text
canonical Basalt resources
        ↓
current workspace / organization / logical-vault authority
        ↓
Context Scope audience floor + verified explicit grants
        ↓
inherited evidence, memory and action policy
        ↓
Context Router / agent / automation / Product Runtime
```

## Scope kinds

The V1 contract supports:

- `personal`
- `workspace`
- `project`
- `team`
- `session`

A scope has a stable ID, owner, audience, resource references, optional parent, intelligence-resource references, and policy.

Resource references point to canonical resources owned by another Basalt layer. They do not duplicate Markdown bodies into the scope record.

## Audience floor

Shared context is based on the resources authorized for the whole active audience. Basalt does not union participant-private knowledge into a shared agent session.

```text
Arthur: private A + Shared
Bob:    private B + Shared

shared scope context = Shared
```

A separately verified scope grant may add a resource specifically authorized for that shared scope.

Hosted resolution uses server-authoritative current audience and membership/grant state. A client does not get to submit a convenient list of audience IDs and thereby manufacture access.

## Policy inheritance

Effective policy resolves from broader authority toward narrower execution context:

```text
Organization / workspace policy
        ↓ may tighten
Context Scope
        ↓ may tighten
Agent
        ↓ may tighten
Session
```

A child may disable capabilities or require stronger review; it cannot silently loosen an ancestor policy.

## Memory

Readable context and writable shared memory are separate.

```text
observation/model output
→ shared-memory candidate
→ source + run/session + audience + target scope
→ authorized human review
→ confirmed accepted memory
→ permanent-memory durability
```

Shared model output is not trusted memory merely because it appeared in a team session.

Hosted shared-memory materialization should remain unavailable until it uses Basalt's existing permanent-memory protection path rather than creating a parallel hosted truth store.

## Agents, skills, and recipes

Scope availability references one canonical agent/skill/recipe identity and version. Revoking scope availability does not delete the original resource, and historical receipts retain the version used.

## Background work

Scoped triggers/background work record the effective scope/policy at execution time. Revocation prevents future execution. Consequential work remains governed by Forge.

## Product Runtime

The V1 SDK exposes scope operations such as listing available scopes, resolving context/effective policy, listing shared intelligence, and shared-memory candidate creation where supported.

Product Experience IDs and hostnames never participate in scope authorization.