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 terms of the Ground, 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.4 is the system specification: it names See your share as Capability 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 capability as much as the Share capability, and §4 and §8 describe that bridge.

One boundary is proposed before anything else. PRD v0.4 places treasury execution, distributions and multi-signature authorization, outside the launch capabilities, 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 Ground 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 Tally 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, an adopted 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 tally, exactly as every other derived fact in the system is. If read-time tallying ever proves heavy in practice, the alternative is a nullable program reference on the opportunities table, which is a schema change and therefore a stop card; 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",
  "election":            "counted",  -- COUNTING-RULES v2 §3; required, no default; a contribution is counted by election, never by silence
  "standing_charge_id":  uuid?,   -- present where HOURS posts against a charge rather than an Opportunity (§7)
  "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
}

The given election terminates elsewhere, and it needs its own contract because it asserts less. A Recognition names the member, describes the work, and quantifies it in whatever unit the work naturally has, hours or units or occurrences, without converting that quantity into money. It carries no rate basis and no policy version that valued it, because nothing valued it. Its deltas are zero, and they are zero for a reason the §9 tally depends on: a Recognition is not a Contribution priced at nothing, it is a contribution the member declined to price.

-- proposed payload contract · patronage.recognition
{
  "program_agent_id":    uuid?,   -- where the work sat under a Program; absent where it did not
  "election":            "given",   -- the only admissible value on this kind
  "description":         text,    -- what was done, in words, since no code prices it
  "quantity":            numeric?, -- the natural unit only
  "quantity_unit":       text?,   -- hours, units, occurrences; never a currency
  "claim_event_id":      uuid,    -- the given claim this attests
  "documentation_ref":   uri?,
  "opportunity_id":      uuid?
}

On the row itself, agent_id is the member recognized and valuation_approver_agent_id holds the attesting hand, exactly as on a Contribution, so a Recognition is no easier to enter than a Contribution and no member enters their own. What differs is valuation_method, which is none, and book_delta and tax_delta, which are zero. No rate_basis and no policy_agreement_id appear, because a field that would have to be null is better absent than false.

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.⁴

The distinct hand extends in two directions that v0.3 did not contemplate. A Recognition has no value to approve, and it is still approved: the confirming hand attests attribution and occurrence, that the work described happened and that it is the member's, which is the whole of what a Recognition asserts. The verb therefore applies the same segregation test to a given claim as to a counted one, and refuses a member attesting their own, even though nothing is being priced. And where HOURS posts against a standing charge rather than an Opportunity, the confirmer is not the Program's Coordinator by inference but the hand the board's resolution names, and that hand is never the charge's holder. Where the holder is an officer, the confirmer sits outside that office, so the secretary does not confirm the secretary's charge and the treasurer does not confirm the treasurer's. The cooperative presently has one steward carrying most of the continuous work, which makes this a protection for that steward before it is a protection for anyone else.

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.

A standing charge is configuration in exactly the sense this section means. It is a board act with a version and an effective date, it names numbers and hands the mechanism must not invent, and the posting verb reads it from the record at valuation time rather than holding any part of it in code. The verb asks whether a charge was in force at the hour's occurrence, which tier that charge set, and which hand it named to confirm; a charge that lapses stops admitting hours from its lapse forward, and hours already posted under it stay computable under the version that governed them. The only structural difference from a rate is what the charge substitutes for: it satisfies the affiliation requirement that a resolved Opportunity otherwise supplies, so an hour under a charge still cites something adopted and still cites something that is not the contributor's own assertion.

This narrows an open question v0.3 left whole. The Default Policy's scope of unattributed activity was doing two jobs at once: it stood for continuous cross-program work that belongs to no Program, and it stood for episodic work that simply has no Program behind it. Standing charges answer the first, and answer it better than the Default Policy could, because they name a confirmer and a tier by resolution rather than leaving the mechanism to guess. What remains open is the second, the ordinary unaffiliated hour, and one thing more: whether a Program-less contribution posts to the cooperative agent under the Default Policy, or is inadmissible until some Program or charge claims it. That question is unchanged by COUNTING-RULES v2 and stays where it was.

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 tally 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 tally and a tax tally 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 capability sentence in PRD v0.4 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 tally does not read Recognitions, and that is the correct behavior rather than a gap in it. capital_accounts sums deltas over capital events; a Recognition is not a capital event and carries no deltas, so it contributes nothing to a balance and could not be made to without contradicting what the member elected. The member surface would show Recognitions all the same, in the itemized history, marked as given and carrying their description and their natural quantity, with no money column and no line into the balance pair above. That is the honest rendering: the history is what the member did, and the tally is what the cooperative owes against it, and those were never the same list. Anyone reading the surface should be able to see at a glance that a given line is deliberately not summed, which is the interface's whole obligation here.

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 capability 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.

Capability 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 given election takes the same two-hand shape, and it should, because the reason for two hands does not go away when the money does. submit_claim carries the election, counted or given, and writes the deltaless patronage.claim either way; the verb refuses a claim that states neither, since silence is not an election and the mechanism must not choose on the contributor's behalf. From there the paths part. A counted claim goes to promote_claim, which values it and writes the capital.contribution. A given claim goes to attest_recognition, which confirms attribution and occurrence, sets valuation_method to none, and writes one patronage.recognition referencing the claim, with both deltas zero. The same segregation test guards both verbs: the attesting hand must differ from the member, and under a standing charge it must be the hand the charge names. Because the election is irrevocable for that contribution, neither verb accepts a claim the other has already consumed, and a member who wishes they had elected differently has the same remedy anyone has here, which is to say so and let the board decide, not to have the verb quietly reverse it. HOURS under a standing charge reaches either verb: post_contribution and submit_claim take the charge in place of the Opportunity, and the version-in-force read at §7 supplies the tier and the confirmer.

The allocation run is a verb sequence in the order the Plan fixes: open_run cuts the tally; 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.4 sequences after the launch capabilities, 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 almanac 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 tally 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 almanac ledger and the build dashboard currently describe different pieces 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 tally surface. Read against this proposal, the divergence resolves as an under-decomposition rather than a contradiction; the union is the bed. And the Programs view, being a Find capability unblocked by Q3, is offered as a Find piece rather than a Share one, with the placement itself open: if it reads better inside the Share bed as its opening piece, the entries renumber and nothing else changes.

# proposed graft · one Find piece, three Share pieces, the proof 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 tally, citing its policy version.

- address: S-02
  title: The tally 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 graft
  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 proof ceremony prefers not to wait for a fiscal close; that choice belongs to the Proof 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. Version 0.4 adds mechanism for the given election and for standing charges and admits neither: no member has elected anything, no charge is in force, no confirmer has been named, and if the board declines COUNTING-RULES v2 the patronage.recognition kind is simply never written. It does not build the treasury module or move any money. It does not merge its own graft, 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.