Foundational Governance Practices
Patches and comments are scoped to the whole document family, not to a single revision. When you open a revision, highlights show what still applies to that revision body; anything anchored to text a later revision removed is listed as needing re-anchoring, and anything that can no longer be merged at all is marked obsolete. See all patches.
Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.
Foundational Governance Practices
Status: Draft - Open for Input Created by; The Meta-Layer Infrastructure SIG Board Origin Date: 7 Sept 2025 Last Updated: 8 Sept 2025
Preamble:
What Changed Since the Previous Revision
This revision incorporates feedback from early community discussion and aligns the document with the Meta-Layer governance tooling now in active use.
Key changes include:
Added a How to Participate (Quick Start) section near the top of the document to make entry points and participation pathways immediately visible. Clarified participation pathways, emphasizing that anyone may submit drafts, comment, or join workgroups without creating a Project. Introduced Projects, Guilds, Workgroups, and Coordinators as explicit governance primitives, with clear separation of roles. Defined Stabilization as a readiness phase rather than a point of finality. Clarified that ML-RFCs remain open to public comment after publication, with structured paths for errata, amendments, or superseding drafts. Added a Glossary to normalize terminology across drafts, tooling, and community practice. Identified https://rfc.themetalayer.org as the primary governance hub for participation. Performed editorial cleanup to improve clarity, consistency, and long-term readability.
No changes were made to the core governance ethos of openness, rough consensus, or artifact-based public memory.
Preamble
The Internet experience begins at the interface, where people encounter information, agents, and one other.another. Protocols and signals are essential, but they are not the experience. We don'tdo makenot thebuild foundational network protocols; we stitch them together and enable them to cooperate in the layer above the web. This is the meta-layer meta-layer:: the space of meaning, annotation, identity, and interaction. Where the IETF ensures the plumbing flows, we ensure that what flows connects people in ways that are open, trustworthy, and interoperable.
Our ethos is familiar - rough consensus and running code - but our vision is distinct: a people-centered Internet that cannot be reduced to pipes and packets. We build the interface layer that gives context to content, trust to transactions, and voice to communities. Just as the IETF stewarded the web's foundation, the MLTF must steward its next level.
Where the IETF ensures the plumbing flows, the Meta-Layer Infrastructure SIG ensures that what flows connects people in ways that are open, trustworthy, and interoperable. Our ethos is familiar - rough consensus and running code - but our focus is distinct: a people-centered Internet that cannot be reduced to pipes and packets.
Just as the IETF stewarded the web's foundation, the Meta-Layer Infrastructure SIG stewards its next level.
How to Participate (Quick Start)
Anyone can participate. The Meta-Layer governance process is open by default. Participation begins at https://rfc.themetalayer.org .
(Optional) Register a Project if you are stewarding a long‑lived body of work. Most participants will submit drafts to existing Projects. Submit an ML-Draft (anyone may submit) and associate it with a Project. Assign or form a Workgroup to steward deliberation and assess rough consensus. Comment and annotate drafts and RFCs at any time. Join or create a Guild to learn, collaborate, and seed new work.
Participation does not require affiliation, permission, or prior approval. Visibility, deliberation, and recorded context are the basis of legitimacy.
1. Purpose
This Draft establishes the foundational governance practices of the Meta-Layer Infrastructure SIG. It is not only a request for input, but an act of unfolding :unfolding: the SIG itself will emerge through these practices.
We propose to adopt a hybrid governance framework inspired by the Internet Engineering Task Force (IETF) -(IETF), rooted in transparency, decentralization, and inclusiveness -inclusiveness, while adapting it to the opportunities and challengesrealities of interface-level civic infrastructure.infrastructure and long-lived public digital artifacts.
By publishing ML-Draft-001, we are setting the table for the entire organization: how it documents itself, how it makes decisions, and how it evolves. This document will serve as the operational directive for the formation and growth of the SIG.
By publishing ML-Draft-001, we set the baseline for how the SIG documents itself, makes decisions, records consensus, and evolves over time.
2. Document Lifecycle: ML-Draft → ML-RFC
ML-Drafts: Exploratory, open documents for capturing ideas, lessons, and proposals. Drafts may be submitted by individual members, but we anticipate and encourage that most will emerge from guilds -small, high-trust groups that review, draft, and steward ideas in the open. Not binding; some may never advance, and that's acceptable. ML-RFCs (Meta-Layer Requests for Comment): Stable documents promoted from ML-Drafts by community consensus and, when needed, formal vote. Represent adopted practices, principles, or shared frameworks for the SIG. Archiving & Provenance: All ML-Drafts and ML-RFCs will be permanently archived (e.g. on Ordinals) , ensuring transparent provenance and long-term accessibility. This record is part of our commitment to accountability and trust. Application for Commenting: We envision building an RFC Application - a public platform where members and observers can read, comment, and track revisions to Drafts and RFCs. This may subsume the Desirable Properties app, creating a single space for civic deliberation.
We anticipate adopting many RFCs in the SIG's first two years , especially around Desirable Properties, terminology, substrate requirements, and governance. These RFCs will form the constitutional building blocks of the Meta-Layer and provide a strong foundation for the planned transition to the Meta-Layer Task Force.
2.1 Overview
The Meta-Layer governance process follows a continuous lifecycle rather than a linear, one-time approval path. Artifacts evolve, decisions are recorded, and prior context remains visible.
The lifecycle is intentionally summarized in a high-level diagram (where included). Detailed comment processes, consensus checks, escalation paths, and post-RFC change mechanisms are specified in the sections below and are not fully represented in the figure.
Figure 1. Meta-Layer Governance Lifecycle. A high-level view of how ideas evolve into ML-Drafts, advance through community deliberation and stabilization, become ML-RFCs, and continue through maintenance and evolution. The diagram is intentionally simplified; detailed comment, consensus, and change processes are specified in the accompanying text.
2.2 ML-Drafts
Revision Notes (Encouraged): Authors submitting revised versions of an ML-Draft are encouraged to include a brief explanation of substantive changes. Explanations are optional for purely editorial revisions, but strongly recommended when changes affect scope, governance mechanisms, or interpretive meaning.
ML-Drafts are exploratory, open documents used to capture ideas, lessons, proposals, and emerging practices.
Drafts may be submitted by individuals or groups. Each draft is submitted within the context of a Project (see Section 2.6). The SIG encourages drafts to emerge from guilds or workgroups that steward ideas collaboratively. Drafts are not binding. Some drafts may never advance, and this is expected and acceptable.
2.3 Community Deliberation
All ML-Drafts are subject to community deliberation , which includes:
Public comments and annotations Open Draft Lab sessions Asynchronous discussion and review Informal consensus signals (e.g., polling, humming)
Community deliberation is treated as a first-class governance activity and forms part of the permanent decision record.
2.4 Stabilization
Stabilization is the phase in which a draft is prepared for potential reliance.
Stabilization includes:
Resolving substantive objections, or explicitly recording unresolved disagreements Clarifying scope and non-goals Ensuring terminological consistency Confirming required sections are present
Stabilization does not imply finality or immutability. It indicates readiness for possible promotion while preserving the ability to evolve.
2.5 ML-RFCs
ML-RFCs (Meta-Layer Requests for Comment) are stable governance artifacts promoted from ML-Drafts by community consensus and, when required, formal approval pathways.
ML-RFCs represent adopted practices, shared principles, or governance frameworks for the SIG. They are intended to be relied upon, but not treated as permanently closed.
Promotion from ML-Draft to ML-RFC requires an associated workgroup to assess rough consensus and readiness for reliance.
3. Post-RFC Comments and Evolution
Once an ML-RFC is published, it remains associated with its originating Project and workgroup for purposes of stewardship and evolution.
Publication as an ML-RFC does not close public comment.
ML-RFCs remain open to annotation and feedback. Post-publication comments may result in:
Errata (editorial or clarifying corrections) Amendments (non-breaking extensions or refinements) Superseding drafts (major revisions responding to changed conditions or fundamental disagreement)
The original ML-RFC remains preserved as part of the historical record. Changes are additive and explicitly linked, never silently overwritten.
3.4. Governance Modes: Rough Consensus vs.and Formal VoteDecision Paths
Rough Consensus: Most decisions (e.g., direction-setting, exploratory work) will be made through visible consensus signals ("humming," polls, comments, discussion). Formal Vote: Critical transitions (e.g., elevating a Draft to ML-RFC, elections, resource allocations) will require an affirmative vote. This may be implemented through a DAO platform for auditable legitimacy. This dual approach balances joyful communal labor with formal accountability mechanisms .
4.1 Workgroups and Rough Consensus
Workgroups are the primary bodies responsible for determining whether rough consensus has been achieved for a given draft or RFC transition.
A workgroup:
Is formed around a specific Project or scope Is open to participation Facilitates deliberation and synthesis Signals whether rough consensus has been reached
Workgroups do not exercise unilateral authority; they act as sensemaking and coordination bodies for the community.
4.2 Coordinators
Each workgroup may have one or more coordinators .
The role of a coordinator is to:
Convene discussions Ensure process integrity Surface objections and consensus signals Coordinate transitions between lifecycle phases
Coordinators do not act as chairs in the traditional sense and do not make decisions on behalf of the group.
The SIG operates under a dual governance model:
Rough Consensus: Used for most direction-setting, exploratory work, and draft development through visible community signals. Formal Decision Paths: Used for critical transitions, including promotion of ML-Drafts to ML-RFCs, elections, and significant resource allocations.
Formal decision paths may include recorded steward decisions, votes, or DAO-enabled mechanisms where appropriate.
4.5. IETF-Inspired Cultural Anchors
We propose adopting/adapting these practices:
Participation as individuals, not companies. Rough consensus & humming. Transparency by default. Joyful communal labor (hackathons, office hours). RFC-like recordkeeping. Reflection & iteration (timely contributions > perfection). Zones of autonomy for working groups. Living system ethos - treating the SIG as regenerative, not static.
5. Link to Desirable Properties
The SIG's work is guided by the 21 Desirable Properties of a Meta-Layer . Governance practices outlined here are not separate - they are how we will live out those properties in practice (e.g., inclusiveness, accountability, accessibility).
6. Teaching & Transparency
This SIG is not only building civic infrastructure; it is also teaching the world how to start a living, global organization . By openly archiving Drafts, documenting consensus, and experimenting with DAO-enabled voting, we model a new kind of regenerative organizational design.
As DAOs were once prototypes for decentralized governance, the Meta-Layer SIG may serve as a model for transparent, people-centered governance in the interface era.
The SIG adopts and adapts the following IETF-inspired practices:
Participation as individuals, guilds, and projects Rough consensus and visible signals Transparency by default Joyful communal labor (e.g., open labs, working sessions) RFC-like recordkeeping Reflection and iteration over perfection Zones of autonomy for workgroups A living-system ethos that treats governance as regenerative
6. Archiving, Provenance, and Inscribed Governance Artifacts
All ML-Drafts and ML-RFCs are archived to ensure durable provenance and long-term accessibility.
Each artifact is associated with a Project , and its lifecycle transitions are stewarded through a workgroup.
The SIG enables, but does not require, Drafts and RFCs to be submitted as Inscribed Governance Artifacts (IGAs) - governance artifacts anchored to neutral public substrates.
Inscription preserves:
Existence and authorship Temporal context Independence from any single platform or institution
This practice supports public memory without enclosing participation or imposing technical barriers.
7. Teaching, Transparency, and Public Learning
The Meta-Layer Infrastructure SIG is not only building civic infrastructure; it is teaching how such infrastructure can be built.
By openly documenting drafts, projects, guilds, workgroups, deliberation, consensus signals, and evolution, the SIG serves as a living example of transparent, people-centered governance at the interface layer of the web.
The primary governance hub for Meta-Layer activity is:
https://rfc.themetalayer.org
This hub enables public participation in Meta-Layer governance by allowing anyone to:
Register a Project that wishes to build governance in public Submit ML-Drafts and associate them with a Project Assign drafts to an existing or newly formed workgroup Comment on any draft or RFC Register a Guild and invite others to join
The hub is designed to lower barriers to participation while preserving durable records of governance activity.
The Meta-Layer Infrastructure SIG is not only building civic infrastructure; it is teaching how such infrastructure can be built.
By openly documenting drafts, deliberation, consensus, and evolution, the SIG serves as a living example of transparent, people-centered governance at the interface layer of the web.
8. Glossary of Terms
The following terms are used throughout this Draft and related ML-Drafts and ML-RFCs:
Artifact: A durable governance object, such as an ML-Draft or ML-RFC, including its associated context and history.
Community Deliberation: The set of public processes through which drafts are discussed, annotated, and refined, including comments, Open Draft Labs, and asynchronous discussion.
Coordinator: A facilitator within a workgroup responsible for convening discussion, maintaining process integrity, and surfacing consensus signals. Coordinators do not decide outcomes.
Draft (ML-Draft): An exploratory, non-binding governance document submitted for community input and deliberation.
Guild: An informal community of practice organized around shared skills, domains, or interests. Guilds may propose drafts, convene learning, or seed Projects.
Inscribed Governance Artifact (IGA): A governance artifact anchored to a neutral public substrate to preserve provenance, authorship, and temporal context.
Meta-Layer: The interface layer above the web where meaning, annotation, identity, presence, and interaction are coordinated.
Project: A persistent container for work within the SIG. Every draft and RFC is associated with a Project, which provides scope and continuity beyond individual documents.
Rough Consensus: A decision-making mode characterized by visible agreement and the absence of sustained, substantive objections, rather than formal voting.
RFC (ML-RFC): A stable governance artifact promoted from an ML-Draft through community consensus and defined approval pathways.
Stabilization: The phase in which a draft is prepared for potential reliance by resolving or explicitly recording objections and ensuring clarity and consistency.
Workgroup: An open coordination body convened around a Project or draft to steward deliberation, assess rough consensus, and manage lifecycle transitions.
7.9. Two-Year Sunset
The Meta-Layer Infrastructure SIG is designed as a two-year initiative .initiative. During this period, wethe expectSIG is expected to produce and adopt a significantsubstantial body of RFCsML-RFCs covering governance, terminology, Desirable Properties, and substrate requirements. At the end of two years, the SIG will transition into the Meta-Layer Task Force , carrying forward this corpus of RFCs as its foundation.
At the conclusion of this period, the SIG will transition into the Meta-Layer Task Force, carrying forward the accumulated corpus of ML-RFCs as its foundation.
10. Projects, Guilds, and Workgroups
10.1 Projects
Projects are the primary containers for work within the SIG. Every submission, draft, or RFC is associated with a Project.
Projects:
Provide scope and continuity May host multiple drafts and RFCs Persist beyond individual documents
10.2 Guilds
Guilds are informal communities of practice organized around skills, domains, or interests. Guilds may propose drafts, convene learning, or seed Projects.
10.3 Workgroups
Workgroups are convened to steward specific drafts or Projects through governance transitions.
A workgroup is required to:
Assess rough consensus Recommend stabilization and promotion Steward post-RFC evolution
10.4 Terminology
The SIG intentionally uses workgroup rather than working group , and coordinator rather than chair , to emphasize facilitation, sensemaking, and interface-level governance over hierarchy.
8.11. Open Questions for Input
How should we classify ML-RFCs and define their statuses (e.g., draft, active, obsolete, informational), so participants know how they can be used and referenced, similar to IETF's system ? What criteria should we use to promote Drafts into ML-RFCs and to approve ML-RFCs? The IETF has a very intensive process for promoting a draft to RFC, which is probably too strict for our current needs. We are not developing detailed technical protocols at this stage, but rather foundational aspects of governance and terminology. These should remain adaptable, and can be modified through the same process in the future. Therefore, we should avoid feeling locked-in the way protocol standards might require. How should the ML Draft workflow work at the moment before we create custom tooling? How should DAO voting be implemented if at all - lightweight or binding only for key decisions? What other IETF cultural practices should we adopt/adapt for our context? How should the RFC Application evolve (standalone or integrated with Desirable Properties app)?
9. References & Related Work
This Draft is informed by research into the IETF's long-lived, regenerative governance systems. Two reports in particular provide important context:
Exploring the Remarkable Regenerative Patterns and Practices of the Internet Engineering Task Force (IETF) - a study of the Internet Engineering Task Force's organizational practices, culture, and regenerative dynamics. The IETF: Organization, Rough Consensus, RFC Process, and Decentralized Meta-Layers - a companion research report exploring IETF processes, participation, and governance lessons as well as the extent to which the IETF addresses the meta-layer.
Also here is the IETF Administrative policies and procedures page .
The SIG invites input on the following questions:
How should ML-RFCs be classified and statused (e.g., active, obsolete, informational)? What criteria should govern promotion from ML-Draft to ML-RFC? How should draft workflows operate prior to custom tooling? How should formal decision mechanisms (including DAO-based voting) be scoped? Which additional IETF cultural practices should be adopted or adapted?
12. Informative References and Related Work
This Draft is informed by long-standing research into IETF governance practices and regenerative organizational models, including:
Exploring the Remarkable Regenerative Patterns and Practices of the Internet Engineering Task Force (IETF) https://docs.google.com/document/d/1tgZ86ugijXPUOo_lD3kLfQBPbneecUNzZim1GOgkC1M/edit?tab=t.0 The IETF: Organization, Rough Consensus, RFC Process, and Decentralized Meta-Layers https://drive.google.com/file/d/1z3kpn_7fjzEwlGnd6OIxvwlzhVzUpbW2/view IETF Administrative Policies and Procedures https://www.ietf.org/administration/policies-procedures/
Published: 2026-02-17
Pages: 6 | Words: 2124
What changed:
This revision incorporates feedback from early community discussion and aligns the document with the Meta-Layer governance tooling now in active use.
Key changes include:
Added a How to Participate (Quick Start) section near the top of the document to make entry points and participation pathways immediately visible.
Clarified participation pathways, emphasizing that anyone may submit drafts, comment, or join workgroups without creating a Project.
Introduced Projects, Guilds, Workgroups, and Coordinators as explicit governance primitives, with clear separation of roles.
Defined Stabilization as a readiness phase rather than a point of finality.
Clarified that ML-RFCs remain open to public comment after publication, with structured paths for errata, amendments, or superseding drafts.
Added a Glossary to normalize terminology across drafts, tooling, and community practice.
Identified https://rfc.themetalayer.org as the primary governance hub for participation.
Performed editorial cleanup to improve clarity, consistency, and long-term readability.
No changes were made to the core governance ethos of openness, rough consensus, or artifact-based public memory.