Program Patronage
A Proposed Module PRD and Specification

This is a proposal, and it should read like one. The Program Stack Patronage Plan is itself a draft before the board, traveling with reviewer checkpoints for counsel, the CPA, and the directors; nothing it proposes is settled.¹ This document sits one layer down and inherits that posture entirely: it sketches the module that would enable the program stack if and when the Plan adopts, in the substrate terms of the CIS as actually built. Where it uses the language of specification, kinds, payloads, verbs, that precision is in service of discussion, not in place of it. Every should below is offered; any of them can be argued down.

Three instruments meet here and none replaces another. The Plan is board policy in the making: the six Primitives, the archetypes, the Labor Schedule, the Default Policy, the year-end sequence. CIS PRD v0.3 is the system specification: it names See your share as Slice 04, read-only at first, blocked by the counting rules, and holds the ten principles that bind every module.² This proposal is the joint between them, and, in v0.2, it also reaches sideways: Programs, internal to the LCA, are organizing bodies for the Opportunities surfaced in the commons, so the module touches the Find slice as much as the Share slice, and §4 and §8 describe that bridge.

One boundary is proposed before anything else. PRD v0.3 places treasury execution, distributions and multi-signature authorization, outside the launch slices, sequenced later under a name not yet settled.² This module would therefore record value and allocation as events and never move money; where the Plan's year-end sequence reaches cash, the module writes the commitment record and stops. And like everything in the series, the document observes Law X: the instrument drafts, surfaces, and proposes; deciding, signing, and governing sit with people. Nou holds no role and no grant in the deployed policy set, and nothing below would change that.⁵

The Plan's Section 9 claims that nothing in it requires modification to the underlying event log model. Read against the applied migrations, the claim holds.³ The events table already carries every field Section 9 asks for, most as named columns rather than payload conventions:

Four further findings shape the proposal. The agreements table is built for versioned instruments whose computations bind to the version in force, and its own comment anticipates a code named POLICY-PATRONAGE, so policy configuration has a first-class home.³ The write policy on events admits members only to signature, registration, opportunity, and gathering kinds; every capital write is, by standing authority, a definer function or an overseer act, which is the write discipline this proposal adopts rather than invents.⁴ The appointment enum in role_grants is closed at director, secretary, treasurer, steward; there is no Coordinator office, and §6 argues none should be added. And the opportunities table carries an author, a kind, a lifecycle, and no Program reference at all, which §4 treats not as a gap but as the shape Law II expects: an affiliation is a relationship, and every relationship is an event.³

What the substrate does not yet hold, this proposal declares rather than migrates: the affiliation and payload contracts (§4, §5), the configuration convention (§7), and the write verbs (§10). The schema is untouched.

The Plan's defined terms carry into this proposal unchanged and capitalized as there: Program, Contribution, Primitive, Capital Account Credit, Coordinator, Patron Class.¹ The six Primitives are HOURS, REVENUE, CASH, OUTPUT, PRESENCE, PROPERTY, a closed set under board authority. To these, v0.2 adds the relationship Todd named as the module's internal ground: a Program is an organizing body for Opportunities surfaced in the commons. An Affiliation is the recorded relationship between one Opportunity and one Program; it is optional, since not every Opportunity has a Program behind it. A Posting Path is a verb sequence that ends in a capital event; a Valued Event is a row in events whose kind begins capital. and whose deltas are set; the Fold is the capital_accounts view; an Allocation Run is the recorded execution of the Plan's year-end sequence.

Vocabulary discipline holds throughout: this is Subchapter K machinery, so balances are 704(b) capital accounts, year-end results are distributive shares, and the retired Subchapter T terms do not appear. Patronage survives as it survives in the Plan's own name, a correctly scoped internal term for the contribution-counting layer, never a tax characterization.

The opportunity board is where engagement begins: play, practice, and work, posted by members, responded to between responder and author, resolved as events. Programs give some of that activity an organizing body: a purpose, a Coordinator, a ratified way of recognizing what the work is worth. The proposal treats the relationship exactly as Todd framed it. Not every Opportunity has a related Program, and nothing forces one; an unaffiliated Opportunity is pure Find, and it stays that way. But an Opportunity can be affiliated with a Program, and once it is, engagement through it becomes eligible for patronage and other recognition under that Program's policy in force.

Because the opportunities table carries no Program column, and because Law II says every relationship is an event, the Affiliation is proposed as a recorded event rather than a schema change: kind opportunity.affiliated, concerning the Program agent, carrying the opportunity in its payload, written by the Coordinator or the author through the Program's own path. The board's view of an Opportunity's Program is then a read-time fold, exactly as every other derived fact in the system is. If read-time folding ever proves heavy in practice, the alternative is a nullable program reference on the opportunities table, which is a schema change and therefore an escalation; that road is named here so choosing it later is a decision, not a drift.

Eligibility flows from the Affiliation, not from the board itself. When an affiliated work or practice Opportunity resolves, its resolution can seed a patronage claim, HOURS or OUTPUT most naturally, referencing both the resolution and the policy version in force, and the claim walks the same verification path as any other (§10). Other recognition is deliberately left open: the Plan's PRESENCE Primitive covers recorded participation, and any non-capital acknowledgment the cooperative wants beyond that is a future policy question this proposal names without inventing.

The module would write these kinds and no others, each named noun-first in the house grammar, each allocation-sequence kind tied to the Plan step it records:

For capital.contribution the columns do their standing work: agent_id is the member, actor_agent_id the human recorder, valuation_approver_agent_id the Coordinator of record, occurred_at the contribution instant and recorded_at the posting instant, so the Plan's fourteen-day contemporaneity rule for HOURS is checkable from the row itself. Deltas follow Law VII, book and tax both, equal by default. The payload carries what the columns do not:

-- proposed payload contract · capital.contribution
{
  "program_agent_id":    uuid,   -- agents.kind = 'program'; Default Policy posts to the cooperative agent
  "primitive":           "HOURS" | "REVENUE" | "CASH" | "OUTPUT" | "PRESENCE" | "PROPERTY",
  "quantity":            numeric, -- hours, revenue usd, units, occurrences, fmv usd
  "rate_basis":          text,    -- labor_schedule tier code, revenue_pct, output unit code, presence_credit, documented_fmv
  "policy_agreement_id": uuid,    -- the version in force that valued it
  "documentation_ref":   uri,
  "claim_event_id":      uuid?,   -- present when promoted from a member claim
  "opportunity_id":      uuid?    -- present when the contribution flows from an affiliated Opportunity's resolution
}

Two pins would complete the contract. Every capital event posts on the entity book: a member's capital account is a relation to the cooperative, not to a hosted program arc, so Law IX's host book carries the program's operational happenings, and the Contribution credit those happenings earn lands entity-side referencing them. And the three status axes behave as everywhere else: provenance real unless a surface is explicitly simulated, settlement settled for posted contributions and anticipated for commitments awaiting the treasury module, temporal state never stored.

The Plan makes the Coordinator load-bearing: a member designated by the board to administer a Program's policy and verify its Contributions, who never approves their own.¹ The tempting implementation is a fifth value in the appointment enum. This proposal argues against it, and the argument is open: offices in role_grants are bylaws offices, per the Authority Map's own comment, and the Coordinator is not one. A Coordinator is a creature of a Program policy, board-designated when that policy adopts, scoped to that Program, ending when it sunsets.

So the designation would live where the Plan puts it: in the Program's policy instrument. Each Program policy is an agreements row, code POLICY-PATRONAGE-<program>, versioned and effective-dated, and its agreement.adopted event carries the machine-readable parameters, the coordinator among them (§7). The posting verbs enforce the segregation the Plan requires: the approver on a capital.contribution must equal the coordinator named by the version in force for that Program, and must differ from the member being credited. Cross-verification for a Coordinator's own contributions falls to the Financial Systems Committee's officers, which the deployed policy set already recognizes. Members read their own records at any time; that right is already the events read policy, capital included, under Bylaws §18.1 and §6.2.1.⁴

One visibility cell is genuinely missing, and §8 adds a second like it: the Coordinator's monthly view of their Program's activity, which the current read policy does not grant. Two honest routes exist, an additive read policy scoped by the program reference, which is Authority Map territory and belongs in an AM v0.2 addendum with its anchors stated, or definer functions that return the summaries without widening row access. This proposal suggests the second for launch, because it ships without touching the policy set, and names the first as the durable form. Both routes are gathered in §15 for one decision.

No rate, weight, or unit value would appear in any view, verb, or check. Every number the Plan proposes, the Labor Schedule tiers, the REVENUE percentage, the OUTPUT unit values, the PRESENCE credit, enters the system as an adopted instrument and is read from the record at valuation time, so a rate change is an amendment event and history stays computable under the version that governed it. Cite as you enforce, Law IV, applied to money.

The agreements table carries no payload column, deliberately; parameters travel in the adopting event's payload, the instrument row holds identity, version, and effective date, and the prior column preserves what a governed record changed from. Amendments are prospective only, as the Plan requires: a new version, a new adoption event, and the fold untouched behind it.

This is the surface v0.1 was missing, and it is key to the PRD. Programs are internal to the LCA, so their view belongs inside the commons portal at techne.coop/intranet, behind the auth gate, in two forms: a principal page of its own at /intranet/programs/, and a primary window on the intranet Overview beside the member's other principal windows, so exploring Programs is a first thing a signed-in participant sees, not a thing they hunt for. The page and the window read the same record; the window is the door, the page is the room.

What a participant finds there is the cooperative's organized life, arranged for engagement:

The visibility ground is mostly already laid: members read the full agent roster under Bylaws §2.9, every Opportunity under the Find policies, and every instrument row under Art. XVI and §1.2.9.⁴ Two cells are missing, and they are the same shape as §6's: affiliation events and adoption parameters live in the events table, which members read only where an event concerns them. Principle 07 is the anchor that closes both, democratic by default, any member sees what governs them, board policies accessible without friction.² The durable form is an AM v0.2 addendum granting member read on the opportunity and agreement namespaces; the launch form is the same definer-function route as §6. One decision covers all three cells, gathered in §15.

The capital_accounts view stays exactly what it is: one row per member, a book fold and a tax fold over capital events, running as the asker so it shows only what the events policy already shows.³ This proposal adds no stored balance anywhere and no second truth. The member surface at /intranet/share/ would render three things from the same record: the balance pair, the itemized history, which is the member's own capital events in order, and, on every line, the citation trail: the event id, the Program, the Primitive, the quantity and basis, and the policy instrument and version that valued it, with a line that flowed from an affiliated Opportunity linking back to it. The slice sentence in PRD v0.3 is the acceptance test written as prose: follow any figure to the events and the policy that produced it, and never hit an unexplained boundary.²

The three doors hold without addition. Browse is the Programs view of §8, /intranet/share/, and the Coordinator desk when the claim pen opens. Ask is the natural-language door over the identical record. Verify is the event log and the fourteen export views already deployed, which carry every kind this module would write without amendment; the rehearsed walkaway has already proven the fold reconstructs byte-identically, so the module inherits X-03 and X-09 and adds nothing to them. The map names the slice See your share and its door Your share, standing parked at /intranet/share/ since U-07; the Programs view takes its place in the intranet rather than the public nav, and whether it ever earns a nav position is a later, smaller question. amended 2026-07-27 · the address follows the built door

All capital writes would ride security definer verbs, the pattern the signature flow set when B-04 escalated and 0003 landed: one atomic function per act, the human actor validated against role_grants, refusal messages that cite the rule refused. The member insert policy on events is not widened for capital kinds; the verbs are the only doors.⁴ The affiliation verb is the one exception in spirit, since opportunity.* kinds are already member-actionable; it still lands as a verb so the Coordinator-or-author rule is enforced somewhere the interface cannot forget it.

Slice 04 is read-only at first, and the proposal phases the pen to match. In the first phase the overseer posts: post_contribution takes the member, the Program, the Primitive, the quantity, and the documentation reference, reads the version in force, computes the deltas, sets the approver, and writes one capital.contribution. In the second phase, opening per Program as its policy adopts, the member's own pen is a claim: submit_claim writes a patronage.claim, deltaless, optionally citing the affiliated Opportunity it flows from, and the Coordinator's promote_claim verifies it into a capital.contribution that references the claim, so self-report and verification are two events by two people and the fold counts only the second. Corrections are compensating events through the standing corrects reference; nothing is ever edited.

The allocation run is a verb sequence in the order the Plan fixes: open_run cuts the fold; record_pnl enters the reconciled figure; post_allocations computes each member's share by capital ratio at the cut and writes the capital.allocation rows, both deltas; record_patron_check attests the 51% floor under a director's hand; apply_qio redirects any deficit-creating loss; record_distribution and record_k1_issuance close the record. Determinism is a requirement, not a hope: given the cut instant and the P&L figure, the allocation rows are a pure function of the log, which is what makes the gate's hand-check possible.

The Plan's seven steps map one-to-one onto the §5 kinds and the §10 verbs, each a recorded event tied to the provision that authorizes it, none authored as a date. Steps 01 through 05 complete entirely inside this module. Steps 06 and 07 are where a missing sentence belongs, and here is the proposed wording: steps 06 and 07 record in this module as linked commitment events per Law VIII, and the movement of cash they describe executes only through the treasury module that PRD v0.3 sequences after the launch slices, so no allocation run in this module moves money, and no distribution timing can precede the qualified income offset check that step 05 records. Until the treasury module exists, capital.distribution rows carry settlement anticipated, the honest mark for a commitment the engine holds and the bank has not yet seen. The sentence is offered to the Plan's own Section 9 as the light amendment already flagged; it changes no step, only names the seam between recording and execution.

The Plan's implementation section phased by calendar, Default Policy in the first quarter and Program policies in the second. The roadmap grammar retired calendar phasing in favor of readiness conditions, and this proposal restates the same intent in that grammar. Notably, the Programs view does not wait for Q3: exploring Programs and their Opportunities is a Find capability, and it can open with Programs shown honestly as in formation before a single rate exists.

R2 repeats per Program indefinitely; that is the polymorphism the Plan promises, a closed Primitive set under an open Program set, and nothing in this module needs to change when the next Program adopts.

Each acceptance below is a sentence a person demonstrates or a probe the suites assert, in the Verification Spec's grammar:

1. A signed-in member opens the Programs view and finds every Program with its standing honestly marked, its affiliated open Opportunities beside it, and the unaffiliated shelf intact.
2. An Affiliation resolves to its event: from the board or the Programs view, the link between an Opportunity and its Program traces to the opportunity.affiliated row that made it.
3. A posted contribution appears in the member's fold and itemized history in the same read, with its event id, Program, Primitive, and policy version visible on the line, and its Opportunity linked where one seeded it.
4. Every figure on /intranet/share/ resolves to its events and its instrument; the Law IV probe walks one balance to its inputs and finds no unexplained boundary.
5. A verb refuses a Coordinator approving their own contribution, and the refusal cites the Plan's segregation rule; the probe matrix gains this cell.
6. Given a cut instant and a P&L figure, the allocation rows recomputed by hand equal the posted rows in both projections; the standing G-S sentence, unchanged: the fold shown equals the fold computed by hand.
7. The member allocation deltas for a run sum to the finalized net figure, a Law III conservation check the suites assert on every run.
8. The rehearsed walkaway continues to reconstruct the fold byte-identically with the new kinds present, which the weekly harness will demonstrate without being asked.

The roadmap ledger and the build dashboard currently describe different packets under S-01 and S-02: the ledger holds a capital account view and an allocation event, the dashboard holds contribution posting paths and a fold surface. Read against this proposal, the divergence resolves as an under-decomposition rather than a contradiction; the union is the train. And the Programs view, being a Find capability unblocked by Q3, is offered as a Find packet rather than a Share one, with the placement itself open: if it reads better inside the Share train as its opening packet, the entries renumber and nothing else changes.

# proposed splice · one Find packet, three Share packets, the gate unchanged
# adoption is the merge, and the merge is Todd's
- address: F-04
  title: The Programs view
  intent: Programs as organizing bodies for Opportunities; the principal page at /intranet/programs/ and the Overview primary window, per PP §8.
  status: open · PP adoption
  cites: [PP, PRD, AM, IM]
  ready_when: PP adopted. F-01 through F-03 verified. The §15 visibility decision recorded.
  deliverable: /intranet/programs/; the Overview window; the affiliation verb.
  acceptance: Explore every Program and its open Opportunities; trace one Affiliation to its event.

- address: S-01
  title: Contribution posting paths
  intent: The §10 verbs land; a valued Contribution posts with both deltas per Law VII.
  status: open · Q3
  cites: [PP, IM, AM, PRD]
  ready_when: G0 attested. Q3 counting rules recorded. PP adopted.
  deliverable: 000N_patronage_verbs.sql; the Labor Schedule and Counting Rules entered as instruments.
  acceptance: A contribution posted by verb appears in the poster's fold, citing its policy version.

- address: S-02
  title: The fold surface
  intent: /intranet/share/ shows the balance and the itemized history with traceable inputs per Law IV.
  status: open · Q3
  cites: [PP, IM, AM, PRD]
  ready_when: S-01 verified.
  deliverable: /intranet/share/ over capital_accounts and the member's own capital events.
  acceptance: Follow any figure to the events and the policy that produced it.

- address: S-03
  title: The allocation run
  intent: The Plan §7 sequence executes as recorded events, steps 01 through 05, with 06 and 07 as commitment records per PP §11.
  status: anticipated
  cites: [PP, IM, AM, PRD]
  ready_when: S-02 verified. Fiscal close. Q4 class semantics recorded.
  deliverable: The run's event trail; the patron-majority attestation under a director's hand.
  acceptance: Hand-computed allocation equals posted allocation, both projections.

- address: G-S   # unchanged in sentence; ready_when follows the splice
  ready_when: S-03 verified.

The first accounting year can reach G-S before a full year elapses by demonstrating S-03 on an illustrative run, provenance marked, if the gate ceremony prefers not to wait for a fiscal close; that choice belongs to the Gate Book, not to this proposal.

The Plan travels to the board with three reviewer sets, entity counsel, tax counsel or the partnership CPA, and the board itself, and those checkpoints carry forward here by reference and unaltered.¹ This proposal adds the mechanism-side items that surfaced in drafting, each routed to its person:

Nothing here is legal or tax advice; it is research shaped for the people who give that advice, in the standing division of labor.

This document proposes a shape and nothing more. It does not set a rate, a weight, or a unit value; those are the Plan's proposed defaults awaiting their reviewers. It does not write the Q3 resolution or presume its content beyond the fields §7 reserves for it. It does not designate a Program, name a Coordinator, or seat a steward. It does not build the treasury module or move any money. It does not merge its own splice, and it does not adopt itself. It is not board-mandated and it is not closed: it is a proposal drawn concretely enough that the board, counsel, the Financial Systems Committee, and the members have something specific to question, amend, or refuse, which is the only way a shape like this should ever harden into a system.