Skip to main content
INFORMATIVEDRAFTDocumentation Governance

Conformance Model

1. Purpose

This document mirrors the definition of how MPLP maps a running system to a conformance-evaluable object.

The core question this answers:

"What exactly is being judged when we say 'this system is MPLP conformant'?"

2. Conformance Object

MPLP does not evaluate running processes directly. Instead, conformance is evaluated against an Evidence Pack — a static, exportable set of artifacts that represent one or more lifecycle executions.

┌─────────────────────────────────────────────────┐
│ Evidence Pack │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Context │ │ Plan │ │ Trace │ ... │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ + Manifest (protocol version, export time) │
└─────────────────────────────────────────────────┘

2.1 Why Evidence Pack?

PropertyBenefit
StaticCan be archived, shared, audited
Self-describingContains protocol version
Vendor-neutralPure JSON, no runtime hooks
ReplayableTrace can reconstruct timeline

3. Conformance Classes

MPLP v1.0.0 defines three conformance classes, corresponding to protocol layers:

ClassLayerMinimum Requirements
L1 ConformantDataValid Context, Plan, Trace schemas
L2 ConformantCoordinationL1 + Module interactions valid
L3 ConformantExecutionL2 + Runtime invariants hold

3.1 L1 Conformant (Data)

The system produces JSON objects that:

  • Pass schema validation against schemas/v2/*.json
  • Contain valid meta.protocolVersion
  • Use UUID v4 for all IDs

3.2 L2 Conformant (Coordination)

The system additionally:

  • Maintains Plan → Context linkage
  • Records Confirm objects for gated actions
  • Produces Trace segments for executed steps
  • Follows module interaction contracts

3.3 L3 Conformant (Execution)

The system additionally:

  • Emits runtime events (via Event Bus)
  • Supports drift detection
  • Provides snapshot/restore capability
  • Enforces lifecycle state transitions

4. Protocol Version Binding

Conformance is always scoped to a protocol version:

{
"meta": {
"protocolVersion": "1.0.0",
"schemaVersion": "1.0.0"
}
}

Rule: Evidence Pack version MUST match the protocol version being evaluated against.

5. Conformance Outcomes

Evaluation produces one of three outcomes:

OutcomeMeaning
CONFORMANTEvidence satisfies all requirements for the claimed class
NON-CONFORMANTEvidence violates one or more requirements
INCOMPLETE-EVIDENCECannot determine; evidence is missing or invalid

5.1 Non-Binary Results

MPLP does not produce:

  • Scores (0-100)
  • Grades (A/B/C)
  • Partial conformance percentages

Conformance is binary per class — a system is L1 conformant or it is not.

6. Evaluation Dimensions

Conformance is judged across these dimensions:

DimensionQuestion
Schema ValidityDo all objects pass JSON Schema validation?
Lifecycle CompletenessIs the Plan → Trace chain complete?
Governance GatingAre high-risk actions gated by Confirm?
Trace IntegrityCan execution be reconstructed from Trace?
Failure BoundingDo failures produce recoverable states?
Version DeclarationIs protocol version correctly declared?

7. Relationship to Golden Flows

Golden Flows define the reference behavior for conformance evaluation.

Golden FlowValidates
GF-01Single Agent Lifecycle (L1/L2)
GF-02Multi-Agent Coordination (L2)
GF-03Human-in-the-Loop Gating (L2)
GF-04Drift Detection & Recovery (L3)
GF-05External Tool Integration (L3/L4)

A system that passes GF-01 through GF-05 is L3 Conformant.

8. What Conformance Does NOT Guarantee

Conformance to MPLP does not guarantee:

  • Correctness of the agent's decisions
  • Quality of the generated plans
  • Security of the underlying runtime
  • Legal compliance with regulations
  • Business suitability for any use case

Conformance only guarantees: The system follows the protocol's structural and behavioral contracts.


Scope: Defines conformance objects, classes, outcomes, dimensions
Exclusions: Certification, legal compliance, quality guarantees