Module: plan

Plan Module

Defines the Plan object as a Directed Acyclic Graph (DAG) of executable steps with dependency management.

Status: Frozen

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 Plan module defines the deterministic reasoning structure for task execution in MPLP.

It represents the intent layer — what an agent (or system) intends to do, decomposed into a Directed Acyclic Graph (DAG) of executable steps.

Within the MPLP lifecycle, Plan is responsible for:

  • Declaring a clear objective with measurable outcomes,
  • Decomposing complex tasks into ordered, dependency-aware steps,
  • Enabling human-in-the-loop approval before execution begins,
  • Providing auditability of reasoning before action.

Plan does not execute actions; it provides the normative execution blueprint that orchestration layers follow.

Architecture

Interaction Model

Dependencies and event emissions.

The Plan module operates as the execution intent layer between Context and Trace.

Dependencies

  • Context: Every Plan MUST reference a valid context_id.
  • Role: Steps MAY specify an agent_role for assignment.

Emissions & Observability

  • Trace: Plan execution generates Trace segments for each step.
  • Confirm: Plan approval MAY require HITL confirmation before status transitions.

Usage in Golden Flows

The Plan module is central to:

  • Golden Flow 01 — Single-Agent Task Execution
  • Golden Flow 02 — Multi-Step Planning
  • Golden Flow 04 — Approval-Gated Execution

Compliance

Normative Constraints

MUST / SHOULD / MUST NOT requirements.

The following constraints are normative and MUST be enforced by any MPLP-conformant implementation:

  1. A Plan MUST reference a valid context_id.
  2. A Plan MUST declare an objective that describes the intended outcome.
  3. Steps MUST be structured as a DAG; circular dependencies are INVALID.
  4. Step status transitions MUST follow the defined lifecycle (pending → in_progress → completed/failed).
  5. A Plan MUST NOT transition to in_progress without explicit approval when governance requires it.
  6. All step completions MUST be traceable and auditable.

Failure to meet these constraints results in a non-conformant execution.

Specification

Canonical Schema

The normative JSON structure for this module.

{
  "required": [
    "meta",
    "plan_id",
    "context_id",
    "title",
    "objective",
    "status",
    "steps"
  ],
  "optional": [
    "trace",
    "events"
  ],
  "stepObject": {
    "required": [
      "step_id",
      "description",
      "status"
    ],
    "optional": [
      "dependencies",
      "agent_role",
      "order_index"
    ]
  }
}

Behavior

Lifecycle

Valid states and transitions.

Status Enum

draftproposedapprovedin_progresscompletedfailedcancelled

Quick Links

View Full Spec← Back to Modules

Evaluation Path

Governance → Compliance → Golden Flows → Adoption Signals

Enterprise Guide Governance Compliance Golden Flows Adoption