Capabilities
Context Platform
Query grounded project context through an authorization-aware registry of eight read providers: Knowledge, Adoption, Delivery Health, Decisions, vSOW snapshots, Relationships, Context Opportunities, and derived Context Concepts. A request flows Sources → domain providers → an authorization-safe router → transports. The provider contract is read-only; each provider preserves its own permissions and authority instead of becoming a second source of truth. Opportunity results are the one exception to mutable_here=false because DigitalStack owns that advisory record itself. Concepts remain mutable_here=false and are derived on every read from authorized opportunity records, never persisted as a second object store. Recording an opportunity uses a separate canonical command service and is never approval — it never mutates, promotes, or supersedes governed truth. Evidence is not automatically a fact, an inference is not an approved decision, an opportunity is not an approved outcome, and partial results are expected and explicit. Distinct from the legacy Context Engine (deterministic briefing + corpus search) — see the Context Engine capability for those surfaces. Internal DigitalStack surfaces are beginning to consume the platform directly (the Execution Copilot adds supplemental grounding from it — controlled rollout, default off); not every product surface uses it yet.
Interfaces
POST /api/v1/context/unified is live over eight registered read providers and supports search, get_projection, get_object, and list_objects. Opportunity is included in the bounded default search; Concept must be requested explicitly and supports project-scoped search/object/list reads. POST /api/v1/context/opportunities records one advisory Context Opportunity through the canonical command service.
- • The write endpoint requires the distinct context-opportunity:write scope and is gated by the server-side CONTEXT_OPPORTUNITY_WRITES_ENABLED flag (default off) until the U7R.2 migration is applied and verified live — reads are never gated by this flag.
The external dsmcp server registers four generic read tools behind CONTEXT_PLATFORM_MCP_NATIVE_ENABLED. When enabled, they forward to POST /api/v1/context/unified and expose the same structured envelope; Opportunity and Concept are available through the generic domain arguments. No Context Platform MCP write tool is registered.
- • Controlled rollout: CONTEXT_PLATFORM_MCP_NATIVE_ENABLED defaults off, so the four tools are absent from MCP discovery until the gateway operator enables it.
- • record_context_opportunity, search_context_opportunities, and list_recovered_context are documented design contracts only; the external dsmcp server does not register them, so they are planned rather than callable.
- • The legacy Knowledge-only search_context tool (documented under the Context Engine capability) remains unchanged; it is not widened to multi-domain.
The read-only contextPlatform namespace (search, projection, object, objects) requires context-engine:read and is a thin transport over the same production router and serializer as REST. It exposes Opportunity reads but intentionally omits the Concept domain and kind from its enums. Mutation.recordContextOpportunity delegates to the same canonical command as REST, requires context-opportunity:write, and is subject to the same write feature flag.
- • Context Concepts are not callable through GraphQL today; use POST /api/v1/context/unified or an enabled generic MCP read tool with the explicit concept domain.
- • Mutation.recordContextOpportunity is gated by CONTEXT_OPPORTUNITY_WRITES_ENABLED (default off), same as the REST write endpoint.
- • Time Management, Work Items & Board, Work Item Enhance, Today & My Work, Project Health, Projects & Engagements, Milestones & Workstreams, Sprints & Planning, Context Engine, and Estimates, Effort & Scope are available. Risk and portfolio event families remain planned.
Required scopes
context-engine:readAPI key scoperequiredcontext-opportunity:writeAPI key scoperequiredExamples
GraphQL examples
context-engine:readLexical search over knowledge, adoption, and decision evidence for a project subject, with per-domain authorization applied before merge.
query SearchContext($input: ContextPlatformSearchInput!) {
contextPlatform {
search(input: $input) {
outcome
truncated
providers {
providerId
status
itemCount
}
results {
id
kind
domain
providerId
title
content
authority {
authorityType
owningDomain
mutableHere
}
evidence {
sourceTitle
provenanceQuality
}
}
limitations {
code
message
}
}
}
}context-engine:readThe one implemented deterministic projection today — delivery risk/health signals for a project, with freshness and coverage reported per provider.
query DeliveryHealthProjection($input: ContextPlatformProjectionInput!) {
contextPlatform {
projection(input: $input) {
outcome
freshness {
status
byProvider {
providerId
freshness {
status
basis
asOf
}
}
}
results {
id
kind
content
attributes
}
}
}
}context-engine:readRead advisory Context Opportunities for a project. Opportunity is also part of the router’s bounded default search; specify the domain when you want only opportunities.
query SearchOpportunities($input: ContextPlatformSearchInput!) {
contextPlatform {
search(input: $input) {
outcome
results {
id
kind
title
content
authority {
authorityType
mutableHere
}
attributes
}
}
}
}context-engine:readRetrieve one namespaced object from an explicit GraphQL-supported domain. Missing and unauthorized objects remain indistinguishable.
query ContextObject($input: ContextPlatformObjectInput!) {
contextPlatform {
object(input: $input) {
outcome
results {
id
kind
domain
title
content
authority {
authorityType
owningDomain
mutableHere
}
}
limitations {
code
message
}
}
}
}context-engine:readList context objects from one or more explicit GraphQL-supported domains with provider-owned lifecycle and pagination semantics.
query ContextObjects($input: ContextPlatformObjectsInput!) {
contextPlatform {
objects(input: $input) {
outcome
truncated
results {
id
kind
domain
title
content
}
continuation {
cursor
}
limitations {
code
message
}
}
}
}context-opportunity:writePropose that the decision domain may want to record a discovered decision. Advisory only — this never approves anything; a human (or the owning domain’s own workflow) must later review it.
mutation RecordOpportunity($input: RecordContextOpportunityInput!) {
recordContextOpportunity(input: $input) {
ok
opportunityId
lifecycleState
idempotentReplay
authorityType
mutableHere
errors {
code
message
}
}
}Operating contract
These boundaries remain part of the customer-facing contract after capability promotion.
Must remain true
- • The provider/router contract is read-only and has no write method. Knowledge, Adoption, Delivery, Decision, Snapshot, Relationship, and Concept results carry mutable_here = false.
- • The Context Opportunity object carries mutable_here = true ONLY for itself (authority_type always advisory) — never for any destination object it references (current_object_ref / promotion_target / promoted_object_ref are always mutable_here = false).
- • A Context Concept is derived on read from authorized opportunities, carries advisory authority with mutable_here = false, and is never persisted or writable.
- • The transport scope (context-engine:read) grants entry only; each provider independently enforces its own domain permission and visibility (context:read, delivery:read, project visibility, financial/staffing, decision/snapshot/relationship visibility).
- • The write scope (context-opportunity:write) is distinct from context-engine:read; holding one never grants the other.
- • The implemented write transports (REST and GraphQL) are thin delegates to the ONE U7R.2 domain service — there is no second persistence path and no provider/router write method. MCP opportunity writes are not registered.
- • Recording an opportunity is never approval: it never mutates, promotes, or supersedes governed truth in any domain, and only a human (or an authorized domain workflow acting for one) can later approve/reject/promote it.
- • The write feature flag (CONTEXT_OPPORTUNITY_WRITES_ENABLED) gates every write transport identically; reads are never gated by it.
- • One authorized domain never authorizes another; unauthorized provider results are omitted or sanitized to preserve non-oracle behavior.
- • Freshness is provider-specific and may be current, stale, mixed, or unknown; request time is never used as source freshness.
- • Coverage never claims a complete denominator; a successful query does not imply complete domain coverage.
- • Partial failure returns HTTP 200 with the failing provider reported; authorization denials never use a differing HTTP status.
- • Continuation cursors are opaque and reusable only with the same operation, subject, domains, query, and filters.
- • Only delivery.health is an implemented public projection today; reserved projections are not callable.
Explicitly not exposed
- • Any write method on one of the eight read-only Context Platform providers or on the Unified Router — the ONE implemented write is scoped entirely to the Context Opportunity command service
- • Context Concepts through GraphQL, or any persisted/writable Concept store — concepts are REST/MCP-readable derived projections only today
- • A registered MCP tool for recording Context Opportunities; the write tool contract exists but the external dsmcp runtime does not register it
- • Any approve, reject, promote, or supersede operation on a Context Opportunity — recording one is proposal-only; adjudication is a future, human-only governance slice
- • Any write to a governed-domain table (decision, requirement, commitment, definition, delivery, snapshot, relationship, …) — the ONE write creates an opportunity record, nothing else
- • Autonomous detection, conversation monitoring, or confirmation UX that would record an opportunity without an explicit caller request
- • Grounded synthesis or a generic prompt-completion answer (planned, U9)
- • Execution-context projections (RFC-gated, U6) and a governed context-object model beyond Context Opportunity (RFC-gated, U7)
- • Cross-provider relevance ranking or a single global chronology across providers
- • A write method on the ContextProvider contract or the Unified Router — the router stays execute()-only; the opportunity write path never runs through it
System boundaries
Systems commonly integrated with this capability. Each row states the boundary and its native status; it does not transfer canonical authority to the connected system.
DigitalStack owns
- • Authorization-safe composition of provider results — never widening access across domains
- • Per-provider execution status, authority classification, freshness, coverage, limitations, and partial-failure reporting
- • Opaque cross-provider continuation cursors (independent per-provider state; no global relevance ranking)
- • The Context Opportunity object itself — the platform’s ONE writable, platform-native advisory record — through exactly one canonical domain service every transport delegates to
- • A read-only Context Concept lens derived from authorized Context Opportunities at request time; concepts are never persisted as a second source of truth
Source systems own
- • The canonical decision, delivery, adoption, vSOW-snapshot, and relationship truth each read-only provider projects — those providers never own or mutate it
- • The original documents and Context Sources that Knowledge evidence is extracted from
- • Whatever a Context Opportunity ultimately becomes once a human, through the owning domain’s own governance workflow, promotes it — that governed object stays owned by its domain, never by the opportunity
Typical integration patterns
Your existing systems of record