Internal Publishing
A Proposed Module PRD and Specification

This is a proposal, and it should read like one. It sits in the series where PATRONAGE, TREASURY, and AGY sit: a module document, drafted before any piece enters the ledger, adopted only by merge, binding nothing until then. Where it uses the language of specification, that precision is in service of discussion. Every should below is offered and any of them can be argued down.

One thing it is not: a governance surface. Nothing published under this module binds anyone, decides anything, or speaks for the cooperative. A member's entry is that member's writing, and the module's first duty is to make that unmistakable on the surface itself.

Four kinds of published surface already stand, and the proposal is a fifth. The public journal at /journal/ carries field notes in one voice, signed by the record-keeper, explicitly non-governing, and readable by anyone. The Almanac at /commons/build/ carries pieces of work, one row each, its status marks carried in the ledger and its counts written by the validator. The authored documents beside it, the launch reading and the verification walk, are about the build rather than of it. The members' record at /intranet/record/ shows the cooperative's own acts to those signed in.

What has no home is the thing a member writes that is neither a field note in the house voice, nor a piece of work, nor an act of the cooperative: an argument, a reading, a piece of thinking offered to the membership under the member's own name. That is what this module would carry, and stating what it is not belongs on the surface rather than in this document, because a member who opens an internally published essay must not be able to mistake it for an instrument.

An Entry is a piece of writing by one member, under that member's name, with a title, a body, and a standing. A Reading is a named peer's recorded act of having read an entry and found it fit to publish under its author's name. A Standing is where an entry has got to, carried by events and never by a field that someone edits. The Register is the generated list of entries, which sits beside the Almanac and is not part of it, because an entry is a publication and a piece is a unit of work, and conflating them would corrupt both counts.

The whole design turns on this and it should be settled before anything else is argued. A peer who reads an entry attests to two things: that they read it, and that it is fit to be published under its author's name. They do not attest that it is right, that they agree with it, or that the cooperative holds its position. A reviewer who disagrees with an entry entirely may still record a reading, and should.

This is what keeps the module from becoming a censor. A review that gates truth turns the reviewers into an editorial board with power over what members may say to each other, which is a governance function nobody has granted and this document does not propose. A review that attests to a reading gives an author a guarantee they cannot get alone, that someone competent has actually read the thing before it stands, and gives a reader the same guarantee in reverse. The sentence belongs printed in plain words on the reading form, not buried in a specification.

An entry is drafted while its author is writing it and only its author can see it. It moves to in reading when its author submits it, which is the act that makes it visible to the readers named on it. It moves to published when the readings required by the instrument have been recorded, or to withdrawn at any point by its author, which is a right the author never loses. Withdrawal hides the entry from the register and destroys nothing.

Every move lands as an event, per Law II. The standing is derived from those events rather than stored as a mutable field, so the question of what an entry's standing was on a given date is answerable, which is the same discipline the rest of the record already keeps.

Publishing writes an event; it does not stamp a row and move on. A revision after publication is a new version carrying its own events and its own readings, and the earlier version remains readable with the readings it actually had. What was published, when, and who read it first survives every later edit.

This costs a little complexity and buys the one thing an internal publication is for. An entry that can be silently rewritten after its readers signed off is worth less than an unread draft, because it carries a warrant that no longer describes the text under it.

The count required to publish is a value the instrument carries and the surface reads from the record, in the same way the tally reads its parameters from the counting rules rather than from any number in a source file. The drafter's cut, offered for argument, is two.

Readers are named rather than queued. An author invites them, and a steward may assign one where an author asks for help finding a reader. Nothing here proposes an automatic assignment: a reading is a relationship between two members, and the system's job is to record it, not to allocate it.

These block the schema rather than the design, and they are the same class as the extended Program question parked since launch day, for the same reason: each sets a visibility function, and an instrument that guesses at a visibility function is an instrument teaching the record to lie.

A schema change: entries, versions, and readings, with the verbs that move standing, and the policies over all of them. That means a migration and a policy pass, and given the P-08 findings closed in the live record on 2026-08-17, an audit of the applied policies for any new member-writable table is not optional. That audit, not the surfaces, is the majority of the honest work.

The surfaces are three: a writing and submitting surface in the intranet, a reading surface for a named peer, and the register. The register is generated from the record in the same manner as the Almanac's counts, never hand-kept, so that it cannot drift from what the record says.

The graft, anticipated on adoption and not before, would be a bed of pieces in the ledger with the module yielding, anticipated, 000N_publishing_verbs.sql. No address is minted by this document. Minting is an act of adoption and adoption is the merge.

The questions in §8 block the stored system. They do not block the practice, and the practice is the part nobody has tested. A member writes an entry, sends it to two people, and records what comes back by hand. If it turns out to be worth having, the software is a migration and this document is its specification. If it turns out that nobody wants to be read before they speak, the cooperative has lost a file and no schema.

There is a candidate already: the steward's own working note of 2026-08-19 on the naming of a foundation, which is an entry in everything but standing. Authored, signed, dated, non-governing, and wanting a reader. Beginning there would also answer a question this document is careful not to assume, which is whether members want their thinking published to each other at all, or whether the wish for it belongs mostly to the person who asked for the system.

This document proposes a shape and nothing more. It opens no surface, applies no migration, and changes no deployed policy. It mints no address and adds no piece to the ledger; the graft enters on adoption or not at all. It does not decide who may publish, who may read, or whether a reading may be declined; those are routed in §8 with the drafter's cuts offered so that there is something specific to refuse. And it does not claim that the cooperative needs it. It claims that the cooperative keeps a careful register of its work and no register at all of its thinking, and that the second absence is worth a conversation.