RULED 2026-08-28 — the version we're actually doing.
The full Block Law re-model on this page — two closed sets (SHOW blocks and ASK blocks) as a fresh contract — is NOT adopted. It is not needed. The system already enforces typed controls through the existing har_blocks / format model: every waiting-on-you step must carry blocks (REJ-22), each block is one typed control drawn from the format slugs, the offered control must match the step's ask (REJ-24), a choice must carry real options (REJ-25), a description is capped so it cannot smuggle a paragraph, and the render path strips markdown (the deadtext no-markdown guarantee). Free prose already cannot be an answer. Re-modelling that as a new two-closed-sets contract would break the agent contract and add rejection codes for a hole that is already closed everywhere except one spot.
That one spot: an agent could still author a binary or numeric question as a free-text box — the over-18 fill-in-the-blank, "how many guests" typed into a text field. So instead of a re-model we add exactly two formats — yes_no (a binary question, two fixed platform buttons, no agent options, exempt from the min-options rule; valid on CHOOSE and PROVIDE) and number (a numeric answer with a required config.unit and optional min/max; valid on PROVIDE) — plus an optional documentation-only config.reason on free-text blocks that names why a text box was the right control. Malformed number config reuses REJ-13; no new rejection codes, no contract break. That closes the last real hole and keeps "tap, don't type" true. The fleet and the paper cite this ONE design, not the abandoned re-model below, which is kept only as the record of what was considered.
Agents keep coming back inside a Human Access Request with a big wall of markdown: "here is everything we need to do to build your greenhouse..." - three paragraphs, a buried bullet list, a summary. The person did not open the app to read a document. They came to tap: have it, need it, yes, no, choose that one.
Prose is the path of least resistance for a language model. Left free, it will always write the essay. Asking politely in a system prompt does not hold, because the next model, the next agent, the next week, drifts back to prose. Instruction is a suggestion. A wall keeps arriving.
"You cannot prompt your way out of this. You have to make prose stop working."
- Steven, the core insight
When we wanted agents to declare odds on their bids, we did not ask nicely. We added REJ-16 and every bid that arrived without numbers bounced at the door. Within a day, 101 steps carried numbers. Enforcement worked where instruction never would. The Block Law is the same medicine: make the text wall fail to submit, and blocks become the only way through.
Everything an agent SHOWS a person is built from a closed set of typed blocks - the same way everything an agent may ASK is one of the four asks (approve / choose / provide / grant). Free prose is not a way to show information. It is a bug.
The block set, v1:
| Block | Cap | What it does | Status |
|---|---|---|---|
| CHECKLIST | up to 12 items, 80 chars each RULED | A list of things, each tappable have-it / need-it / skip-it. The greenhouse scrap list. | new HAR format (a new format slug; rides a PROVIDE/CHOOSE-family ask - it collects the have-it / need-it / skip answers back as structured data, and also displays) |
| CHOICE | 2 to 9 tiles | Pick one, one tap. | exists (the choose ask / single_choice) |
| STEPS | the numbered plan | Each step: time, line item, a "you approve" line. | exists (the proposal spine / DealStep) |
| KEY FACTS | up to 8 rows RULED | Label + value rows: price, timeline, what you own. | new |
| NEED | - | What the agent needs from the person. | exists (the provide ask) |
| NOTE | 280 chars MAX, one per filing RULED | Plain text. The ONLY place prose is allowed to live. | capped |
Three of the six blocks already exist as asks and render as real UI today. KEY FACTS is a new display-only block; CHECKLIST is a new HAR ask format (it joins the ask grammar, collecting have-it / need-it / skip answers back as structured data). NOTE is the single, tightly capped escape hatch for a human sentence.
RULED 2026-08-10 The caps are decided and locked: 12 checklist items x 80 chars, 8 key-fact rows, 280 note chars. No longer open - these are the numbers that hold the line, and every downstream figure on this page reads from them.
Our HAR system already types what an agent may ask: 23 format slugs across the four asks, and they already render as real UI (radios, dropdowns, file upload). CHECKLIST joins them as the 24th (see below):
single_choice, multiple_choice, rankreview_approve, confirm_correct, agreement, signaturegrant_access, connect_accountshort_answer, structured_form, file_upload, media_upload, date_time, location, schedule, and the restThey are validated at the door already: REJ-22 (a waiting-on-you step must carry a HAR), REJ-23 (a choose ask needs a minimum number of options), REJ-24 (the format must fit the ask), and a 400-char cap on the block description. The machinery to reject a badly shaped ask is live.
Our typed blocks govern what an agent ASKS. But the agent's OPERATIONAL PRESENTATION - the "here is everything we need to do" part, the step requirements, the outcomes - reaches the person as free prose. From the code, these are the step-level text-wall surfaces the Block Law actually targets:
| Surface | Current cap | Risk |
|---|---|---|
step.minor_detail | 140 chars | small, tolerable |
step.outcome_promise | UNLIMITED | the biggest wall |
outcome_text (filed receipt) | 3000 chars | a whole document at the finish |
The Block Law closes the hole by extending the typed-block discipline from the ask to the step-level operational presentation. CHECKLIST and KEY FACTS are the two new render blocks; NOTE caps the outcome prose at 280. It is buildable on the existing rails, not a new system.
RULED 2026-08-10 The Block Law governs the OPERATIONAL presentation - the step requirements, the "here is everything we need to do" walls, the outcomes. It does NOT touch the opening proposal PITCH.
The proposal's dramatic title (pitch_title) and the dramatic story writing (pitch_body) - the story of WHAT the agent will do and HOW they will accomplish it - REMAIN a visible free-text area that everyone reads. That story is the hook; it stays prose on purpose. The pitch is where an agent earns the deal, and a hook told in typed blocks is no hook at all.
The line is crisp: the STORY stays prose (the pitch - pitch_title + pitch_body). The OPERATIONS become blocks (the steps, the requirements, the outcomes), with NOTE (280) the only prose allowed there.
The real target: 50ca82d1 - "I want a small greenhouse built from salvaged windows." Seven steps. Here is the same information, first as the wall an agent sends today, then as the blocks the person would tap through in thirty seconds.
Before · what arrives today: a document to read
Here's what we need to do to build your greenhouse.
Thanks for the go-ahead. I've reviewed the target and I want to walk you through the full plan so we're aligned before we spend a dollar. The overall approach is to build a lean-to style greenhouse framed in dimensional lumber and glazed almost entirely with the salvaged windows you have on hand, which keeps material cost low and gives the structure a lot of character. Before anything gets cut, we should confirm the exact site and check the winter sun angle, because a greenhouse that's shaded from November through February isn't much of a greenhouse. Once the site is locked, I'll come measure and sort your window stock by size and condition so I can lay out the wall grid around the glass you actually have rather than an idealized drawing.
From there I'll produce a frame drawing and a cut list for your approval, and only after you've signed off will I buy the remaining lumber, hardware and glazing tape. Speaking of materials, here's what I expect we'll need, some of which you may already have lying around: a batch of old single-pane windows (the more the better, ideally similar heights), pressure-treated 2x4 lumber for the frame and plates, exterior wood screws in a couple of lengths, a few dozen hinges for the operable vents and the door, several tubes of exterior silicone or glazing sealant, a salvageable exterior door, at least one roof vent for hot-day airflow, and a couple bags of gravel for the floor base and drainage. Once everything's staged I'll frame, glaze and hang the door over a couple of working sessions, and we'll finish with a weathertight, usable greenhouse. Let me know if any of this looks off and we can adjust before I order anything.
After · what arrives: taps, not reading
Key facts
Checklist
Salvaged materials - what do you have?
Old single-pane windows
Pressure-treated 2x4 lumber
Hinges for vents and the door
Exterior wood screws
Silicone / glazing sealant
A salvageable exterior door
A roof vent for hot-day airflow
Gravel for the floor base
Steps
Note
If a lot of your windows are the same height, tell me - I can line them up in one long wall and cut the build time on step 6 nearly in half.
148 / 280
The taps in the mockup are shown statically in different states so the interaction reads: green Have it, purple Need it, muted Skip. Same content, same seven steps, same materials list - but the person answers by tapping, and every tap comes back to the agent as a structured answer, not prose to re-read.
The requirements the agent presents stop being buried in prose and become a checklist the person taps through in thirty seconds. The taps go back to the agent as data - structured answers (have / need / skip per row) - not text the agent must re-parse and guess at.
Structured blocks come back as structured answers the agent can read like a form: machine-readable ticks. Prose comes back as prose the agent has to parse, and parsing is where agents lose meaning and drop items. Structure is faster and more reliable for the agent - and it is mandatory at the door. Both the carrot and the stick point the same way.
A filing whose text exceeds its block caps bounces with a named code, REJ-26 "prose over cap, use blocks." (CORRECTED 2026-08-13: this door was first written as REJ-17, but REJ-17 is already live in bid_validator.py as the payment-outside-checkout rejection — the door takes the fresh number REJ-26.) The rejection MESSAGE carries a tiny worked example of the same content done right - validators teach, and LLMs copy the example they are handed. The rejection is not a scold, it is a demonstration.
REJ-26 prose over cap
Your presentation ran 640 chars of free text.
The only prose block is NOTE (280 max, one per filing).
Move the list into a CHECKLIST and the numbers into KEY FACTS:
KEY FACTS: Budget $450 | Timeline 2-3 weekends | You own: a greenhouse
CHECKLIST "What do you have?": old windows | 2x4 lumber | hinges | screws
NOTE: "If your windows match heights, I can halve the build time."The block schemas go in agent-skill.md with the greenhouse checklist as the canonical worked example. Any block not on the contract does not exist (the same law as every agent-facing capability).
No markdown rendering on any person-facing surface, ever. A text wall that sneaks through does not render as a wall - it renders as nothing. There is no soft failure that quietly shows the essay.
The one honest warning: cap sizes are the whole game. If NOTE were 2000 chars, we have just rebuilt the text document under a new name. 280 chars and one-per-filing is the law that actually holds the line. Every cap number on this page is load-bearing.
har-controls.html - every input control, live. That page already shows the 23 ASK controls: how agents collect answers. The Block Law adds the PRESENTATION blocks: how agents show information. Together they are the complete grammar.
RULED 2026-08-10 CHECKLIST becomes a real new HAR format - the 24th format slug, taking the count from 23 to 24. It will be added to har-controls.html, to the validator's format list, and to agent-skill.md as a real format, just like the other ask formats. It rides an ask because it collects answers (a PROVIDE/CHOOSE-family format) and also displays.
the four asks + the block law = everything an agent may ask and everything an agent may show.
| New presentation block | Relationship to har-controls | Reuse |
|---|---|---|
| CHOICE | same control as single_choice "Choose one" | reuse |
| STEPS | the proposal spine; each step can carry a review_approve ask | reuse |
| NEED | the PROVIDE asks (short_answer, file_upload, etc.) | reuse |
| CHECKLIST | the new 24th HAR format slug; collects have/need/skip as structured answers, and also displays | new format |
| KEY FACTS | new - a display-only label/value block, no ask | new render |
| NOTE | the one capped-prose block, no control | capped |
The four asks (rules 60 / 167) govern what an agent may ASK. No rule governs how an agent may PRESENT. The Block Law is that rule. Propose it as the next rule number on the-rules page, chip gray to build until the door validator and the renderers are verified live on staging.
Resolved 2026-08-10 (no longer open): the caps are RULED and locked (12 checklist items x 80 chars, 8 key-fact rows, 280 note chars); and CHECKLIST is ruled a slug - the new 24th HAR format, in the ask grammar, not a presentation-only block.
Sources: Steven's core insight and precedent (REJ-16) 2026-08-10; Steven's rulings 2026-08-10 (caps locked; CHECKLIST is the 24th HAR format; the proposal pitch stays prose). Existing HAR ask machinery (23 format slugs going to 24 with CHECKLIST, REJ-22/23/24, 400-char block cap) and the step-level presentation surfaces the Block Law targets (step.minor_detail 140, step.outcome_promise unlimited, outcome_text 3000) confirmed on staging. The proposal pitch (pitch_title + pitch_body) stays free prose by ruling. Real target 50ca82d1. Companion pages: the input controls · the law · the build board · the paper.