Files
member-console/design/cooperative

Cooperative

Type: Domain Schema: cooperative Status: Early development — module structure defined; full accounting depth deferred to Issue 16 Tables: 2 Primary source: Decision 108; documents/doc-29-product-entitlement-rules-placement.md (boundary analysis) Decisions: 93, 95, 108

Purpose

The cooperative module answers the question: "What value has this member contributed, and how does that participation translate into cooperative governance?"

It is an observation layer on billing outcomes. It does not execute billing mechanics, generate invoices, or control resource access. A Temporal workflow triggered by payment settlement writes patronage events; the billing module continues executing whether or not the cooperative module is available. This decoupling is the defining architectural invariant.

The cooperative module exists because patronage attribution, cooperative identity, and the accounting operations required for 1099-PATR compliance and member equity management are governed by cooperative law and institutional policy -- not by commercial billing logic. Placing these concerns in the billing module created a category error: cooperative accounting is not a billing concern, it is a cooperative governance concern that observes billing outcomes.

This module is in early development. The two tables present (patrons, patronage_events) were extracted from the billing module (Decision 108). The full cooperative accounting depth -- patronage allocation, retained vs. distributed patronage, member equity accounts, fiscal year close, equity redemption -- is deferred to Issue 16 (Cooperative Accounting Depth).

Tables

Table Purpose
patrons Cooperative identity layer on billing accounts. Tracks membership and denormalized lifetime contribution totals.
patronage_events Append-only record of individual cooperative value contributions. Reactive observation on the payment pipeline.