Maker Fills, Builder Builds

Decision

A Maker fills in fields and does nothing else. Everything a Builder constructs — the prose, the arrangement, the modules, the headers — is closed to a Maker, and there is no per-block switch that opens it. Owner ruling 2026-09-11, in two sittings, from the Access menu's "Prevent Maker editing" item:

what if the rule is that in Maker the Maker role can only fill in fields and everything else is auto locked. Builder constructs. Maker fills out. … Best maker is limited to filling out forms.

and, on whether a Builder should be able to open a block to a Maker:

i don't think we need allow maker editing or prevent maker editing. let's start with the rule that Maker does not edit. we can keep reader view for now.

In plain terms: the Builder drafts the precedent; the Maker completes the blanks. The Maker never gets a pen on the clauses. If a clause needs the Maker's own words, the Builder puts a field there.

1. Maker's one write is the field value. write-data now means write-field-values and the things that only make sense while filling in: answering Goldie, correcting a value in line, and Save Version. It no longer means editing a content block's prose, moving, duplicating, removing, deleting or putting back a block, or changing numbering. Those are arrangement and drafting; they follow write-structure.
2. The per-block lock is removed, not inverted. There is no Prevent Maker editing and no Allow Maker editing: the rule itself closes every block, so a switch that closes or opens one block has nothing to do. The write-lock operation, the padlock menu item, the locked fact in the operation resolver and the stored exclusion list access.locked_for all go. A block that needs the Maker's own words gets a field, which is the one thing a Maker writes. A free-text schedule is a data block with a long-text field, not an opened content block.
3. A Module's lock goes with it; the Document-tier hard stop stays. The question GB-158 asks — does a Module's lock reach the Blocks inside it — is moot: there is no lock. The Document-tier access.locked that strips every write capability is a different mechanism (an administrative hard stop on the whole document) and is unchanged.
4. A Maker sees the paper, plus the Document's own card. No module cards, no header rows, no kind mark on any block, no block spine that opens a menu, no add rows, no fold arrows. The owner's words: "a maker does not need the mark glyph on each block. that is the chrome. but they still need access to the Document chrome in order to print or share the document", and, correcting a first cut that had moved the door to the Work Bar: "Maker should be seeing the top card in the paper for Document otherwise they have no way to export and download the document. that was supposed to be retained." So the document's cover sheet is drawn for a Maker, which amends Tinted Chrome, White Paper ruling 4 (a Maker sees the document card; a Reader still does not). On a Maker's card the name is read-only, the guide is read-only, there is no Goldie trigger and no Add module, and the mark's menu offers what the catalogue gives write-data: Save Version and Export today, and Share when it arrives (owner, 2026-09-11: "Maker will also get Share in the menu when that arrives") — the rows that file or hand the document on, never one that constructs. Everything on a block or module stays Builder chrome, extending the 2026-08-21 ruling from headers to every control on a block. A Maker's canvas is a Reader's canvas plus editable fields, Goldie and that one card. Hiding blocks or modules from a Maker (hidden_for) is a separate switch and is unchanged.
5. Reader stays on the ladder and stays unbuilt. The owner asked whether Reader is needed at all. It stays as a capability row — read, comment, no agent — because a counterparty lawyer or a beneficiary should read a live document without a pen and without the platform paying for inference on their behalf. Nothing further is built for it; the spine hover ruling of 2026-09-06 is the whole of its current UI. The owner's second sitting confirmed it: "we can keep reader view for now".
6. Export is the read-only copy for everyone outside the system. A person who is neither Builder nor Maker nor Reader receives the export, and Share, once built, is how a Maker hands it on from the same menu. An export is a snapshot: it cannot be commented on and cannot be recalled, which is why it does not replace Reader.
7. The three roles' names are not settled by this ruling. The owner asked the same day whether Creator and User would be better names than Builder and Maker. That question is filed as a proposed owner decision in backlog/decisions/ and is not decided here. Capability names (write-data, write-structure) do not change whatever the roles are called.

Why

• The lock was a patch over the wrong default. Under the 2026-07-25 position a Maker could work the prose of any block, and the Builder closed blocks one at a time. Authoring real templates showed the opposite shape: every clause of a will or an agreement is load-bearing, and the places where a Maker's own words belong are fields. Once the default is "closed", a per-block switch is a second rule for a case the first rule already handles. The 2026-07-25 callout said as much: "Maker is provisional … per-block locking is expected to revise" the Maker contract. This is that revision, and it revises the lock out.
• Two roles is simpler to explain and to test. Builder constructs; Maker fills out. Every "can a Maker do X?" question now has one answer — only if X is a field value. The editing access matrix shrinks from a cell per operation and lock state to one row per role.
• It matches how the document is used. A Maker on a platform-owned document is the consumer; the structure is the platform's. A Maker on a firm's precedent is the client; the structure is the firm's. In neither case is rearranging clauses the Maker's job.

Landed

GB-230 landed the ruling on 2026-09-11, the day it was made:

• The operation catalogue names write-structure on every row of every kind except write-field-values and save-version — the Document's own name, copy and lifecycle included, since a Maker's document card is a door to Export, not a set of verbs.
• The write-lock row, the resolver's locked fact, the padlock menu item, the About card's locked_for member and every Convex writer of access.locked_for are gone. The column stays declared so older rows still validate; the narrowing that drops it is a separate change with a migration, per the widen-migrate-narrow rule.
• A Maker's canvas draws no header row, kind mark, drag grip, add row or block menu on any block or module; the document's cover sheet is drawn with a read-only name and guide, no Goldie trigger, and a mark menu of Save Version and Export.
• The live route still passes no role, so every live visitor is a Builder until the access record (GB-14) lands; the default is recorded at that one seam.

Consequences

• Permissions and Visibility carries the amended capability table and the superseded 2026-07-25 positions, marked as such rather than deleted.
• Access Metadata still lists an "authored structural lock" among its open questions; ruling 2 answers it: there is none. Only the Document-tier administrative hard stop remains open there.
• Access Metadata drops "works the document's own content" from write-data.
• Folio Operations Resolve Once is unchanged: the rule still resolves in one place; only the capability each row names moves.
• The Maker-mode Goldie of GB-93 (collects values, never touches structure) is exactly a Maker under this ruling; nothing there changes.