The canonical specification for the system that holds the authoritative state of RegenHub, LCA and makes that state legible to members, directors, officers, auditors, and the agents that build and operate it. Version 0.3 carries the ten principles unchanged, retires an external design gate whose funder context has ended, and defines four launch slices in place of a phased calendar.
This document specifies the Common Information System for RegenHub, LCA, a Colorado public benefit limited cooperative association operating publicly as Techne. The system's purpose is unchanged from the first version: to hold the cooperative's authoritative state and to make that state legible. It is the book of record and the interface through which the cooperative operates itself. It is written for organizers, for members, for counsel, and for the build and runtime agents whose working context is assembled from this series.
Version 0.3 differs from version 0.2 by two removals and one addition. Removed: the sections that established an external design discipline as a gate on delivery, and the rule that a phase shipping below its target had shipped a regression. Added: four launch slices as the unit of scope, replacing the phased calendar. Everything else carries, and where a v0.2 structure is inherited this document says so, because a refactor that hides its lineage is not legible. The removal is recorded formally below, at a citable address, so that the change is a fact in the record rather than an absence.
The four properties of the Ethereum Foundation Mandate (Censorship Resistance, Open Source, Privacy, Security, collectively CROPS) served in v0.2 as the design discipline against which architectural decisions were gated, with an evolutionary pathway and per-phase stage targets. The Ethereum Foundation's community hub program has ended, and the cooperative's eligibility for that funding ended with it. Filed · as reported
Effective this version, CROPS is retired as a requirement and as a delivery gate. It is retained in the record as a design note and as history. The ten principles of §2, which predate the mapping and were always the cooperative's own, carry forward unchanged and are the sole design authority of this specification. Properties formerly credited to the mapping survive only where a principle holds them on the cooperative's own reasoning: openness under principles 02, 04, 07, and 10; security as conservation, traceability, and audit under principles 04, 05, and 09; privacy under principle 06; and portability under principle 08. Censorship resistance is not carried as a requirement. On-chain attestation of the event log moves from commitment to optional layer, adoptable later only with its own stated justification.
The sibling document Hub Operations PRD v0.1, which specified the grant-reporting surface, is retired as a governing specification. Its application, event registration, and attendance modules are salvaged into the Belong and Gather slices of §4. Its KPI and compliance machinery is retired with the grant. Nothing is deleted; the superseded documents remain in the record as history. Drafted · this record
Document conventions follow the series overview (SER v0.1 §2): every claim wears a status mark; citations use code, version, and section; supersession is explicit; only humans record decisions; the Subchapter K vocabulary quarantine holds throughout.
Ten principles, carried from v0.2 with their numbering intact so existing citations continue to resolve. What is removed is only the mapping layer that annotated them against an external mandate. They now stand, as they always could have, on the cooperative's own authority.
One authoritative state with three doors. The doors differ; the room does not. Browse is the graphical surface, Ask is the natural-language surface, Verify is the ledger and its audit views. All three read the same underlying record; none holds private state of its own.
The system remains defined as much by what it is not. It is not a marketing site: the public door (LP) introduces the system but is not the system. It is not a CRM: people appear in the record as agents with memberships and agreements, not as leads. And it is not a social platform: the Find one another slice of §4 adds a bulletin surface where members post offers and invitations to play, practice, and work, but entries there are governed records with authors and lifecycles, not a feed ranked for engagement. This is a clarification of the v0.2 boundary rather than a breach of it, and it is named here so the departure is chosen, not slipped.
The ratification vote of August 14, 2026 is recorded in the system as a governed event with signatures, but the full governance module (motions, ballots, threshold machinery) is post-launch scope, sequenced in the roadmap (RDM) after the four launch slices. Anticipated
The unit of scope is the slice: a coherent capability a member can use the day it lands, named identically on the public page and in the work plan. Slices replace phases. There are no dates below except the single gate the cooperative already holds; readiness conditions do the sequencing, and a blocked slice wears the mark of what blocks it, by name.
Identity, membership, and agreement. The slice through which a person becomes, and remains, legible to the cooperative: one agent record that persists as their relationship changes, from visitor to member, whatever their class.
Events and presence. The slice that makes the studio's calendar part of the record: what is happening, who is hosting, who came, and what came of it.
The opportunity surface. The genuinely new slice of this version, with no v0.2 predecessor: a bulletin of offers and invitations to play, practice, and work, where relationships and livelihoods begin. Entries are governed records with an author, a lifecycle, and an outcome, not posts in a feed.
Contribution and account, read-only at first. The slice through which each member sees what they have put in, whether work, patronage, or capital, and the share of results that follows, alongside the written rules that computed it. Balances are computed from the event log, never stored as editable numbers.
Beyond the launch slices, two capability areas remain in system scope but out of launch scope: the governance module (motions, ballots, notice machinery) and treasury execution (distributions, multi-signature authorization). Treasury's packets sequenced 2026-07-22 as the T train, specified by the Treasury module PRD at /commons/treasury/, and the deployed map settled its public name as Treasury; the governance module remains without a slice name, a module PRD, or packets, and is the one scoped capability with no trajectory yet in the roadmap. Open · governance naming and splice amended 2026-07-27 · X-13
Everything in the system resolves to one of four primitives: Agents, who participate; Resources, which flow; Events, which happen; and Agreements, which bind. Agreements are first-class records, not metadata, and every relationship between records is itself an event. The vocabulary is closed: a new kind of thing is admitted only by expressing it through these four. This is what lets a contribution, a vote, a payment, and a membership be reasoned about in one grammar, and it derives from the REA accounting ontology (McCarthy, 1982) as extended in v0.2.
All authoritative state is a deterministic fold over one ordered, append-only log of events. Balances are computed, never stored. Nothing in the past is edited; a correction is a new compensating event, so the history of a fact travels with the fact. The conserved quantities named by principle 05 are enforced at the data layer: one voting share per voting member, vote tallies equal to the sum of cast votes, each capital account equal to the fold of that member's capital events, and the patron-majority economic floor the Colorado act requires. An operation that would break one of these is refused before it is written, not flagged after. Drafted · eleven laws
Every surfaced claim carries the three-axis status contract, generalized from the instrument work into the system-wide vocabulary: provenance (real or illustrative, authored), settlement (settled, anticipated, or open, authored), and temporal state (elapsed or ahead, derived from the clock and never authored). The three axes are independent and are not collapsed into a single status field.
The canonical schema belongs to the Information Model artifact (IM), whose seed is the eleven invariant laws already drafted in The System Before Its Name together with the C6 schema reference card. The nineteen cooperative core tables carry; the twelve Hub extension tables reduce to what Gather actually needs, with the final count settled in IM, not here. Anticipated · IM v0.1
What an agent may see is a pure function of their role, the record's class, and the governing section of the bylaws. It is defined by the governing documents, not granted or revoked by an administrator for convenience. The default is disclosure to members; the exceptions are structural rather than toggled: tax identifiers, personal contact details, and sensitive deliberations.
Cite-as-you-enforce is the discipline that ties the books to the law, and it is concrete. Under the drafted bylaws, the memberships records cite §1.1 to 1.4; capital accounts cite §5.1; votes cite §1.6 and §1.14; meeting attendance cites §2.7; notices cite §2.4 and Article X; confidentiality obligations run end to end under Article 18. These anchors are real today and provisional today, because the bylaws they cite are themselves Drafted; every policy that cites them hardens at ratification and is re-verified then. Drafted · hardens at R1
Member classes are defined by the bylaws, including the patron-majority requirement that patron members receive the majority of economic benefit at the cooperative level. The full class structure, including the patron and investor classes and the question of whether co-working members are partners for tax purposes with capital accounts, remains before the board and counsel. This document does not resolve it; it requires only that the system represent whatever the bylaws settle, faithfully, per principle 03. Open · §11
No agent, human or machine, may invent a permission. The Authority Map (AM v0.1) is the citable catalog of roles and row-level policies, each with its bylaw anchor; the runtime instrument operates under scoped impersonation so that an answer never draws on more than the asking member could see themselves.
The substrate carries from the estate and is named honestly as a constraint: static pages served from the repository, with Supabase as the data layer. There is no application server the cooperative runs, which is why enforcement lives in the database. Row-level security, append-only event tables, and declared constraints are not implementation details here; they are where the principles become load-bearing.
New dependencies require a decision record under the Build Protocol. The substrate's limits are accepted deliberately: what cannot be done well on static pages plus a governed database is deferred, not improvised.
Stated on the cooperative's own authority, each anchored to the principles it serves. These are the floor below which no slice ships.
The acceptance criteria for each slice are the plain-language capability blocks in §4: each sentence beginning a member can is a test, verified per the Verification Spec. Above the slices sit six system-level criteria, each of which can be checked rather than asserted.
The single gate the cooperative holds: Belong and Gather usable by members at the ratification gathering of August 14, 2026. Anticipated
Each question names its owner and what it blocks. None blocks the start of the build; each becomes blocking exactly where its scope becomes material, and a blocked packet wears the mark of the question that blocks it.
The specification is the part of the system that can be read before it can be run. If a build agent and a curious member read this document and come away disagreeing about what the system is, the document has failed principle 02, and the fix begins here, not in the code.