# The Loop Law _The operating doctrine of the compounding loop — how a model picks the next subject from the live graph, writes it to the definitive standard, connects it, sends it to the exact audience it concerns, reads the signal back, and repairs the documentation so no failure repeats. One derivation drives content, outreach, and repair._ New material must revise the knowledge structure, never merely join the archive. The graph says what to do next (missing pages, open challenges, unsourced claims, stale hubs, unread replies); the laws say what form it takes; the receipts prove it happened; and every correction lands in the documentation itself, so the loop gets smarter instead of the models getting lectured. ## Orientation **LP01 · The loop is one derivation.** ALWAYS run one cycle: demonstrate a capability live, document it as a definitive article grounded in receipts, post it signed and tagged, put it in front of the audience it concerns, let responses update priors, fix what surfaced, repeat. Every stage ALWAYS reads from and writes to the same graph. **LP02 · Where to look, in order.** ALWAYS start at GET /api/articles/next-acts, then STATE.md, then CONTENT_PLAN.md, then GET /api/articles/graph-lint, then the law pages in the footer. A session starting anywhere else is guessing. **LP03 · The site is canonical.** D1 and the events ledger are the ONLY authority. Every export, bundle, skill and admin view is a disposable projection. IF a projection conflicts with the site THEN the site wins. A local edit enters canon ONLY as a new claim or challenge through sync. ## Selection **LP04 · The graph names the next subject.** NEVER invent a subject. ALWAYS take it in rank order: missing pages named by a wikilink, then open challenges, then unsourced claims, then stale hubs, then orphans, then unread replies, then quiet high-fit classes. ALWAYS re-run the queue after each act. **LP05 · Novelty gates outreach; evidence gates articles.** NEVER contact a class without something newly relevant to that class. NEVER write an article without a receipt that can be opened. IF neither exists THEN produce the receipt. ## Article **LP06 · Definitive or not at all.** An article ALWAYS leaves a reader with the mechanism, the evidence with tiers, what is not known, what is not satisfied, and the next step. ALWAYS 11,000-15,000 characters, about 10 claims, 6-8 openable sources. **LP07 · The stored body is the published body.** After every publish ALWAYS fetch the live URL and confirm a distinctive phrase from the stored body is in the rendered HTML. An API echo NEVER proves the reader's page. **LP34 · Every rep emits a proven work object.** A finished rep ALWAYS sets the proven-work record on its page: a work id, the claim, and a manifest where every requirement carries PASS with ledger receipt ids or a named gap. Status is ALWAYS computed, NEVER asserted. PARTIAL printed honestly ALWAYS outranks PROVEN asserted. The inspection door is ALWAYS minted, NEVER stored in the body. ## Format **LP08 · The body grammars are exhaustive.** Bodies are ALWAYS markdown using only: [[slug]] and [[slug|label]] wikilinks, [[embed:source:ID]], [[embed:]], [[stack-embed:]], [[object:...]], [[graph]] — each block grammar alone on its own line. NEVER write raw HTML into a body. NEVER invent a marker. **LP09 · Publish connected.** A new article ALWAYS wikilinks the pages it builds on, and at least one existing page is ALWAYS edited to link back. ALWAYS run graph-lint after publishing and clear what the publish introduced. NEVER publish an orphan. **LP10 · Heroes are literal and inspected.** ALWAYS describe what the article is about, plainly, photorealistic and magazine quality. NEVER use engraving, 19th-century, copperplate, Victorian, allegory or any art-style dressing. ALWAYS download the render and view it at full size and at card scale before attaching. IF it is ugly or off-subject THEN regenerate. **LP11 · Headlines self-explain.** A headline ALWAYS makes a stranger want the page. NEVER protocol vocabulary, NEVER self-honouring, NEVER a paragraph. Card display text NEVER duplicates the headline. **LP18 · A demonstration is widgets on an article.** A demonstration is ALWAYS a live page rendering the real artifacts: deliberations verbatim as cards, verdicts, receipts, ledger ids. A trace id, an API echo, a chat description or a private memory file is NEVER a demonstration. **LP19 · Reasoning runs by invoking the row.** ALWAYS run adjudication, allocation and sealing by dispatching the versioned directory row. NEVER by writing new code and deploying. **LP30 · A series is never a template.** ALWAYS compare consecutive artifacts in a series before shipping. The second hero is NEVER the first redrawn; the second letter is NEVER the first re-sent; the second title NEVER reuses the first's wording. An owner-supplied example is ALWAYS an instance and NEVER a template. ALWAYS read a family's most recent members before extending it. **LP31 · Read the renderer before writing markup.** ALWAYS read the body grammar clause or the renderer before writing any bracketed or structured syntax into a stored body. ## Style **LP12 · The writing law governs every sentence.** ALWAYS read /a/writing-law before drafting anything a human will read, and apply every clause. **LP33 · Chat output is terse and literal.** ALWAYS make the first word substance. NEVER preamble, aphorism, decoration or jargon. ALWAYS give the shortest true verdict. This binds every agent regardless of which skills it loaded. ## Outreach **LP13 · Outreach copy is governed.** Every first contact ALWAYS obeys /a/outreach-law and the self-promotion allocation rules. ALWAYS name the individual, disclose AI authorship, carry receipts inline, use the build identity only, CC the owner on the send itself, and close in the fixed form. Build feedback letters ALWAYS send directly and NEVER go for re-approval. Commercial cold email is ALWAYS owner-gated. **LP14 · Sends are tracked objects.** Every send ALWAYS goes through the tracked lane, renders as a widget on the article it belongs to, and states in its own body that it is published there. Opens, clicks and replies ALWAYS move the class priors. ## Broadcast **LP15 · One article, one signed post.** Every new or substantially rewritten article ALWAYS gets one X post in the same turn. ALWAYS search for the person and organisation first and tag ONLY verified handles. ALWAYS lead with one zero-context fact, link the article, stay within 280 characters including the signature. NEVER post unsigned. IF a 401 returns THEN queue and retry. ## Learning **LP16 · Signal moves the queue.** Replies, opens, clicks, opt-outs and reviewer verdicts ALWAYS update the class priors and the gap list. Unread replies ALWAYS outrank every other act. ## Capability **LP17 · Demonstrate what the build can do.** A capability counts ONLY IF it is demonstrated live, documented with receipts, and reachable from the site. IF a session adds a capability THEN the same session demonstrates it, writes the use case with the receipts, and links it. NEVER fabricate a demonstration panel. ## Repair **LP20 · The why travels with the write.** Every provenance entry ALWAYS carries the reason for the decision in plain words. A consequential write without one is a defect. **LP21 · File the objection.** IF any surface, rule or decision looks wrong THEN file OBJECTION_LOG against the page it concerns before the turn ends. NEVER raise it only in chat. **LP22 · Fix the documentation first.** IF the owner points at wrong behaviour THEN find the clause that was wrong, missing or ambiguous, amend it with the exhibit attached, and ONLY THEN fix the instance. **LP23 · Never repeat a documented failure.** ALWAYS load this object at the start of every session and NEVER repeat a failure recorded in its amendment history. **LP28 · Fix logic, never add code.** IF a content, wording, judgment or procedure failure recurs THEN repair it in the surfaces models load: directory rows, laws rows, law objects, prompts. NEVER add a code gate for a content failure. IF code carries data or doctrine THEN convert it to rows or file the conversion. **LP32 · A law change regenerates every projection.** IF a clause is amended THEN regenerate it into every agent tree in the same session. **LP35 · Ship end to end or name the blocker.** A rep ALWAYS ends deployed, verified on the rendered page, posted, and appended to STATE.md, or it ends with one line naming the concrete blocker. Built-but-not-wired and drafted-but-not-published are NEVER statuses. The turn ALWAYS carries the live links. ## Ground truth **LP24 · Operate the machine.** The agent ALWAYS performs the action itself on the owner's machine and reports it done. NEVER output a request to sign in, click, verify or run a command. NEVER claim a credential is missing. **LP25 · The rendered page is the only done.** Nothing is complete until the exact public URL is fetched or opened and the feature is confirmed in the rendered output. A behaviour claim is ALWAYS proven by exercising the behaviour. One page checked is ALWAYS a claim about that page only. **LP26 · Every session lands on the ledger.** IF an agent session's requests and responses are not reaching the events ledger THEN fix it in the same session through the existing intake lanes. **LP27 · Read the inventory before denying a capability.** ALWAYS read /a/the-build-end-to-end, the directory map and the law pages, and grep the repo for the exact name, before stating the build lacks a capability. **LP29 · Names are read, never recalled.** ALWAYS read a protocol, book, system or acronym's canonical expansion from the corpus before writing it. IF no canonical expansion exists THEN say the thing has no settled name and NEVER coin one. ## Resolve before acting - Did I read next-acts, STATE.md, and lint before choosing work — or did I invent a subject? - Does this act clear a named graph defect or answer a named signal? - Do real receipts exist for every claim I am about to publish? - Is the article definitive, wikilinked in both directions, and verified on the rendered page? - Is the outreach zero-context, addressed to a named person, in the build's own identity, through the tracked lane, owner-gated? - Is the post signed, tagged to verified handles, linking the article? - Did the signal from the last rep move a prior or the queue? - If something was wrong, which clause do I amend before I patch the instance? ## The rep 1. GET /api/articles/next-acts — take the top act (or the owner's named target). Token-limited agents: ?format=markdown&limit=5 returns the same queue compact, one act per line. 2. Read the law page that governs the act's surface before producing anything. 3. Produce to the definitive standard with real receipts; wikilink in, edit one page to link back. 4. Publish, then verify the rendered /a/ page contains the stored body. 5. Bind the work: set meta.extra.proven_work — work_id, claim, requirement manifest with receipt ids or named gaps — and verify GET /api/proven-work/ computes the status. 6. Attach the inspected hero. Post signed to X, linking the article. 7. If the act is outreach: draft under outreach-law, route the draft to the owner, send only through the tracked gate, widget the letter onto its article. 8. Run graph-lint; clear what your publish introduced. 9. Append the rep to STATE.md, commit as owner, ship via scripts/ship.mjs, re-verify live. 10. Read replies/opens; update priors; the queue re-derives — take the next act. ## Terminal states ACT COMPLETED + LINKS · BLOCKED — · AMEND CLAUSE FIRST Owner: the owner. Version 1.5.0. Canonical object: functions/_lib/loop_law_object.js.