---
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.phasoric.com/context-scopes
markdown_url: https://developers.phasoric.com/context-scopes.md
mirror_url: https://phasoric.com/developers/context-scopes
---
# Context Scopes

A Phasoric 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 Phasoric 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 Phasoric layer. They do not duplicate Markdown bodies into the scope record.

## Personal hosted sources

An account can use hosted intelligence through an owner-only personal scope without creating an organization. In Hosted Watches, a pack's Workspace references, or Settings → Developer, open **Choose hosted sources**. Select a synced Phasoric Hosted vault and either specific notes or the entire vault. Whole-vault authorization includes future notes. Saved selections can be edited, disabled, and explicitly restored.

This setup registers the existing storage mapping and saves authorization references. Scheduling a Watch, attaching a pack, and purchasing an entitlement remain separate actions. Local-only and device-encrypted sources must run locally. Existing plan, MCP/API, and pack entitlements continue to apply.

Authenticated account sessions, or entitled account bearer credentials, can use these Product Runtime endpoints:

| Method and path under `/api/product/v1` | Result |
| --- | --- |
| `GET /personal-sources/workspaces` | Workspaces currently owned by the account |
| `GET /personal-sources?workspaceId=…` | Synced hosted mappings and availability |
| `GET /personal-sources/:mappingId/notes?workspaceId=…&cursor=…` | Note paths and a continuation cursor; no bodies |
| `GET /personal-sources/:mappingId/scopes?workspaceId=…&cursor=…` | Saved personal selections, including disabled selections |
| `POST /personal-sources` | Register an exact mapping and create or reuse its personal scope |

Example request body:

```json
{
  "workspaceId": "aaf77c0a-0bd1-4677-a516-cf3c41fac963",
  "mappingId": "414694c7-4764-4ec4-8ebd-d8e19ff89e85",
  "name": "Project evidence",
  "selection": { "kind": "notes", "paths": ["project/plan.md"] }
}
```

Use `{ "kind": "vault" }` for explicit whole-vault authorization. The response's `data.scope.id` and `data.mapping.mappingId` are the Context Scope and mapping references for entitled MCP/API calls. The hosted SDK exposes `listPersonalHostedSources` and `enablePersonalHostedSources`. Scope resource DTOs retain `mappingId` alongside the workspace, vault, path, and permissions. Generic scope listing supports `cursor` and `limit`, returning `nextCursor` outside `data`.

Manage a saved selection with `PATCH /scopes/:scopeId` and its current `expectedRevision`. Disable using `status: "archived"`; restore using `status: "active"`. Edits must use exact hosted source references. Ownership, organization assignment, and personal audience cannot be widened through this endpoint. Source availability is checked again when used, and disabled bindings are never automatically revived.

Organization policies still govern any linked workspace. Linking an existing personal workspace preserves scope IDs and its owner-only audience, associates the scopes with the organization, and increments their revisions. The owner must have active organization membership. Unlinking or suspending an organization does not silently convert its scopes back to personal authority. Shared audiences and installation service principals continue to require organization governance.

## Audience floor

Shared context is based on the resources authorized for the whole active audience. Phasoric 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 Phasoric'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.