POSIX Analogy — Conceptual Mapping
This page provides a conceptual mapping between POSIX interface ideas and MPLP's schema-defined lifecycle governance. The analogy is intended to help readers understand MPLP's positioning by relating it to a well-known interface standard.
Hard Boundaries
- This mapping is explanatory (analogy) and non-normative. It does not define MPLP requirements.
- MPLP is not POSIX, not an OS, and this is not a POSIX compatibility claim.
- Validation Lab evaluates evidence only; it does not host execution and does not certify implementations.
Conceptual Mapping Table
The following table maps POSIX concepts to their MPLP analogues. This is for conceptual positioning only.
| POSIX Concept | What POSIX Standardizes | MPLP Conceptual Mapping (Analogy) | Where It Is Enforced / Evidenced |
|---|---|---|---|
| Standard interface | App ↔ system boundary | Schema-defined lifecycle interface (Context / Plan / Confirm / Trace) | Schemas + Golden Flows |
| Syscall contract | Failure semantics, invariants | Module contracts + kernel duties (expected signals, failure behavior) | Schemas + Cross-cutting duties |
| Portability | Run across OSes | Portability across substrates (models / frameworks / runtimes / vendors) | Evidence Pack + Lab verdict ruleset |
| Signals | Standardized interrupts | Confirm gates / abort / rollback signaling | Confirm + Trace evidence |
| Logs / debugging | Observability | Trace timeline + Evidence Pack (replayable artifacts) | Trace schema + Evidence Pack manifest |
| Conformance tests | Portability proof | Golden Flows + evidence-based verdicts | Validation Lab (evidence-only) |
| libc / adapters | Portability surface | SDK surface / adapters (schema-preserving usage) | SDK conformance evidence (usage-level) |
Where MPLP Enforces This
The conceptual mappings above are realized through concrete, verifiable constructs:
- Schemas: Define the data contracts for Context, Plan, Confirm, Trace, and all L2 modules. See Architecture.
- Golden Flows: Provide evaluation scenarios that validate lifecycle invariants. See Golden Flows.
- Kernel Duties: Specify cross-cutting responsibilities that all implementations must honor. See Kernel Duties.
- Evidence Pack: The replayable artifact bundle that Validation Lab consumes for verdict generation.
- Validation Lab: Evidence-based evaluation only; it does not host execution or certify implementations.
How to Use This Page
After reading this conceptual mapping:
- Understand the architecture: Review L1–L4 Architecture to see how layers map to the "interface boundary" concept.
- Explore modules: Each L2 module defines specific contracts. Start with Module Interactions.
- See it in action: Golden Flows demonstrate the expected lifecycle behavior.
- Evaluate your implementation: Validation Lab consumes Evidence Packs to produce verdicts—without hosting execution.
FAQ (Misread Prevention)
Is MPLP compatible with POSIX?
No. MPLP is not POSIX and does not implement any POSIX APIs. The POSIX analogy is purely conceptual—it helps explain what kind of standardization MPLP provides (interface-level, not network-protocol-level).
Does this page define normative requirements?
No. This page is strictly non-normative. All normative requirements are defined in the Schemas and the specification documents.
Does MPLP certify implementations?
No. MPLP provides evaluation mechanisms (Golden Flows, Validation Lab) but does not offer certification. Validation Lab produces evidence-based verdicts, not endorsements.
Is MPLP an operating system or runtime?
No. The "Agent OS Protocol" designation refers to MPLP's role as a lifecycle governance protocol—analogous to how POSIX governs the app/OS interface—not to MPLP being an actual OS or runtime.