visibility catalog · AM v0.1 · no agent invents a permission

Authority Map

The catalog of who may see and do what in the record, as a pure function of role, record class, and governing section, never as an administrator's toggle. Every policy below cites its anchor in the published governing instruments at techne.coop/legal. The document governs; the policy migration it emits distills, and flips the rls-audit suite from deny-all to the real matrix.

status · Drafted cites · Bylaws v2.1 (techne.coop/legal/bylaws) · Membership Agreement v2.3 · IM v0.1 · VS v1 absorbs · the C7 probe matrix · the RLS conventions emits · 0002_policies.sql RegenHub, LCA · Boulder · July 2026
§1

Preamble

This map is the document a build agent cites instead of inventing a permission, per Law V and BP v1 §4. It is drawn against the governing instruments as actually published: Bylaws v2.1 at techne.coop/legal/bylaws, the Membership Agreement v2.3, and the Community Supporter Agreement, with the Hub Membership Agreement under counsel review and the Investor rider Anticipated. It absorbs the estate's C7 probe matrix in shape, with roles and tables re-derived for the launch schema of IM v0.1, and the RLS conventions in discipline: every policy carries its anchor, and a policy without an anchor does not merge.

Status discrepancy, filedAM v0.1 §1a

The bylaws document at techne.coop/legal/bylaws declares itself v2.1, Ratified July 2026, effective July 2026. The legal index at techne.coop/legal, which states that it is the source of truth for document status, marks the bylaws v.2, Drafted. This map cannot resolve that conflict and does not try; it cites the v2.1 text, wears the question openly, and defers the mark's flip to the G-R gate of VS v1 §5, which requires re-verification of every anchor whenever the status changes hands. Until the index and the instrument agree, no surface downstream of this map displays Ratified. Open · Todd, with the legal page

One resolution arrived with the fetch and is recorded gladly: the open deficit-restoration question is answered in the instrument itself. Bylaws §5.3.4 provides a qualified income offset and §5.6 disclaims any obligation to restore a negative capital account, which reads as QIO without DRO. That constant moves from open to drafted-in-instrument, subject to CPA confirmation. Drafted · QIO per §5.3.4, §5.6; CPA to confirm

§2

The visibility function

What an agent may see is visible(agent, record) = f( role, record class, governing § ), structural rather than configured. The default runs toward disclosure to members, and the exceptions are carried by the instrument, not by preference.

The disclosure ground is concrete in v2.1. Any member may request the membership list, alphabetical with addresses, available electronically (§2.9). Every member receives the bylaws and their amendments (Art. XVI). The annual benefit report is posted publicly on the website (Art. XV). A member's own record travels with information rights under §18.1 and their own tax reporting under §6.2.1. These four anchors are why the directory, the agreements shelf, and the self-views exist as member defaults rather than privileges.

The restriction ground is equally concrete. The member record includes tax identification numbers where required (§1.13), and those never enter an application-level policy at all, per §4 below. Confidential information is defined and bound by §18.2. Deliberative records, board hearings under §1.8 and dispute proceedings under Art. XI, carry their own confidentiality. The function honors all three without a toggle anywhere.

§3

Classes and roles

Roles come in two kinds, and the map keeps them distinct: membership classes, which the bylaws define at §1.1, and appointments, which the bylaws create and the board grants. Role names follow the live reference: patron_member, director, steward, applicant.

§1.1(a), (b)Voting patronsCooperative Members and Coworking Members: patron members with one vote each (§1.4, §1.11, §2.6.1). The classes differ in patronage mode, not in visibility; the map treats both as patron_member with the class held on the membership row.
§1.1(c)Community ParticipantsMembers with access to programming and events, whose governance participation is as the Board determines. The map gives them the member defaults of §2 and marks the Board's determination as the hook it is. Open · Board policy hook
§1.1(d), §1.4.1Investor MembersNon-voting members of capital. Member defaults plus their own capital record; no vote unless also a patron. The rider that details their terms is Anticipated on the legal page, and their rows in this map harden with it.
§1.2, §1.3ApplicantsNot yet members: they see their own application, the instruments they would sign, and nothing else. Admission is a human act of the Board, simple majority (§1.3.1(e)), and membership takes effect per §1.3.3.
§3.1DirectorsThe Board manages the business; directors read membership records, applications before them, the stock ledger, and capital accounts, because §1.3, §1.8, §5.1.4, and §5.3 assign them the decisions those records serve.
§4.4, §4.5OfficersThe Treasurer holds custody of funds and accounts; the Secretary is custodian of records, the member register, and the stock transfer books. Officer grants follow the office, not the person.
§4.1, §1.13StewardThe operational role the live reference names: a Board-authorized agent handling intake, gatherings, and attendance. Its ground is the Board's authority to authorize agents and name a membership liaison; the delegating resolution itself is not yet in the record. Anticipated · Board resolution
Law X · NCThe instrumentNou appears nowhere in this map. It holds no role and no grant; it answers under scoped impersonation of the asking member, so an answer can never draw on more than that member could see themselves.
§4

Structural exceptions

Three kinds of record are restricted by structure, not by policy fine print, and no role below director-with-purpose reaches them.

§1.13Tax identifiersSocial security and tax identification numbers are kept for reporting and appear in no application table and no policy in this map. They live out of band, in the custody the Board authorizes, and the schema's launch tables simply have no column for them, which is the strongest policy there is.
§18.2Confidential informationRecords designated confidential, or that a reasonable person would understand as such, inherit §18.2 end to end. Surfaces inherit the restriction from the record; no view may widen it.
§1.8, Art. XIDeliberationsSuspension and termination proceedings and dispute records are visible to the parties and the Board, and to no one else, with Art. XI requiring confidentiality of dispute materials to the fullest extent possible.
§5

The matrix

The C7 shape, re-derived: the thirteen launch tables, and the profiles addendum of §9, against the map's roles, expectations sourced from this document and checked by the rls-audit suite. R is read, W is write, and every cell is scoped by the policies of §6; self means the row concerns the agent asking.

table public applicant member director officer steward
agentsselfR · self WRRR
agreementsRRRR · WR
membershipsselfRR · WRR · W
stock_ledgerselfRR · W
signaturesself Wself · self WRR
applicationsself · self WselfRRR · W
eventsself · scoped WRRR · W
gatheringsR · host WRRR · W
sessionsR · host WRRR · W
registrationsself · self W · host RRRR
attendanceself · host WRRR · W
opportunitiesR · author WRRR
responsesscoped R · self WRRR
profilesselfR · self WRRR

public reads nothing in the database: the public surface is the website, per Art. XV and the legal page, not an anonymous database role · responses are visible to the responder and the opportunity's author · the capital view folds only what the events policy already shows the asker · the profiles row (addendum, 2026-07-22, B-06) carries one guarded cell: email rides no client select and is served by profile_email() on the owner's visibility choice, to active members only

§6

The policies, by anchor

Each policy family, with the section that authorizes it. The emission carries the SQL; this register is the citation trail an auditor or an agent follows.

directoryMembers read agents and memberships: the membership list is a member right, alphabetical, electronic on request. Bylaws §2.9; §1.13 for the register itself.
agreements shelfMembers and applicants read the governing instruments; officers maintain them. Art. XVI distribution; §1.2.9 the duty to abide presumes the right to read.
own recordEvery agent reads what concerns them: their membership, signatures, applications, events, registrations, attendance, and the capital fold over their own events. §18.1; §6.2.1 for the tax view of self.
admission pathApplicants write their application and their signature; stewards manage intake; directors decide. §1.2, §1.3.1(d), (e), §1.3.3.
lifecycle writesMembership transitions are written by directors or the steward, with the automaton trigger enforcing legality and the acting human recorded, since §1.7 and §1.8 assign these acts to people and the Board.
stock custodyThe ledger of shares is read by its holder and the Board, written by the Secretary who keeps the transfer books. §1.11, §1.6, §4.5(e).
gather pathsMembers see the calendar and register or cancel for themselves; hosts and the steward record attendance, which serves quorum and the record of presence. §2.1, §2.7; PRD v0.3 §4.
find pathsMembers read open opportunities and write their own; responses are between responder and author until an outcome event says otherwise. PRD v0.3 §4; §18.2 for anything designated confidential.
capital viewsA member's fold is theirs; the Board and Treasurer read all, because allocation and custody are theirs to perform. §5.1, §5.3, §4.4.
profile cardMembers read one another's self-description; each agent writes only their own, and the email cell moves solely through the visibility function on the owner's word. Presentation state, not record: edits are not evented, by decision (B-06). §2.9, §1.13, §18.1.
§7

Write paths and the human actor

Reads are broad by design; writes are narrow by the same design. Every write that the bylaws assign to a person or the Board requires a recorded human actor, and no instrument holds a write grant of its own.

The acts that belong to people, with their anchors: admission by Board vote (§1.3.1(e)); withdrawal by the member's own notice (§1.7.1); suspension and termination by Board process with notice and hearing (§1.8); signatures by the signer (§1.3.1(d), §2.8); gate attestations by organizers (VS v1 §6). Each lands in the record as an event whose actor_agent_id is a person, per Laws VI and X, and the substrate's lifecycle trigger refuses any transition the automaton does not permit regardless of who asks.

Build agents write only through the repository under BP v1; the runtime instrument writes nothing, drafts everything, and reads as the member it serves. The service paths that maintain derived structures run as definer functions owned by the schema, which is a custody arrangement, not a role.

§8

Re-verification, and what moved

Reading v2.1 against the draft-era anchors carried in the estate found real movement, recorded here so the correction is chosen rather than slipped.

The vote anchors moved: the old mapping cited §1.6 and §1.14 for votes, which in v2.1 govern transfer restrictions and certificates; voting now grounds in §1.4, §1.11, §1.12.2, and §2.6. The membership anchors held (§1.1 to 1.4), as did capital accounts (§5.1) and notices (§2.4, Art. X). Attendance's old anchor §2.7 now reads as quorum, which is the purpose attendance serves, so the citation stands with its meaning sharpened. The IM v0.1 emission's comments remain accurate under this re-reading; the estate documents that cite the moved vote anchors are corrected at the reconciliation merge.

The standing duty: at G-R, or whenever the legal index and the instrument agree on a status flip per §1a, every anchor in this map and in the schema comments is re-verified against the governing text, and the map's own mark changes only through that gate.

§9

The emission, and two additions carried openly

The migration 0002_policies.sql distills this map: the helper functions, every policy with its anchor within reach of the schema-lint, and the grants that make deny-by-default become the matrix of §5. Applying it flips the rls-audit suite live.

Two schema additions ride in the emission because the map cannot function without them, and both are flagged as IM addenda rather than slipped in: an identity binding on agents (auth_user_id), since the visibility function must know who is asking, and a role_grants table for appointments (director, officer, steward), since classes live on memberships but offices do not. Both are Tier B changes under BP v1 §6, recorded here for adoption into IM v0.2. Open · IM v0.2 addenda, Todd's nod

A third addendum joins them by the steward's direction of 2026-07-22 (B-06): a profiles table, the self-description satellite of agents, emitted by 0009_profiles.sql with its matrix row in §5 and its policy family in §6. Two of its choices are carried openly: profile edits are presentation state and are not evented, and the profile view declares no crafts, inferring practice from the record instead (and, when the Share train opens, from contributions and patronage activity). Its avatars ride a private storage shelf under the same self-write, member-read cells. Tier B, recorded for adoption into IM v0.2.

Deferred with their instruments: Investor-rider specifics, the Community Participant governance hook, the Hub Membership Agreement's Class Two and Three terms, and every post-launch table family. Amendments to this map are Tier B at the policy level and Tier C at the document level, prospective, with supersession explicit.

the working agreement of this map

Authority here is cited, time-bound, and event-based, never assumed. When a needed permission has no row in this map, the answer is an escalation card and, if warranted, an amendment with an anchor, because the alternative, a permission that exists only in code, is exactly the unexplained boundary the fourth principle forbids.