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.4 carries the ten principles unchanged, retires an external design discipline whose funder context has ended, defines four launch capabilities in place of a phased calendar, and speaks the evolved register of Lexicon v2, Ground and Craft.
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 differed from version 0.2 by two removals and one addition. Removed: the sections that established an external design discipline as a bar on delivery, and the rule that a phase shipping below its target had shipped a regression. Added: four launch capabilities as the unit of scope, replacing the phased calendar. Version 0.4 differs from version 0.3 in register alone: the prose moves to the evolved vocabulary of Lexicon v2, Ground and Craft, and no address, status mark, or machine name is re-cut. 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 checked, 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 v0.3, CROPS is retired as a requirement and as a condition on delivery. 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 capabilities 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.3 §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 capability 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.
A ratification vote, whenever the members are admitted and it is called, 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 Almanac (ALM) after the four launch capabilities. Anticipated
The unit of scope is the capability: a coherent thing a member can do the day it lands, named identically on the public page and in the work plan. Capabilities replace phases. There are no dates below except the single date the cooperative already holds; readiness conditions do the sequencing, and a blocked capability wears the mark of what blocks it, by name.
Identity, membership, and agreement. The capability 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 capability 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 capability new at v0.3, 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 capability 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 capabilities, two 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 pieces sequenced 2026-07-22 as the T bed, 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 capability name, a module PRD, or pieces, and is the one scoped area with no trajectory yet in the Almanac. Open · governance naming and graft 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 tally over one ordered, append-only log of events: in the functional vocabulary, a deterministic fold. 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 tally 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 capability ships.
The acceptance criteria for each capability are its plain-language member sentences in §4: each sentence beginning a member can is a test, verified per the Verification Spec. Above the capabilities sit six system-level criteria, each of which can be checked rather than asserted.
The single proof the cooperative holds: Belong and Gather usable by members at the members' ratification gathering. Anticipated Amended 2026-09-03 (X-36): this sentence named August 14, 2026 as the ratification gathering. That day was the public launch and the board's first special meeting, recorded at /launch/; no member has been admitted and the ratification vote has not been scheduled.
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 piece 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.