Skip to main content

Governance Model

PTI ecosystem governance combines practices proven in open internet standards and cloud-native foundations, adapted for regulated-adjacent trust infrastructure. This model is inspired by bodies such as the IETF, W3C, and CNCF — not a copy of any single organization's bylaws.

Design goals

The governance model MUST:

  1. Separate specification authority from implementation and operations
  2. Enable rough consensus among diverse stakeholders
  3. Provide escalation paths for architecture, security, and legal-adjacent questions
  4. Support a multi-phase transition from founder stewardship to mature ecosystem (Ecosystem Roadmap)
  5. Remain vendor-neutral in normative outcomes

Structural overview

Layers of authority

Layer 1 — Community (informal)

Anyone MAY participate in public review: comment on RFC drafts, file issues, run conformance self-assessments, and publish independent implementations. Community input SHOULD influence Working Group decisions but does not alone constitute approval.

Layer 2 — Working Group (normative process)

The Working Group owns the RFC process, specification lifecycle, and decision-making rules. It MUST publish meeting notes and decision logs for substantive votes.

Layer 3 — Review boards (specialized)

BoardMandateBinding power
Architecture Review Board (ARB)Cross-RFC coherence, layering, breaking-change impactSHOULD block Accepted → Stable promotion without sign-off on architectural RFCs
Security Review Group (SRG)Threat models, crypto choices, disclosure coordinationMUST review all RFCs touching authentication, encryption, or trust exchange
Conformance Program BoardProfiles, test suites, certification policyMUST approve profile changes affecting certified implementations

Review boards RECOMMEND; the Working Group MUST respond publicly to blocking recommendations.

Layer 4 — Stewardship (transitional)

During early phases, a Stewardship Council (initially aligned with the founding steward) MAY:

  • Fund infrastructure for RFC publication and test harnesses
  • Appoint initial Maintainers and board members
  • Execute trademark policy pending foundation transfer

The Stewardship Council MUST NOT unilaterally change Stable RFCs. Specification changes MUST follow Layer 2 process.

Comparison to familiar models

AspectIETF-style influenceW3C-style influenceCNCF-style influencePTI adaptation
Document unitInternet-Draft → RFCRecommendation trackProject sandbox → incubatingPTI RFC lifecycle
ConsensusRough consensus, running codeGroup decision, AC reviewTechnical oversight committeeWG + ARB for architecture
Implementation proofInteroperability demos valuedImplementation report至少 two adopters for graduationConformance tests + pilot implementations
MembershipIndividual participationMember organizationsVendor-neutral foundationOpen participation; no fee for RFCs
IP policyRoyalty-free standardsW3C patent policyCNCF CLARF terms for normative contributions (see Contribution Process)

PTI does not adopt any external body's membership fees, patent pools, or trademark rules wholesale. Implementers SHOULD consult counsel for IP implications in their jurisdiction.

Decision types and forums

Decision typePrimary forumAppeal path
New RFC acceptanceWorking GroupRe-open with new evidence; ARB review
RFC status promotionWorking Group + relevant boardStewardship Council audit (Phase 1–2 only)
Profile / test changeConformance Program BoardWorking Group ratification
Security advisorySRG → Working GroupPublic disclosure timeline
Trademark disputeTrademark policy ownerDocumented escalation (Phase 3+)
Governance rule changeWorking Group supermajorityPublic comment period (minimum 28 days)

Transparency requirements

The following MUST be publicly accessible:

  • Active RFC drafts and status history
  • Accepted governance documents in this section
  • Conformance profile definitions and test suite versions
  • Security advisories after coordinated disclosure
  • Annual stewardship report (from Phase 2 onward)

The following MAY be restricted temporarily:

  • Embargo-stage vulnerability details
  • Personal data in contribution attribution
  • Pre-decision legal advice

Phase-dependent governance

Governance authority expands with ecosystem maturity:

PhaseWorking GroupStewardshipIndependent foundation
Phase 1Convened; Maintainers appointedStrong operational roleNot yet
Phase 2Elected Maintainers; partner seatsShared fundingExploratory
Phase 3Community-elected leadershipAdvisoryForming
Phase 4Foundation-directedMinimalPrimary legal home

See Ecosystem Roadmap and Future Foundation Model.