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.

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:

Example request body:

{
  "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.

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:

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.

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.