How Groundwork's protocol is organized
Lexicons
Groundwork does one job on purpose: it records who has authority, and how they came to have it. It doesn't record how a group argued its way to a decision, or what meeting format they used, or whether they run sociocracy or majority vote. That's deliberate — the narrower Groundwork stays, the more freely other things can build on top of it without fighting its assumptions.
This page is the shape of that idea, not a schema reference — a draft of the actual lexicons (the machine-readable definitions themselves) is forthcoming. What follows is the philosophy: how the pieces are meant to layer, and why.
Three layers, not one lexicon
⭕ Groundwork — authority
Circles, roles, consent, delegation. Who belongs to what, who holds what, and the record of how that authority was actually granted. This is the layer this app implements. Nothing above it is required to use it.
📜 Assembly — deliberation Designed
Proposals, responses, decisions, agreements, meetings — how a group actually argues, decides, and remembers why. Fully designed, and referenced by this app's roadmap, but not yet wired into anything you can click here.
🛠️ Facilitation products — methodology
Whatever a specific community actually runs on — sociocracy, Robert's Rules, an async RFC process, a General Assembly. This layer is wide open. Different products, same underlying records.
Inside Groundwork itself
Twelve record types, grouped into four conformance profiles. A product declares which profiles it supports — the profiles are independent concerns, not a stack you climb in order. A federated directory could implement Federation without ever touching Consent.
groundwork/core
The interoperability floor — circles exist, roles exist, acts are logged. Not itself a governance implementation.
circleA sovereign governance unit — a group with real authority over its own domain.
roleA bundle of capabilities within a circle. Not an access level — a capability bundle someone accepts.
opThe append-only log every governance act writes to, regardless of what else a product implements.
consentEventA plain-language summary of a governance act — readable by a person, structured enough for a machine.
groundwork/consent
The actual proposal: authority is granted through a traceable process, not just declared. This app implements this profile.
roleOfferThe first act of the consent ceremony — written by whoever's offering the role.
roleMembershipAcceptance, written by the holder on their own PDS — not the circle's.
roleProposalA proposed change to a role, which triggers re-consent from existing holders rather than silently updating.
delegationA scoped, time-bound handoff of authority between circles — always traceable, never open-ended.
proxyConsentA member authorizing someone else to exercise consent on their behalf.
proxyAcceptanceThe proxy holder actually exercising that authorization.
groundwork/federation
Independent of consent — sovereign circles relating to each other, and circles that move.
circleLinkA declared relationship between circles — peer, federation, delegate, advisory, or founder.
circleForwardA migration pointer, so a circle's identity survives moving to a new DID.
groundwork/capability-execution
No new records — extra fields on existing ones (an execution grant on a capability, a credentials pointer) for capabilities a machine can actually carry out, not just describe. Can't be claimed without Consent underneath it — an execution grant with no consent behind it is exactly the access-list problem Groundwork exists to avoid.
Why layer instead of building one big thing
Different communities need different amounts of structure, and asking all of them to adopt a full methodology to get basic legibility is how governance tools end up unused. You can build directly on Groundwork alone — a read-only view of who holds what, with no deliberation tooling at all — and that's a complete, valid thing to build. Assembly and a facilitation product are additions, not requirements.
A few sparks, not a roadmap
Illustrative, not an exhaustive list — just what composing these layers could look like in practice:
A governance health dashboard — reads only Groundwork data: which circles have gone quiet, which roles are vacant. No Assembly needed.
An RFC-style proposal tool — a written proposal, a comment period, a decision with a summary of how concerns were addressed. Assembly, minimal UI.
A cooperative minutes app — meetings, agenda items, outcomes, and the resulting agreements, all landing as records the cooperative actually owns.
A full facilitation suite — real meeting mechanics (blocks, temperature checks, stack management) with clean records underneath the theater.
A draft of the lexicons themselves — the actual record definitions — is forthcoming. This page is the "why," not the "what fields."