Protocol Hierarchy

Overview

The JellyLabs governance system is built on a meta-protocol hierarchy that establishes clear authority relationships between protocols. This hierarchy prevents governance deadlock and ensures that all changes flow through a consistent, well-defined process.

The Hierarchy

PSP v1 (Proposal Specification Protocol)
  ↓ governs structure of ↓
DIDP v1 (Deterministic Iterative Development Protocol)
  ↓ uses for publication ↓
PPP v1 (Protocol Publication Protocol)

Note on PSP Naming Evolution: PSP v1 was originally envisioned as “Protocol Specification Protocol” (defining how protocols are structured) but evolved during implementation to “Proposal Specification Protocol” (defining change governance). The protocol structure specification functionality was later identified as a separate concern. See Decision Log DL-008 for details.

Authority Order

From highest to lowest authority:

  1. PSP v1 — Governs what may be proposed, introduced, or changed
  2. DIDP v1 — Governs how approved work is developed
  3. PPP v1 — Governs how completed work is published
  4. Documentation — Explanatory only (non-normative)

Why This Matters

Prevents Contradiction

Without a clear hierarchy, protocols could conflict with each other:

  • DIDP might define a development process that PSP forbids
  • PPP might require publication formats that DIDP can’t produce
  • Changes to one protocol might invalidate another

The hierarchy ensures that lower protocols cannot contradict higher protocols.

Establishes Clear Proposal Pathway

Any change to the JellyLabs system must follow this path:

  1. Proposal must conform to PSP — If it doesn’t, it cannot proceed to development
  2. Development must follow DIDP — If it doesn’t, it cannot converge
  3. Publication must follow PPP — If it doesn’t, it cannot be published

This creates a single, unambiguous path for all changes.

Closes the Bootstrap Loop

A critical question for any governance system: Who governs the governors?

In the JellyLabs hierarchy, the answer is: PSP governs PSP.

From PSP v1, Section 8 (Self-Application):

PSP v1 applies to itself. Any proposal to modify, replace, or deprecate PSP v1 MUST be submitted as a PSP-conformant proposal.

This means:

  • PSP cannot be changed arbitrarily
  • All PSP changes must go through the same proposal process as any other change
  • The system is self-consistent and governable

Makes the System Governable

Without this hierarchy, the governance system would be designed but not governable:

  • No clear way to propose changes
  • No way to resolve conflicts between protocols
  • No protection against contradictory modifications

With the hierarchy, the system is both designed AND governable:

  • Clear process for proposing changes (PSP)
  • Clear process for implementing changes (DIDP)
  • Clear process for publishing changes (PPP)
  • Self-consistent rules that prevent deadlock

Modification Rules

Changing PSP

To modify PSP v1:

  1. Submit a PSP-conformant proposal
  2. Proposal must explain why the change is needed
  3. Proposal must demonstrate PSP v1 compliance
  4. If accepted, develop under DIDP v1
  5. Publish under PPP v1

Changing DIDP

To modify DIDP v1:

  1. Submit a PSP-conformant proposal (PSP governs all changes)
  2. If accepted, develop under DIDP v1
  3. Publish under PPP v1

Changing PPP

To modify PPP v1:

  1. Submit a PSP-conformant proposal (PSP governs all changes)
  2. If accepted, develop under DIDP v1
  3. Publish under PPP v1

Changing Documentation

Documentation is non-normative (explanatory only). It can be updated without formal proposals, but:

  • Must not contradict published specifications
  • Should be kept in sync with specifications
  • Cannot establish new requirements

Historical Context

The meta-protocol hierarchy was established during the foundational design work for JellyLabs (December 2025). It was explicitly documented in Foundation Session 2 (CONVO-02) as a critical architectural decision.

From CONVO-02-EXTRACT.md:

The Bootstrap Problem: If PSP controls permissions to modify DIDP, and DIDP controls how proposals are developed, but PSP itself needs a modification process — who governs PSP?

Solution: PSP is self-applying. Changes to PSP must follow PSP’s own proposal process. This closes the loop and prevents governance deadlock.

References

  • PSP v1 Specification: /specs/psp/v1
  • DIDP v1 Specification: /specs/didp/v1
  • PPP v1 Specification: /specs/ppp/v1
  • Conversation Archive: archive/conversations/CONVO-02-EXTRACT.md (Phase IV: PSP Discovery)

Critical Insight

Never modify protocols without understanding the entire chain.

The hierarchy exists to prevent:

  • Contradictory protocols
  • Governance deadlock
  • Unclear authority
  • Un-governable systems

When proposing changes to any JellyLabs protocol, always ask:

  1. Does this conform to PSP?
  2. Can this be developed under DIDP?
  3. Can this be published under PPP?
  4. Does this contradict any higher-authority protocol?

If the answer to any question is “no” or “unclear,” the proposal needs revision before proceeding.