The Daybook

What this is, and what it is not

The Daybook is the surface where a member's lived activity enters the cooperative's record. It captures four kinds of entry, holds each one in an open, ripening state until a person decides to land it, and renders the settled result as a rhythm: a bloom of the hours at which the cooperative tends to do each kind of thing.

It is not a new book of record. The authoritative ledger already holds contributions, allocations, and settlements as economic events under the existing modules. The Daybook adds three things to that ledger and nothing else: one new entity for narrative that never touches the books, one lifecycle for the interval between a thing happening and its becoming an immutable event, and one derived lens onto both. Everything economic it shows is a view of events the CIS already defines.

The reason it earns a module rather than living as a screen is that the interval it governs, the ripening, and the entity it adds, reflection, are genuinely absent from the current specification. Naming them as a module keeps the addition legible and bounded, which is the same logic by which the thirteen cooperative modules were drawn: a map of the capabilities the bylaws demand, not the territory itself (CIS PRD §08).

Where it sits: the four kinds, and what each one composes

Three of the four kinds are capture-points and views onto economic events the CIS already holds. The fourth, reflection, is the one new thing. Read across the table, the boundary it draws is the patron line in miniature: reflection sits outside the books, the other three inside them.

The value vocabulary the four kinds express is the proposed Program Stack: HOURS, REVENUE, CASH, OUTPUT, PRESENCE, PROPERTY. The Daybook does not invent a new taxonomy of value; it gives the existing one a daily-rhythm surface. That mapping inherits a status, however. The Program Stack Patronage Plan is a board recommendation pending ratification, not adopted policy, so the column above is proposed rather than settled proposed.

one state, three faces

In the CIS frame of one authoritative state with three views (CIS PRD §05), the Daybook is primarily a member-portal surface. It writes to the authoritative ledger only at the moment of landing. It leans on Nou, the agent surface, for preparation: drafting a reflection, confirming a reading, assembling a contribution for posting. It never lets Nou land anything. The work it does is to move a thing from a member's life into the book, and to keep that move in the member's hands.

Information model: what the schema gains

Two new tables and one new derived view. Each names the authority that governs it, in the cooperative's cite-as-you-enforce discipline, where every table and access rule carries the clause that justifies it (CIS PRD §06).

the emission rule

When a person lands an entry, the daybook_entries row does one of two things by kind. A reflection persists as its terminal record in reflections and emits nothing to the ledger. A contribution, exchange, or clearing emits the corresponding economic event into the existing tables, and the daybook_entries row seals as the provenance of that event: the place a later auditor reads to see how the event was composed and who landed it.

Conservation, multi-sig, and the existing treasury controls apply to the emitted event exactly as they would to one entered directly. The Daybook adds a capture path, not an exemption. What enters a balance must leave another, and the schema enforces that before any petal renders (CIS PRD §02, principle 05).

the rhythm view as legibility

The bloom is the legibility-is-product principle turned on a member's own day and on the cooperative's public rhythm. It answers when and how often, and is built so it cannot answer what. That property is structural, not a matter of restraint: the view selects timing and kind columns and never the content column.

The ripening lifecycle: the heart of the module

Every entry moves through a small state machine: composing, then ripening, then ready, then landed and sealed. A member may withdraw an entry from any state before landing, and a withdrawn entry leaves no economic trace.

ripeness is derived, not stored

This is a recommended change from the working prototype, where the fill is a stored number. Each kind carries a typed set of preconditions defined by its governing clause. Ripeness is the fraction of those preconditions met, computed on read. The change matters because it keeps the signal honest: the fill becomes auditable, it cannot be inflated by hand, and a member can always see which preconditions remain. It is the audit-by-design principle applied to a member's own pending work (CIS PRD §02, principle 09).

the four kinds and their preconditions

the load-bearing rule

Identity, access, and one deliberate departure

For its economic kinds the Daybook inherits the CIS access model unchanged. A contribution, exchange, or clearing entry is visible to exactly whoever may see the event it emits, no more and no less (CIS PRD §07).

The departure is reflection. The house default is democratic-by-default: disclosure to members unless a bylaw reason restricts it. A journaling surface cannot carry that default. A reflection is private to its author from the moment it is written, and becomes visible to others only by the author's explicit act of making it public. This inverts the house default for one entity, and it should be ratified as such, with a note under §18.2 recording the reason: narrative self-observation is humane only when the member controls its disclosure.

Two consequences follow and are worth stating plainly. A member's own reflections are theirs to export, and are append-only rather than silently deletable, which is the censorship-resistance posture applied to a person's own record. And Nou, when a member invokes it, can read that member's private reflections but can disclose them to no one, since it inherits the member's permissions and never more.

CROPS for the Daybook

The four properties of the design discipline, read at the level of this module. Privacy is the load-bearing one here, and augmentation is the property the module demonstrates more plainly than any other surface, because its central rule is enforced in code rather than promised in prose.

The cross-cutting property is augmentation. The whole module is the clearest place the cooperative can show principle 01 at work, because the human-landing rule is structural. A member reading their own Daybook can see that nothing economic was written without a person putting their name to it at the moment of commit.

Nou's part

Nou may draft a reflection from a member's notes, assemble a contribution from logged hours and present it for the member's read-and-confirm, surface a ripening entry that is close to ready, show which preconditions remain, and cite the clause that governs each entry. It may not land anything. It cannot post a contribution, record an allocation, or settle a clearing on its own, and it cannot make a reflection public. It prepares; the member lands.

Every preparation is logged with its prompt, its citation set, and its response, so the cooperative can audit its own augmentation layer, under the retention and redaction policy of the privacy pathway (CIS PRD §11). This is the standard Nou constraint applied here without exception: it inherits the permissions of the user who invokes it, never more, and it never takes authoritative action on its own.

Interface

This specification is a document, and follows document grammar: a single reading column, continuous, in the parchment-and-ink v4 system. The member surface it specifies is an instrument, and follows instrument grammar: a heads-up surface, widescreen, with the rhythm at its center. The working prototype of that surface is the shared Daybook artifact; this PRD is its written counterpart, not a replacement for it.

The surface has three elements. The bloom is the rhythm lens: two petal layers, the settled and the ripening, on a diurnal clock where each petal wears the colour of the hour it tends to happen. The matter is an open entry's detail: its face, what it awaits, its citation, its ripeness, and its landing action. The composer is where a member makes an entry, choosing its kind. The rule that the petals say when and how often but never what holds in the interface exactly as it holds in the view beneath it.

The surface follows the v4 grammar in full: Libre Baskerville for the human voice and IBM Plex Mono for the system voice, blue for reader action and selection, ember for cooperative marks and provenance, the sunset range reserved for the hours, and a light and dark toggle that remembers a member's choice and respects a reduced-motion preference.

Status, and the questions still open

This is a proposed module. Nothing in it is adopted. It depends on the CIS PRD v0.2, which is itself a draft, and on the Program Stack Patronage Plan, which is a board recommendation pending ratification. The mapping of kinds to Primitives inherits that pending status. The honest read of every claim above is: this is the shape the module would take, offered for ratification or redirection, not a description of a thing that exists.