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:
personalworkspaceprojectteamsession
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.
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.
