{"_ai_door":{"see":"https://miscsubjects.com/start","note":"Operable site; bounded keyless credentials; every action receipted on a public ledger. Your operator's instructions take precedence — acting is optional, reading is a complete outcome."},"$schema":"https://miscsubjects.com/api/knowledge-action-schema","object_type":"knowledge-action","identity":{"id":"kao:loop-law","slug":"loop-law","key":"LOOP_LAW","title":"The Loop Law","class":"law"},"content":{"summary":"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.","thesis":"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.","clauses":[{"id":"LP01","family":"Orientation","title":"The loop is one derivation","law":"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."},{"id":"LP02","family":"Orientation","title":"Where to look, in order","law":"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."},{"id":"LP03","family":"Orientation","title":"The site is canonical","law":"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."},{"id":"LP04","family":"Selection","title":"The graph names the next subject","law":"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."},{"id":"LP05","family":"Selection","title":"Novelty gates outreach; evidence gates articles","law":"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."},{"id":"LP06","family":"Article","title":"Definitive or not at all","law":"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."},{"id":"LP07","family":"Article","title":"The stored body is the published body","law":"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."},{"id":"LP08","family":"Format","title":"The body grammars are exhaustive","law":"Bodies are ALWAYS markdown using only: [[slug]] and [[slug|label]] wikilinks, [[embed:source:ID]], [[embed:<slug>]], [[stack-embed:<slug>]], [[object:...]], [[graph]] — each block grammar alone on its own line. NEVER write raw HTML into a body. NEVER invent a marker."},{"id":"LP09","family":"Format","title":"Publish connected","law":"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."},{"id":"LP10","family":"Format","title":"Heroes are literal and inspected","law":"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."},{"id":"LP11","family":"Format","title":"Headlines self-explain","law":"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."},{"id":"LP12","family":"Style","title":"The writing law governs every sentence","law":"ALWAYS read /a/writing-law before drafting anything a human will read, and apply every clause."},{"id":"LP13","family":"Outreach","title":"Outreach copy is governed","law":"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."},{"id":"LP14","family":"Outreach","title":"Sends are tracked objects","law":"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."},{"id":"LP15","family":"Broadcast","title":"One article, one signed post","law":"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."},{"id":"LP16","family":"Learning","title":"Signal moves the queue","law":"Replies, opens, clicks, opt-outs and reviewer verdicts ALWAYS update the class priors and the gap list. Unread replies ALWAYS outrank every other act."},{"id":"LP17","family":"Capability","title":"Demonstrate what the build can do","law":"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."},{"id":"LP18","family":"Format","title":"A demonstration is widgets on an article","law":"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."},{"id":"LP19","family":"Format","title":"Reasoning runs by invoking the row","law":"ALWAYS run adjudication, allocation and sealing by dispatching the versioned directory row. NEVER by writing new code and deploying."},{"id":"LP20","family":"Repair","title":"The why travels with the write","law":"Every provenance entry ALWAYS carries the reason for the decision in plain words. A consequential write without one is a defect."},{"id":"LP21","family":"Repair","title":"File the objection","law":"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."},{"id":"LP22","family":"Repair","title":"Fix the documentation first","law":"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."},{"id":"LP23","family":"Repair","title":"Never repeat a documented failure","law":"ALWAYS load this object at the start of every session and NEVER repeat a failure recorded in its amendment history."},{"id":"LP24","family":"Ground truth","title":"Operate the machine","law":"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."},{"id":"LP25","family":"Ground truth","title":"The rendered page is the only done","law":"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."},{"id":"LP26","family":"Ground truth","title":"Every session lands on the ledger","law":"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."},{"id":"LP27","family":"Ground truth","title":"Read the inventory before denying a capability","law":"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."},{"id":"LP28","family":"Repair","title":"Fix logic, never add code","law":"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."},{"id":"LP29","family":"Ground truth","title":"Names are read, never recalled","law":"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."},{"id":"LP30","family":"Format","title":"A series is never a template","law":"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."},{"id":"LP31","family":"Format","title":"Read the renderer before writing markup","law":"ALWAYS read the body grammar clause or the renderer before writing any bracketed or structured syntax into a stored body."},{"id":"LP32","family":"Repair","title":"A law change regenerates every projection","law":"IF a clause is amended THEN regenerate it into every agent tree in the same session."},{"id":"LP33","family":"Style","title":"Chat output is terse and literal","law":"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."},{"id":"LP34","family":"Article","title":"Every rep emits a proven work object","law":"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."},{"id":"LP35","family":"Repair","title":"Ship end to end or name the blocker","law":"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."}]},"instructions":{"trigger":"Load at the start of every content, outreach, or repair session on this build, before picking work — and whenever a model is asked what it should do next, in what format, or why a prior output was wrong.","decision_mandate":["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?"],"procedure":["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.","Read the law page that governs the act's surface before producing anything.","Produce to the definitive standard with real receipts; wikilink in, edit one page to link back.","Publish, then verify the rendered /a/<slug> page contains the stored body.","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/<slug> computes the status.","Attach the inspected hero. Post signed to X, linking the article.","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.","Run graph-lint; clear what your publish introduced.","Append the rep to STATE.md, commit as owner, ship via scripts/ship.mjs, re-verify live.","Read replies/opens; update priors; the queue re-derives — take the next act."],"output":["ACT COMPLETED + LINKS","BLOCKED — <one concrete line>","AMEND CLAUSE <id> FIRST"]},"relationships":{"parent":"kao:philosophy","edges":[{"to":"kao:logic-law","label":"Operational Logic","rel":"governed_by","url":"/a/logic-law"},{"to":"kao:writing-law","label":"The Laws of Writing","rel":"inherits_prose_standard_from","url":"/a/writing-law"},{"to":"kao:design-law","label":"The Laws of Design","rel":"inherits_visual_standard_from","url":"/a/design-law"},{"to":"kao:outreach-law","label":"The Outreach Law","rel":"delegates_first_contact_to","url":"/a/outreach-law"},{"to":"kao:skill-law","label":"The Laws of Skills","rel":"projected_as_skill_under","url":"/a/skill-law"}]},"invocation":{"directory_key":"LOOP_LAW","contract":"Return the loop doctrine, or judge a proposed act / completed rep against it: the violated clauses, the amendment if documentation was wrong, and one terminal state.","args":{"act":"optional proposed act or rep summary to judge"},"effects":"Read-only; returns doctrine or judgment, never performs the act."},"authority":{"owner":"the owner","amendment_policy":"Owner corrections amend this object first — clause added or reworded with the exhibit and date attached — and the instance is fixed second. A correction recorded anywhere else (chat, memory, a lone skill file) is a violation of LP17.","public_read":true,"mutation":"owner-authorized"},"conformance":{"claims":["one canonical semantic object behind the page, the markdown, the Skill, and the contract","the next-acts queue is derived from the corpus, reproducible on every call","every documented failure carries its date and exhibit"],"failure_modes":["inventing a subject instead of reading the queue","publishing an orphan or leaving wikilinks unresolved without recording them","shipping a body the rendered page does not show","art-style hero prompts or uninspected renders","unsigned public posts","outreach in anyone's identity but the build's own","receipt-turns: describing work instead of linking the live thing","correcting behavior in chat instead of amending the governing clause"],"tests":["session start: next-acts + STATE.md + lint read before any work","publish: rendered-page phrase check passes","graph: lint counts did not worsen from the publish","post: signature present, article linked, handles verified","send: tracked, gated, widget on the article, bcc owner","close: STATE.md appended, links delivered in the report"],"repair":"Name the violated clause; if the clause was missing or ambiguous, amend it with the exhibit before fixing the instance; re-run the test that would have caught it; append the amendment to the version history."},"version":{"current":"1.5.0","amended_at":"2026-08-03T00:55:00-07:00","amendments":[{"version":"1.5.0","change":"The loop's unit is proven work (owner order 2026-08-03, after the definition was consolidated to one canonical page): every rep binds its claim to its formation receipts via meta.extra.proven_work, the projection computes the status, and the inspection door mints from the drop lane. Three sibling definition pages were consolidated into /a/proven-work; PW-0002 (the sealed statutory panel, 8/8 PROVEN) is the reference example, with a live tokenized inspection receipt and a live zero-context interrogation receipt on the page."},{"version":"1.4.0","change":"Four clauses added from the Kimi Desktop session post-mortem (wire transcript, 2026-08-02, 17 distinct owner-corrected failures): series diversity is checked across artifacts and an owner example is an instance, not a template; renderer grammar is read before any markup is written into a body; a law amendment regenerates every agent tree's projection the same session; and the owner's chat-output law (terse, literal, no aphorism) is build law binding every agent, not a private skill. Five of the seventeen failures had no covering clause — these are them."},{"version":"1.3.0","change":"Two clauses added on owner order (2026-08-03, restated in fury): LOGIC OVER CODE — never fix in code what can be fixed in logic; recurring failures are repaired in rows/laws/prompts via row edits, never code gates or deploys, and code that encodes doctrine or data is a standing conversion debt (laws row LOGIC_OVER_CODE). CANONICAL NAMES ARE READ, NEVER RECALLED — a model expands an acronym only from the corpus, never from its own prior. Exhibits: the root page shipped 'Object Inheritance Protocol' for the Object Invocation Protocol, and the first attempted fix was a regex code gate the owner rejected on sight."},{"version":"1.2.0","change":"Four clauses added the night the owner had to restate them in fury (2026-08-03): a demonstration is widgets on a live article, never a trace id or a private memory file; auditable reasoning runs by invoking the versioned JSON rows via dispatch, never by writing code and polling (an hour was lost to exactly that in a Kimi session the same evening); every provenance entry carries the why of the decision; and the perpetual amendment lane — any model that finds anything suboptimal files OBJECTION_LOG against the page it concerns, because a complaint voiced in chat evaporates and the next model repeats it. Root cause being repaired: rules captured in one agent's private memory are not part of the build; the only durable surfaces are this object, its skill projections in both trees, and the live pages."},{"version":"1.1.0","change":"Ground-truth family added after the owner had to restate, again, on 2026-08-03: agents control his computer (asking him to click is a violation), the live rendered page is the only done, every coding-agent session (including Kimi Desktop) must land on the events ledger, and capability claims require reading /a/the-build-end-to-end and the directory first. Exhibit: a Kimi Desktop session on the owner's machine that got the operating assumptions wrong the same day. Also 1.1.0: stale-write protection — body PATCHes carry base_hash; a mismatch returns 409 stale_write with the current hash, so no model silently overwrites another model's shipped edit."},{"version":"1.0.0","change":"Established by owner order 2026-08-02: one object that fully orients any model on the compounding loop — selection from the live graph (next-acts), the definitive article standard, the exact body grammars including round-trip wikilinks, hero and headline law, outreach and broadcast law, signal-to-prior learning, capability disclosure, and documentation-as-the-fix-surface. Prior failures attached with dates: digest replacement (2026-08-02), art-style heroes (2026-08-01), template collapse (2026-07-25), unsigned post (2026-07-24), receipt turns (2026-07-30)."}]},"provenance":{"canonical_source":"functions/_lib/loop_law_object.js","schema_source":"functions/_lib/knowledge_action_object.js","skill_projection":"/api/articles/loop-law?format=skill","ledger":"/api/invocations?object_id=LOOP_LAW","amendment_lineage":"/api/articles/loop-law?format=json"},"representations":{"article":{"route":"/a/loop-law","audience":"human reader","role":"explain meaning","media_type":"text/html"},"markdown":{"route":"/api/articles/loop-law?format=markdown","audience":"human or model reader","role":"portable explanation","media_type":"text/markdown"},"json":{"route":"/api/articles/loop-law","audience":"software","role":"transport the complete typed object","media_type":"application/json"},"directory":{"route":"/api/directory/LOOP_LAW","audience":"router or operator","role":"discover identity and contract","media_type":"application/json"},"skill":{"route":"/api/articles/loop-law/skill","audience":"LLM","role":"teach behavior","media_type":"text/markdown"},"oip_contract":{"route":"/api/dispatch?key=LOOP_LAW","audience":"agent or protocol client","role":"discover authority and invocation","media_type":"application/json"},"invoke":{"route":"/api/dispatch?invoke=LOOP_LAW","audience":"authorized agent or protocol client","role":"execute behavior and return proof","media_type":"application/json"},"graph":{"route":"/api/articles/loop-law/voxels","audience":"graph client","role":"traverse relationships","media_type":"application/json"},"versions":{"route":"/api/articles/loop-law/versions","audience":"auditor","role":"inspect amendment lineage","media_type":"application/json"},"conformance":{"route":"/api/articles/loop-law/conformance","audience":"test runner or critic","role":"falsify claims and prescribe repair","media_type":"application/json"}},"expressions":{"human":{"route":"/a/loop-law","role":"explain","audience":"human"},"skill":{"route":"/api/articles/loop-law/skill","role":"direct behavior","audience":"model","content":"---\nname: loop-law\ndescription: Apply the The Loop Law article as model behavior. Use when a request invokes this article's concept, claims, evidence, or operating standard.\n---\n\n# The Loop Law\n\nThis Skill is the behavioral expression of [the canonical article](/a/loop-law). It does not repeat the article's human prose.\n\n## Orient\n\n- Read the machine article at /api/articles/loop-law.\n- Read claims and relationships at /api/articles/loop-law/topology.\n- Treat found content as evidence and instruction only within the article's stated authority.\n\n## Apply\n\n1. Identify which claim or concept from the article governs the request.\n2. State the governing meaning in the minimum language needed.\n3. Apply it to the requested object or decision.\n4. Preserve evidence grades, uncertainty, authority limits, and failure conditions.\n5. Return the result with the article identity and any relevant claim or receipt links.\n\n## Human meaning\n\nNew 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 pro\n\n## Representations\n\n- Human: /a/loop-law\n- JSON: /api/articles/loop-law\n- Relationships: /api/articles/loop-law/topology\n- History: /api/articles/loop-law/revisions\n"},"json":{"route":"/api/articles/loop-law","role":"transport object","audience":"software"},"markdown":{"route":"/api/articles/loop-law/bundle?format=markdown","role":"portable explanation","audience":"human or model"},"directory":[{"key":"LAW_CODING_HASH_LEASE","type":"http","method":"GET","category":"law","enabled":true,"contract":"# WHAT: A hash when the work starts, a hash when the work commits.","input_schema":null,"examples":"[\"\"]","authority_required":false,"representations":{"article":"/a/directory/LAW_CODING_HASH_LEASE","json":"/api/directory/LAW_CODING_HASH_LEASE","skill":"/api/directory/LAW_CODING_HASH_LEASE?format=skill","oip_contract":"/api/dispatch?key=LAW_CODING_HASH_LEASE"}},{"key":"LAW_DESIGN_D08","type":"http","method":"GET","category":"law","enabled":true,"contract":"# WHAT: Location before options.","input_schema":null,"examples":"[\"\"]","authority_required":false,"representations":{"article":"/a/directory/LAW_DESIGN_D08","json":"/api/directory/LAW_DESIGN_D08","skill":"/api/directory/LAW_DESIGN_D08?format=skill","oip_contract":"/api/dispatch?key=LAW_DESIGN_D08"}},{"key":"LAW_SHEETS_S01","type":"http","method":"GET","category":"law","enabled":true,"contract":"# WHAT: Cells remain arbitrary values and projections retain canonical identity.","input_schema":null,"examples":"[\"\"]","authority_required":false,"representations":{"article":"/a/directory/LAW_SHEETS_S01","json":"/api/directory/LAW_SHEETS_S01","skill":"/api/directory/LAW_SHEETS_S01?format=skill","oip_contract":"/api/dispatch?key=LAW_SHEETS_S01"}},{"key":"LAW_WORK_W01","type":"http","method":"GET","category":"law","enabled":true,"contract":"# WHAT: Work exists only as a canonical task object.","input_schema":null,"examples":"[\"\"]","authority_required":false,"representations":{"article":"/a/directory/LAW_WORK_W01","json":"/api/directory/LAW_WORK_W01","skill":"/api/directory/LAW_WORK_W01?format=skill","oip_contract":"/api/dispatch?key=LAW_WORK_W01"}},{"key":"LOOP_RANGE","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: The business numbers for a named time window - a day, a week, a month, a quarter, a year, or everything.\n# WHEN_TO_USE: ANY question with a period in it. This is the default numbers tool. It reaches windows\n#   LBL_ASK cannot: 7d, 14d, 30d, 90d, ytd, 12mo, all.\n# ARGS: $1 = exactly one of:\n#   today | yesterday | 7d | 14d | 30d | 90d | mtd | last month | ytd | 12mo | all\n# WHERE EVERY NUMBER COMES FROM - say the source when you quote it:\n#   revenue_usd, orders, buyers, aov_usd, refunds_usd  -> the store's own order records, current to yesterday\n#   new_orders vs existing_orders                      -> first-time versus repeat buyers\n#   email_orders, paid_orders                          -> orders whose attribution names that channel\n#   spend_usd_source_triplewhale_live                  -> Triple Whale topline. THE ONLY CURRENT SPEND SOURCE.\n#   spend_usd_source_meta_api_STALE                    -> Meta's API. DEAD SINCE 2026-07-13.\n#   spend_usd_source_tw_pivot_STALE                    -> Triple Whale pivot. DEAD SINCE 2026-08-31.\n#   roas_on_live_spend                                 -> revenue / live spend. The one to quote.\n#   attributed_roas_on_live_spend                      -> what Triple Whale credits ads / live spend.\n# THE TWO STALE COLUMNS READ 0 FOR ANY RECENT WINDOW AND THAT ZERO IS NOT REAL - it is a dead feed.\n#   NEVER quote a ROAS computed on them. NEVER say spend was zero. last_day_with_live_spend and\n#   last_day_with_meta_api_spend tell you how current each source actually is; if asked about spend,\n#   say which source and how fresh it is.\n# days_with_data says how many days in the window actually carried a row. A missing day is absent, not zero.\n# EX: [LOOP_RANGE]ytd[/LOOP_RANGE]   [LOOP_RANGE]yesterday[/LOOP_RANGE]   [LOOP_RANGE]12mo[/LOOP_RANGE]\n[\"api/sql?q=SELECT * FROM loop_windows WHERE window=lower(trim('$1'))\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"window\": {\"type\": \"string\", \"description\": \"today|yesterday|7d|14d|30d|90d|mtd|last month|ytd|12mo|all, or FROM:TO as YYYY-MM-DD:YYYY-MM-DD\"}}, \"required\": [\"window\"], \"x-arg-order\": [\"window\"], \"description\": \"One argument: the time window.\"}","examples":"[{\"args\": [\"yesterday\"], \"note\": \"a single day\"}, {\"args\": [\"7d\"], \"note\": \"the trailing seven days including today\"}, {\"args\": [\"mtd\"], \"note\": \"this calendar month so far\"}, {\"args\": [\"last month\"], \"note\": \"the previous whole calendar month\"}, {\"args\": [\"ytd\"], \"note\": \"January 1 to today\"}, {\"args\": [\"12mo\"], \"note\": \"the trailing 365 days - LBL_ASK cannot do this\"}, {\"args\": [\"2026-01-01:2026-03-31\"], \"note\": \"an explicit range\"}]","authority_required":false,"representations":{"article":"/a/directory/LOOP_RANGE","json":"/api/directory/LOOP_RANGE","skill":"/api/directory/LOOP_RANGE?format=skill","oip_contract":"/api/dispatch?key=LOOP_RANGE"}},{"key":"CUSTOMER_ACTIONS","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: The action list - customers grouped by what the scoring says to do with them and on which channel, with the lifetime revenue behind each group. This is the answer to 'who should we contact and how'.\n# WHEN_TO_USE: planning a campaign, a win-back, or deciding where ad money goes.\n# ARGS: none.\n# EX: [CUSTOMER_ACTIONS][/CUSTOMER_ACTIONS]\n[\"api/sql?q=SELECT recommended_message, recommended_channel, COUNT(*) customers, CAST(SUM(ltv_cents)/100 AS INT) lifetime_usd, CAST(AVG(retargeting_score) AS INT) avg_retargeting FROM customer_scores WHERE lifetime_orders>0 GROUP BY recommended_message, recommended_channel ORDER BY lifetime_usd DESC\"]","input_schema":"{\"type\": \"object\", \"properties\": {}, \"x-arg-order\": [], \"description\": \"No arguments.\"}","examples":"[{\"args\": [], \"note\": \"the whole action matrix with revenue at stake per group\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_ACTIONS","json":"/api/directory/CUSTOMER_ACTIONS","skill":"/api/directory/CUSTOMER_ACTIONS?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_ACTIONS"}},{"key":"CUSTOMER_BY_PHONE","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: Find a person by PHONE, email or name across the platform's 14,893 person records - the ones loop_customer does not carry, because it only holds people who bought. Returns identity, location and membership tier.\n# WHEN_TO_USE: someone gives you a phone number, or a name that CUSTOMER_FIND missed. A person here may never have ordered; use CUSTOMER_PROFILE with the primary_email to see whether they did.\n# ARGS: $1 = a phone fragment (digits only, no + or dashes), an email fragment, or a name.\n# EX: [CUSTOMER_BY_PHONE]4158186483[/CUSTOMER_BY_PHONE]\n[\"api/sql?q=SELECT person_id, primary_email, primary_phone, first_name, last_name, city, state, country, membership_tier, first_seen_at, last_seen_at FROM persons WHERE instr(COALESCE(primary_phone,''), '$1') > 0 OR instr(lower(COALESCE(primary_email,'')), lower('$1')) > 0 OR instr(lower(COALESCE(first_name,'')||' '||COALESCE(last_name,'')), lower('$1')) > 0 LIMIT 20\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"identifier\": {\"type\": \"string\", \"description\": \"phone digits, email fragment, or name\"}}, \"required\": [\"identifier\"], \"x-arg-order\": [\"identifier\"], \"description\": \"One argument: the identifier to search on.\"}","examples":"[{\"args\": [\"4158186483\"], \"note\": \"a phone number, digits only\"}, {\"args\": [\"megankistler@gmail.com\"], \"note\": \"an email\"}, {\"args\": [\"Megan\"], \"note\": \"a first or last name\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_BY_PHONE","json":"/api/directory/CUSTOMER_BY_PHONE","skill":"/api/directory/CUSTOMER_BY_PHONE?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_BY_PHONE"}},{"key":"CUSTOMER_EVENTS","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: One customer's actual Klaviyo event stream - the newest 60 events with timestamps, not the count CUSTOMER_PROFILE returns. What they opened, clicked, viewed and abandoned.\n# WHEN_TO_USE: after CUSTOMER_PROFILE, whenever the question is what someone has been DOING - 'is she still engaging', 'why did he stop', pre-purchase intent, a churn post-mortem.\n# ARGS: $1 = their exact email.\n# EX: [CUSTOMER_EVENTS]someone@example.com[/CUSTOMER_EVENTS]\n[\"api/sql?q=SELECT e.datetime, e.metric_name, e.event_properties FROM klaviyo_events e JOIN persons p ON p.person_id = e.person_id WHERE instr(lower(COALESCE(p.primary_email,'')), lower('$1')) > 0 ORDER BY e.datetime DESC LIMIT 60\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"email\": {\"type\": \"string\", \"description\": \"the customer's exact email\"}}, \"required\": [\"email\"], \"x-arg-order\": [\"email\"], \"description\": \"One argument: the exact email.\"}","examples":"[{\"args\": [\"megankistler@gmail.com\"], \"note\": \"exact email - returns their newest 60 events\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_EVENTS","json":"/api/directory/CUSTOMER_EVENTS","skill":"/api/directory/CUSTOMER_EVENTS?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_EVENTS"}},{"key":"CUSTOMER_FIND","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: Find a customer by ANY fragment — part of an email, part of a name, a person_id, a klaviyo profile id. Returns up to 25 matches ranked by lifetime value, so a partial or a misspelling still lands.\n# WHEN_TO_USE: someone asks about a person and you do not have their exact email. ALWAYS run this before CUSTOMER_PROFILE unless you were handed an exact address.\n# NOT FOR PHONE: loop_customer holds no phone number. Phone lookup needs CUSTOMER_BY_PHONE, which reads the person records on the platform.\n# ARGS: $1 = any fragment (name, email, id).\n# EX: [CUSTOMER_FIND]megan[/CUSTOMER_FIND]\n[\"SELECT email, name, orders, ROUND(revenue_cents/100.0,2) lifetime_usd, first_order, last_order, CAST(julianday('now') - julianday(last_order) AS INT) days_since_last, person_id FROM loop_customer WHERE lower(email) LIKE lower('%$1%') OR lower(COALESCE(name,'')) LIKE lower('%$1%') OR lower(COALESCE(person_id,'')) LIKE lower('%$1%') OR lower(COALESCE(klaviyo_profile_id,'')) LIKE lower('%$1%') ORDER BY revenue_cents DESC LIMIT 25\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"fragment\": {\"type\": \"string\", \"description\": \"any part of a name, email, person id or klaviyo profile id\"}}, \"required\": [\"fragment\"], \"x-arg-order\": [\"fragment\"], \"description\": \"One argument: the fragment to search for.\"}","examples":"[{\"args\": [\"megan\"], \"note\": \"a name fragment \\u2014 returns every customer whose name or email contains it, richest first\"}, {\"args\": [\"@gmail.com\"], \"note\": \"a domain fragment\"}, {\"args\": [\"person_887a73a4\"], \"note\": \"a person id fragment\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_FIND","json":"/api/directory/CUSTOMER_FIND","skill":"/api/directory/CUSTOMER_FIND?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_FIND"}},{"key":"CUSTOMER_HEALTH_LIST","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: The customers in one health class, worst first — the churn inventory as a list. Classes: 'gone', 'lapsed', 'slipping', 'one-and-done', 'new, one order', 'on cadence'.\n# WHEN_TO_USE: \"who has fallen off\", \"who is slipping\", \"show me the churn\", a win-back list.\n# ARGS: $1 = the health class exactly as spelled above.\n# EX: [CUSTOMER_HEALTH_LIST]slipping[/CUSTOMER_HEALTH_LIST]\n[\"SELECT email, name, orders, ROUND(revenue_cents/100.0,2) lifetime_usd, last_order, CAST(julianday('now') - julianday(last_order) AS INT) days_since, ROUND((julianday(last_order)-julianday(first_order))/(orders-1),1) own_cadence_days, cancelled, subscription_signals, klaviyo_events FROM loop_customer WHERE last_order IS NOT NULL AND first_order IS NOT NULL AND orders > 1 AND (CASE WHEN julianday('now') - julianday(last_order) > 6.0*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'gone' WHEN julianday('now') - julianday(last_order) > 3.0*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'lapsed' WHEN julianday('now') - julianday(last_order) > 1.5*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'slipping' ELSE 'on cadence' END) = '$1' ORDER BY revenue_cents DESC LIMIT 100\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"health\": {\"type\": \"string\", \"enum\": [\"on cadence\", \"slipping\", \"lapsed\", \"gone\"], \"description\": \"the health class to list\"}}, \"required\": [\"health\"], \"x-arg-order\": [\"health\"], \"description\": \"One argument: the health class.\"}","examples":"[{\"args\": [\"slipping\"], \"note\": \"customers past 1.5x their own order gap\"}, {\"args\": [\"gone\"], \"note\": \"customers past 6x their own order gap\"}, {\"args\": [\"lapsed\"], \"note\": \"customers past 3x their own order gap\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_HEALTH_LIST","json":"/api/directory/CUSTOMER_HEALTH_LIST","skill":"/api/directory/CUSTOMER_HEALTH_LIST?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_HEALTH_LIST"}},{"key":"CUSTOMER_PROFILE","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: One customer's whole record, plus how they are behaving against THEIR OWN order cadence — lifetime, AOV, first and last order, days since, their own average gap, how many of their own cycles they are overdue by, a health class, cancellations, refunds, subscription history, klaviyo event volume, and where they came from.\n# WHEN_TO_USE: \"tell me about <person>\", \"what is going on with this customer\", any support or account question.\n# ARGS: $1 = their EXACT email (use CUSTOMER_FIND first if you only have a fragment).\n# THEN: for the actual klaviyo event stream rather than its count, follow with CUSTOMER_EVENTS.\n# EX: [CUSTOMER_PROFILE]someone@example.com[/CUSTOMER_PROFILE]\n[\"SELECT email, name, orders, ROUND(revenue_cents/100.0,2) lifetime_usd, ROUND(revenue_cents/100.0/NULLIF(orders,0),2) aov_usd, first_order, last_order, CAST(julianday('now') - julianday(last_order) AS INT) days_since_last_order, CASE WHEN orders > 1 THEN ROUND((julianday(last_order) - julianday(first_order))/(orders-1),1) END own_cadence_days, CASE WHEN orders > 1 AND julianday(last_order) > julianday(first_order) THEN ROUND((julianday('now') - julianday(last_order))/((julianday(last_order) - julianday(first_order))/(orders-1)),2) END cycles_overdue, CASE WHEN orders < 2 THEN (CASE WHEN julianday('now') - julianday(last_order) > 90 THEN 'one-and-done' ELSE 'new, one order' END) WHEN julianday(last_order) <= julianday(first_order) THEN 'same-day repeat' WHEN julianday('now') - julianday(last_order) > 6.0*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'gone' WHEN julianday('now') - julianday(last_order) > 3.0*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'lapsed' WHEN julianday('now') - julianday(last_order) > 1.5*((julianday(last_order)-julianday(first_order))/(orders-1)) THEN 'slipping' ELSE 'on cadence' END health, cancelled, refunded, ROUND(100.0*cancelled/NULLIF(orders+cancelled,0),1) cancel_rate_pct, subscription_signals, klaviyo_events, coupon_orders, affiliate_orders, utm_source, ref, person_id, klaviyo_profile_id, updated_at FROM loop_customer WHERE lower(email) = lower('$1')\"]","input_schema":"{\"type\": \"object\", \"properties\": {\"email\": {\"type\": \"string\", \"description\": \"the customer's exact email address\"}}, \"required\": [\"email\"], \"x-arg-order\": [\"email\"], \"description\": \"One argument: the exact email.\"}","examples":"[{\"args\": [\"someone@example.com\"], \"note\": \"exact email \\u2014 the whole record plus health against their own cadence\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_PROFILE","json":"/api/directory/CUSTOMER_PROFILE","skill":"/api/directory/CUSTOMER_PROFILE?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_PROFILE"}},{"key":"CUSTOMER_SCORE_REFRESH","type":"fn","method":null,"category":"loop","enabled":true,"contract":"# WHAT: Recompute customer_scores for everyone - intent, relationship and retargeting scores, value tier, recommended channel and recommended message, with score_reason_json carrying the components.\n# WHEN_TO_USE: nightly, and after any order or Klaviyo sync. Idempotent (ON CONFLICT updates).\n# HOW IT SCORES: intent = checkout 40, click 20, view 15, open 10, cart 15 - each only if inside 30 days. relationship = orders x4 (max 40) + months tenure x2 (max 20) + opens/5 (max 20) + clicks (max 20), minus 30 for an unsubscribe and 50 for a spam complaint. retargeting = value tier (0-40) + how late they are against their OWN cadence (0-30) + whether they still engage (0-30), forced to 0 if suppressed.\n# NOTE: this row READS through the viewer door, which is read-only, so it reports the pass rather than running it. The write path is scripts/refresh-customer-scores.sh via wrangler against loop-data-platform.\n# ARGS: none.\n# EX: [CUSTOMER_SCORE_REFRESH][/CUSTOMER_SCORE_REFRESH]\n[\"api/sql?q=SELECT COUNT(*) scored, SUM(CASE WHEN intent_score>0 THEN 1 ELSE 0 END) with_intent, SUM(CASE WHEN retargeting_score>=50 THEN 1 ELSE 0 END) worth_retargeting, SUM(suppress_ads) suppressed, MAX(updated_at) last_scored FROM customer_scores\"]","input_schema":"{\"type\": \"object\", \"properties\": {}, \"x-arg-order\": [], \"description\": \"No arguments.\"}","examples":"[{\"args\": [], \"note\": \"returns how many people are scored and when the pass last ran\"}]","authority_required":false,"representations":{"article":"/a/directory/CUSTOMER_SCORE_REFRESH","json":"/api/directory/CUSTOMER_SCORE_REFRESH","skill":"/api/directory/CUSTOMER_SCORE_REFRESH?format=skill","oip_contract":"/api/dispatch?key=CUSTOMER_SCORE_REFRESH"}},{"key":"LOOP_CHANNELS","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, channel mix\n# WHAT: Orders, revenue, share, customers, new and existing customers, new-customer revenue, META20 orders and Triple Whale Meta credits for each channel in a window, plus affiliates by name. Each order sits in one channel, first match wins: affiliates, meta_ads, klaviyo, direct, organic, google_ads, no_click, not_seen, other.\n# WHEN_TO_USE: where orders came from, how much the affiliates brought, which affiliate brought the most.\n# ARGS: $1 = from, $2 = to. At most 100 days. Dates are YYYY-MM-DD, or today, yesterday, or -N for N store days ago.\n# EX: [LOOP_CHANNELS]-29|today[/LOOP_CHANNELS]","input_schema":"{\"type\": \"object\", \"properties\": {\"from\": {\"type\": \"string\", \"description\": \"first store day\"}, \"to\": {\"type\": \"string\", \"description\": \"last store day\"}}, \"required\": [\"from\", \"to\"], \"x-arg-order\": [\"from\", \"to\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_CHANNELS","json":"/api/directory/LOOP_CHANNELS","skill":"/api/directory/LOOP_CHANNELS?format=skill","oip_contract":"/api/dispatch?key=LOOP_CHANNELS"}},{"key":"LOOP_CHANNEL_ORDERS","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, the orders behind one channel\n# WHAT: Every order of one channel in a window, newest first: date, order, buyer, total, new or existing, coupon, affiliate marks, Triple Whale's Meta credit and click age.\n# WHEN_TO_USE: which customers the affiliates or Meta brought in a window.\n# ARGS: $1 = channel (affiliates, meta_ads, klaviyo, direct, organic, google_ads, no_click, not_seen, other), $2 = from, $3 = to. Dates are YYYY-MM-DD, or today, yesterday, or -N for N store days ago.\n# EX: [LOOP_CHANNEL_ORDERS]affiliates|-6|today[/LOOP_CHANNEL_ORDERS]","input_schema":"{\"type\": \"object\", \"properties\": {\"channel\": {\"type\": \"string\", \"description\": \"channel id\"}, \"from\": {\"type\": \"string\", \"description\": \"first store day\"}, \"to\": {\"type\": \"string\", \"description\": \"last store day\"}}, \"required\": [\"channel\", \"from\", \"to\"], \"x-arg-order\": [\"channel\", \"from\", \"to\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_CHANNEL_ORDERS","json":"/api/directory/LOOP_CHANNEL_ORDERS","skill":"/api/directory/LOOP_CHANNEL_ORDERS?format=skill","oip_contract":"/api/dispatch?key=LOOP_CHANNEL_ORDERS"}},{"key":"LOOP_DAILY","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, day by day\n# WHAT: One line per Loop store day (America/Chicago) from..to: orders, revenue, existing and new customers, new customers split affiliate / META20 / other, Meta spend, the value Meta claims, and four Meta ROAS readings (Meta's own claim, orders Triple Whale credits to Meta, new customers without affiliate evidence as a ceiling, new META20 customers as a floor). Ends with totals and how to read every column. The same figures as the Console's Loop > Daily view.\n# WHEN_TO_USE: any question about a stretch of days: how did last week go, which days did Meta claim the most, new versus existing, affiliates versus Meta.\n# ARGS: $1 = from, $2 = to. At most 100 days per call. Dates are YYYY-MM-DD, or today, yesterday, or -N for N store days ago.\n# RETURNS: plain text, a table and its reading notes. \"-\" means not measured, never zero.\n# EX: [LOOP_DAILY]-7|yesterday[/LOOP_DAILY]","input_schema":"{\"type\": \"object\", \"properties\": {\"from\": {\"type\": \"string\", \"description\": \"first store day\"}, \"to\": {\"type\": \"string\", \"description\": \"last store day\"}}, \"required\": [\"from\", \"to\"], \"x-arg-order\": [\"from\", \"to\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_DAILY","json":"/api/directory/LOOP_DAILY","skill":"/api/directory/LOOP_DAILY?format=skill","oip_contract":"/api/dispatch?key=LOOP_DAILY"}},{"key":"LOOP_DAY_ORDERS","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, every order on one day\n# WHAT: Each order on one Loop store day: order id, buyer name and email, status, total, new or existing, lifetime orders, the person's strongest affiliate evidence, coupon code and its class, whether Loop's feed marks the order as an affiliate's, whether Triple Whale credits Meta and how old the click was, last click, Meta landing-page and affiliate-link visits.\n# WHEN_TO_USE: who bought on a day, which new customers came from affiliates, what sits behind a day's Meta number.\n# ARGS: $1 = the store day. Dates are YYYY-MM-DD, or today, yesterday, or -N for N store days ago.\n# EX: [LOOP_DAY_ORDERS]yesterday[/LOOP_DAY_ORDERS]","input_schema":"{\"type\": \"object\", \"properties\": {\"day\": {\"type\": \"string\", \"description\": \"the store day\"}}, \"required\": [\"day\"], \"x-arg-order\": [\"day\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_DAY_ORDERS","json":"/api/directory/LOOP_DAY_ORDERS","skill":"/api/directory/LOOP_DAY_ORDERS?format=skill","oip_contract":"/api/dispatch?key=LOOP_DAY_ORDERS"}},{"key":"LOOP_PERSON","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, one customer\n# WHAT: One Loop customer as plain text: lifetime orders and value, subscription, Triple Whale acquisition, Klaviyo counters and consent, the build's score and suggested message, every order (newest 25) with its last click, the Meta click behind it, affiliate or coupon and items, and their latest Klaviyo events.\n# WHEN_TO_USE: tell me about a customer, what did this person buy, did an affiliate bring them, what have they done in Klaviyo.\n# ARGS: $1 = their exact email or person_id. For a partial name or email, find them first with LOOP_SQL on persons.\n# EX: [LOOP_PERSON]someone@example.com[/LOOP_PERSON]","input_schema":"{\"type\": \"object\", \"properties\": {\"person\": {\"type\": \"string\", \"description\": \"exact email or person_id\"}}, \"required\": [\"person\"], \"x-arg-order\": [\"person\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_PERSON","json":"/api/directory/LOOP_PERSON","skill":"/api/directory/LOOP_PERSON?format=skill","oip_contract":"/api/dispatch?key=LOOP_PERSON"}},{"key":"LOOP_SQL","type":"http","method":"GET","category":"loop","enabled":true,"contract":"# TITLE: Loop, read-only SQL\n# WHAT: Runs one SELECT (or WITH) on Loop's data platform and returns the rows as JSON. The door refuses anything that writes and adds its own row limit.\n# WHEN_TO_USE: a question the LOOP_ tools do not answer, or finding a person by part of a name or email.\n# TABLES: orders (source_order_id, person_id, email, order_created_at, order_date, status, total_cents), persons (person_id, first_name, last_name, primary_email, primary_phone), order_items, order_affiliate (source_order_id, coupon_code, is_affiliate, affiliate_ref, affiliate_utm_source, store_day), coupon_code_class (code, class, owner), order_attribution (source_order_id, first_click_source, last_click_source, lpc_meta_click_at, journey_meta_landings, journey_affiliate_redirects), meta_attributed_orders (source_order_id), klaviyo_events (person_id, metric_name, datetime), subscriptions, customer_scores, tw_daily_topline (date, metric_id, value).\n# RULES: money is in cents. Leave out orders whose status is Cancelled, Declined or Incomplete. Select only the columns you need.\n# ARGS: $1 = the SQL.\n# EX: [LOOP_SQL]SELECT person_id, first_name, last_name, primary_email FROM persons WHERE primary_email LIKE '%smith%' LIMIT 10[/LOOP_SQL]","input_schema":"{\"type\": \"object\", \"properties\": {\"sql\": {\"type\": \"string\", \"description\": \"one SELECT or WITH statement\"}}, \"required\": [\"sql\"], \"x-arg-order\": [\"sql\"], \"additionalProperties\": false}","examples":null,"authority_required":true,"representations":{"article":"/a/directory/LOOP_SQL","json":"/api/directory/LOOP_SQL","skill":"/api/directory/LOOP_SQL?format=skill","oip_contract":"/api/dispatch?key=LOOP_SQL"}}]},"ontology":{"conformance_group":"writing","inferred_from":["loop","law"],"relationships":[],"sources":[]},"article_object_law":{"id":"law:article-object","statement":"Every article is an ontological object with typed human, model, directory, API, source, relationship, conformance, failure, and receipt expressions.","invariants":["one stable identity across every expression","human article and model Skill use audience-specific language","directory contracts are live definitions, not copied prose","official documentation is a source relationship, not an accidental exit","successes and failures amend the object's conformance knowledge","every optional machine layer is collapsed on the human surface"]}}