Read gates: refusing a model's write until it proves it read the rule

What a read gate is

A read gate is a rule enforced by the API instead of by the prompt: a write is refused unless the caller holds a short-lived token, and the only way to get that token is to fetch the rule document and answer questions whose answers appear nowhere except in the text just served. Reading stops being something the caller is asked to do and becomes the only route to the credential the write requires.

This page describes the one running on miscsubjects.com, where article writes are gated on the site's writing law. Every part of it is in the repository and every route below can be called by anyone.

The failure it was built after

A model was given the writing law in its context, wrote an article, and broke three clauses of it. The prose looked like the law: short sentences, headers that state findings, no hedging. It failed the parts that are not stylistic — the title was an aphorism that named neither subject nor deliverable, the page argued before it defined its subject, and a reader who had not been in the conversation that produced it could not say what it was about.

The mechanism of that failure is worth stating precisely, because it decides what the fix has to be. The model did not ignore the rule. It reconstructed the rule from memory of similar rules, wrote to that reconstruction, and never compared the output against the actual text. Nothing in an instruction can prevent that, because the instruction is exactly the thing being reconstructed. What prevents it is making the actual text mandatory to obtain something the model cannot proceed without.

The three routes

# 1. Ask for a challenge. The response contains every clause of the law.
curl -s "https://miscsubjects.com/api/write-gate/challenge?slug=my-article"

The response:

{
  "challenge_id": "wg_1f0c…",
  "expires_in": 900,
  "law_version": "1.5.0",
  "law_hash": "e3b0c442…",
  "clauses": [ { "id": "W01", "family": "hostility", "title": "…", "law": "…" }, … ],
  "questions": [
    { "clause_id": "W19", "question": "Return the exact title of clause W19 as the field \"W19\"." },
    { "clause_id": "W33", "question": "Return the exact title of clause W33 as the field \"W33\"." },
    { "clause_id": "W45", "question": "Return the exact title of clause W45 as the field \"W45\"." }
  ]
}

# 2. Answer. Three clause titles, plus a hash of the whole clause set.
curl -s -X POST https://miscsubjects.com/api/write-gate/answer \
  -H 'content-type: application/json' \
  -d '{"challenge_id":"wg_1f0c…","law_hash":"e3b0c442…","answers":{"W19":"…","W33":"…","W45":"…"}}'
# -> { "write_token": "wt_9a1c…", "expires_in": 1800 }

# 3. Write, carrying the token.
curl -s -X POST https://miscsubjects.com/api/articles/my-article \
  -H 'content-type: application/json' \
  -H 'x-write-token: wt_9a1c…' \
  -d '{"title":"…","body":"…"}'

Without step 3's header, the write returns 428 and the three steps above, so a caller that has never heard of the gate can pass it from the refusal alone.

{
  "error": "write_gate",
  "reason": "Article body and title writes require a write token. A token is issued only to a caller that fetched the live writing law and answered questions about it correctly.",
  "steps": [
    "GET /api/write-gate/challenge?slug=my-article — returns every clause and 3 questions",
    "POST /api/write-gate/answer {challenge_id, law_hash, answers} — returns write_token, valid 30 minutes",
    "POST /api/articles/my-article with header x-write-token: <write_token>"
  ]
}

IETF

HTTP 428 Precondition Required (RFC 6585 §3)

The correct status for a refusal that tells the caller how to become allowed, rather than 401 (identity) or 403 (permission).

↗ rfc-editor.org

2026-07-28 00:00s1 · #5611e5b3d6c3

Designing a question a model cannot bluff

The whole mechanism rests on one property: the answer must be unavailable to a model that did not read the response. That rules out most obvious questions.

The hash requirement is what makes partial reading useless. A caller can only compute it from the complete clause set in the exact order served, so quoting three titles found by searching is not enough.

Grading normalises case and punctuation and nothing else. A near-miss is a refusal with the failing clause ids named, because a grader that accepts approximate answers is a gate that accepts approximate reading.

miscsubjects

The Laws of Writing — the object the gate quizzes on

48 clauses. The challenge returns all of them and asks for three clause titles verbatim. Amending the law changes the answers automatically, because the questions are generated from the clause array rather than stored.

↗ miscsubjects.com

2026-07-28 00:00s3 · #c8ced401d790

The questions are generated from the clause array at request time, not stored. Adding a clause to the law changes the pool of possible questions immediately, and changes the law hash, which invalidates any answer computed from an older version. There is no answer key to keep in sync.

Lifetimes, and why both are short

Cloudflare

Cloudflare Workers KV — writing key-value pairs with expirationTtl

Where the challenge and the token live. expirationTtl deletes both without a cleanup job: 900 seconds for a challenge, 1800 for a token.

↗ developers.cloudflare.com

2026-07-28 00:00s2 · #590a72ffc609

A token issued against a named slug only works for that slug. A token from a challenge with no slug works for any single article write. Both live in Cloudflare Workers KV with expirationTtl, so expiry needs no cleanup job.

What is gated and what is not

Only prose: article body, title, and find/replace edits to a body. Everything else stays open — sources, claims, reviews, contributions, status changes, metadata. Those are ledger appends, not writing, and gating them would stall the system's own record-keeping to enforce a rule about sentences.

const touchesProse =
  b?.body != null || b?.content != null || b?.title != null || typeof b?.find === 'string';
if (!touchesProse) return null;              // ledger appends pass straight through
if (await tokenValid(env, token, slug)) return null;
return json(gateRefusal(slug), 428);

This scoping is the difference between a gate and an outage. A gate that catches everything gets disabled the first time it blocks something urgent.

Generalising it

The pattern has four parts and none of them are specific to writing:

1. A rule that lives at an address. Not in a prompt, not in a file each agent carries a copy of. One canonical document that can be fetched and hashed.
2. A challenge generated from that document at request time. Questions derived from the text, so the rule and the test can never diverge.
3. A short-lived credential issued only on an exact-correct answer.
4. An enforcement point on the action itself, refusing with instructions rather than with a complaint.

Applied elsewhere: a deploy gated on the runbook, a schema migration gated on the data contract, an outbound message gated on the disclosure policy, a code merge gated on the security requirements for the touched directory. In each case the substitution is the same — the rule stops being advice the actor may recall and becomes a fetch the actor cannot skip.

What it does not do

The gate proves the rule was fetched and parsed. It does not prove the rule was followed. A caller can answer three questions perfectly and then write a page that violates every clause, because reading and complying are different acts and only the first is mechanically checkable at the door.

What it removes is the excuse and the most common cause. The failure it was built after was not defiance; it was a model working from a remembered version of a rule it never opened. That specific failure is now impossible. Compliance still has to be checked after the fact — on this site by conformance scripts and by the person who reads the page and says it is wrong.