Context Module
Defines the root anchor for Plans, Traces, and Roles, encapsulating domain, environment, and constraints.
Usage Boundary: This page provides an evaluative summary and a canonical schema excerpt for convenience. The authoritative, versioned specification remains on docs.mplp.io. MPGC does not issue certifications, badges, or endorsements; adoption and conformance are self-assessed by the adopting organization.
Definition
Protocol Role
The normative responsibility of this module.
The Context module serves as the semantic root anchor for all MPLP executions.
It defines the execution boundary within which Plans, Traces, Roles, and Collaborations operate. Every MPLP-conformant execution MUST begin with a valid Context.
Within the MPLP lifecycle, Context is responsible for:
- Establishing the domain scope (e.g., backend, frontend, data-pipeline),
- Declaring the execution environment (e.g., production, staging, development),
- Defining constraints that govern downstream behavior,
- Providing traceability anchor for all child artifacts.
Context does not define execution logic; it provides the normative boundary conditions that all other modules inherit.
Architecture
Interaction Model
Dependencies and event emissions.
The Context module operates as the root node of the MPLP artifact graph.
Dependents (Modules that reference Context)
- Plan: Every Plan MUST reference a valid
context_id. - Trace: Every Trace MUST be anchored to a Context.
- Collab: Collaborative sessions inherit their scope from Context.
- Role: Role assignments are scoped within a Context.
- Dialog: Conversations operate within a Context boundary.
Emissions & Observability
- Context creation and status changes MUST emit traceable events.
- Context constraints are inherited by all dependent artifacts.
Usage in Golden Flows
The Context module is the entry point for all normative execution patterns:
- Golden Flow 01 — Single-Agent Task Execution
- Golden Flow 02 — Multi-Step Planning
- Golden Flow 03 — Multi-Agent Task Coordination
Compliance
Normative Constraints
MUST / SHOULD / MUST NOT requirements.
The following constraints are normative and MUST be enforced by any MPLP-conformant implementation:
- Every MPLP execution MUST begin with a valid Context.
- A Context MUST declare a
domainandenvironmentin itsrootobject. - A Context MUST NOT be modified after transitioning to
archivedstatus. - Child artifacts (Plans, Traces, etc.) MUST reference an existing
context_id. - Context constraints MUST be inherited by all dependent artifacts unless explicitly overridden.
- Context status transitions MUST be traceable and auditable.
Failure to meet these constraints results in a non-conformant execution.
Stability
Context Invariants
Stability guarantees that define the module.
The following invariants define the stability guarantees of a Context:
- A Context defines a single semantic domain.
- A Context MAY evolve, but its domain identity MUST remain stable.
- Archived Contexts MUST NOT be mutated.
- All dependent artifacts inherit Context constraints implicitly.
Error Handling
Failure Semantics
What happens when constraints are violated.
Any execution referencing an invalid, missing, or incompatible Context is considered non-conformant and MUST be rejected.
Specification
Canonical Schema
The normative JSON structure for this module.
{
"required": [
"meta",
"context_id",
"root",
"title",
"status"
],
"optional": [
"summary",
"tags",
"language",
"owner_role",
"constraints",
"created_at",
"updated_at",
"trace",
"events",
"governance"
],
"rootObject": {
"required": [
"domain",
"environment"
],
"example": {
"domain": "backend",
"environment": "production",
"entry_point": "services/auth/"
}
}
}Behavior
Lifecycle
Valid states and transitions.
Status Enum
Semantics
Contexts are stable once archived.
Quick Links
Evaluation Path
Governance → Compliance → Golden Flows → Adoption Signals