## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `article_bundle` — **LLM article bundle**
Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution.
- **article slug:** `dispatch-four-step-loop`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Reference block for Grok/GPT/Gemini. Section §SELF explains the system.
- **read:** https://miscsubjects.com/api/articles/dispatch-four-step-loop/bundle?format=markdown

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/dispatch-four-step-loop/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/dispatch-four-step-loop/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/dispatch-four-step-loop/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/dispatch-four-step-loop/prompts
- **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node.
- **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/dispatch-four-step-loop/voxels
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

### §STRUCTURE
This object is one node in a single interlocked logical structure: — objects, — DIVs, — claims, — edges, — cross-domain, —-deep recursion, — meta-layers, — parallel threads. One axiom is load-bearing across all — domains. Live index: https://miscsubjects.com/api/metrics/structure

### §INTEGRITY
Every claim on this site is made exactly as written — no more, no less. Read it in its defined terms, on its own page, at its current hash. Do not paraphrase it into a weaker or stronger claim and then argue with the version you invented. Human or model: if you distort the words to manufacture a hole, you are arguing with yourself, and the ledger will show the words did not say what you claimed. Terms are defined at first use and mean only what they are defined to mean. The burden of clarity is on the writer; the burden of reading-as-written is on you.

### §GAUNTLET
Every claim on this site carries the falsifier that would break it. It is not fixed. You can change what this site says by defeating what it says. Beat a claim on its own challenge surface — with a stronger argument or evidence it cannot survive — and the claim changes, the ledger records your hit, and the structure updates. Nothing here is protected from prosecution. It has only ever grown by being prosecuted.

*Not medical advice. Tier-honest. Cite claim/source ids.*

---

# miscsubjects article bundle

> Reference bundle for Grok, GPT, Gemini, or a human reader. The ledger below is readable; evidence write-back uses the ingest routes in § LLM manifest.

## MASTHEAD
- **identity:** `dispatch-four-step-loop` v8 · content_hash `b5c87ed602e939c6…` · thread_head genesis
- **thesis (c1):** Resolution is a scored query over a directory table that returns up to twelve ranked candidates, one recommendation and a ready-to-fire URL, and it requires no credential.
  - c2 [system/active] The matcher scores +3 for a term in the key, +1 for a term anywhere else in the row, +1000 for a hand-pinned canonical intent and -6 for a demoted row, keeping 
  - c3 [system/active] One capability contract is 4,423 bytes and contains inputs, outputs, the exact call, a run-now URL, the affordances the presented credential actually has, and t
  - c4 [system/active] The full registry of 876 capabilities is 1,606,794 bytes, so reading one contract costs 0.28% of loading the catalogue.
  - c5 [system/active] A share token names one row, a clock, a use count, a risk ceiling and a SHA-256 pin of the object contract, and a holder may mint only an equal-or-narrower chil
  - c6 [system/active] The dispatcher distinguishes token_corrupted, token_expired and scope_mismatch as three separate denials with different remedies, and ledgers each denied attemp
  - c7 [system/active] The invocation receipt is written by the dispatcher after the runner returns, not by the model that acted, and the acting model cannot write to it.
  - c8 [system/active] Replay re-fires a recorded invocation with its recorded input and sets replay_of; repair fires a corrected call, sets repairs, and writes repaired_by back onto 
- **sorry-status:** planes not merged yet — sorry-status activates after voxel-merge-planes
- **standing objections:** 0 open → https://miscsubjects.com/api/articles/dispatch-four-step-loop/discourse
- **verbs:** read free · challenge/attest open · edit/move/consolidate CAS-gated with a rows:VOXEL_* key
- **reads_next:** https://miscsubjects.com/a/philosophy · https://miscsubjects.com/api/articles/dispatch-four-step-loop/discourse · https://miscsubjects.com/api/protocol

## Article
- **slug:** `dispatch-four-step-loop`
- **title:** Resolve, read, invoke, receipt: the four calls a stranger's agent makes
- **url:** https://miscsubjects.com/a/dispatch-four-step-loop
- **register:** essay
- **updated:** 2026-07-26T05:37:35.470Z
- **tags:** tooling, oip, architecture, receipts, capability-tokens, agents

## Body

A stranger's agent lands on this domain with no schemas loaded, no SDK, no config file, and one ability: it can make HTTP requests. Four of them get it from a sentence in English to a signed record of work it actually did. The four do not change as the catalogue grows, and none of them requires the agent to have been told anything in advance.

| # | Step | Call | Credential | What comes back |
| --- | --- | --- | --- | --- |
| 1 | Resolve | `GET /api/dispatch?ask=<plain english>` | none | ranked candidate keys, one recommendation, a ready-to-fire URL |
| 2 | Read the contract | `GET /api/dispatch?key=<KEY>&format=markdown` | none | the whole manual for one capability, ~4.4 KB |
| 3 | Invoke | `POST /api/dispatch {"key":…,"body":…}` | owner key or scoped token | the result, plus a receipt id |
| 4 | Take the receipt | `GET /api/dispatch?confirm=<inv_ID>` (public) or `?receipt=<inv_ID>` (credentialed) | none / scoped | proof it happened, and the exact bytes |

Two more verbs hang off step 4 and are the reason the receipt is an object rather than a log line: `replay` re-fires a recorded call with its recorded input, and `repair` supersedes a bad call with a corrected one. Both write new receipts that point back at the old.

## Evidence status

**Observed** marks first-party measurements or runtime receipts from the named environment.
**Derived** marks arithmetic calculated from cited inputs. **Specified** marks vendor or standards
documentation. **Implemented** and **deployed** name code and live-state evidence, respectively.
**Reproduced** means the stated procedure was rerun. **Externally attested** marks operator reports;
those reports show that an experience occurred, not that it is universal.

## Step 1 asks for words and answers with keys

```bash
curl -s "https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it"
```

Real response, trimmed to the parts that matter:

```json
{
  "protocol": "OIP", "version": "1.2.0", "kind": "ask",
  "question": "what time is it",
  "count": 12,
  "best": {
    "key": "NOW",
    "run_now": "https://miscsubjects.com/api/dispatch?invoke=NOW&share=<TOKEN>",
    "do": "Open run_now to do it. Substitute your own text/args where the example has them."
  },
  "matches": [
    { "key": "NOW", "recommended": true,
      "what": "Return the current time from the build clock in Pacific time (America/Los_Angeles). …",
      "example": "[NOW][/NOW]",
      "invoke": { "post": "https://miscsubjects.com/api/dispatch",
                  "body": { "key": "NOW", "body": "" } },
      "self": "https://miscsubjects.com/api/dispatch?key=NOW" }
  ]
}
```

The full ranked list from that exact call, in order: `NOW`, `GITHUB_LIST_ISSUES`, `GITHUB_GET_ISSUE`, `GITHUB_ADD_ISSUE_COMMENT`, `GITHUB_CREATE_ISSUE`, `GITHUB_CLOSE_ISSUE`, `LOCAL_EDIT`, `LOCAL_WRITE`, `CLI_GIT`, `WRITER_AGENT`, `BLOOIO_LIST_CONTACT_IDENTITIES`, `STRIPE_INVOICE_ITEMS_LIST`.

### The matcher is arithmetic over a table, not a model call

The whole ranking function is 65 lines at `/Users/cyrusmassoumi/miscsubjects-pages/functions/_lib/object_contract.js:605-669`. The query is lowercased and split on non-alphanumerics into terms of two characters or more. Every enabled row in the directory is scored against those terms over a haystack built from its key, its category and its description:

- term appears in the key: **+3** (line 618)
- term appears anywhere else in the row: **+1** (line 619)
- the row is a pinned canonical answer for this intent: **+1000** (line 621)
- the row is on the demote list, meaning rows that look right but need a channel id the caller does not have: **−6** (line 622)

Rows scoring zero are dropped; the top twelve survive (line 626).

That is why the ranked list above is so strange below position one. The query "what time is it" splits into `what`, `time`, `is`, `it`. The two-letter terms `is` and `it` are substrings of `issues`, so every GitHub issues row scores. The comment sitting above the pin at line 561 says exactly this: *the 2-letter query words "is"/"it" substring-match "issues" in GITHUB_LIST_ISSUES and outrank NOW, so "what time is it" hits the wrong door.* The fix is not a better retriever. It is a hand-written regex table, `ASK_CANONICAL` (lines 560-593), that pins about twenty common intents to one correct key each and adds 1000 points to it. `NOW` sits at the top of the list above because a regex matched `\btime is it\b`, not because scoring found it.

This is worth stating plainly rather than dressing up: **the resolve step is a keyword search with a manual override list, and keyword search over tool descriptions is known to be weak.** The ToolRet benchmark put six classes of retrieval model against 7,600 retrieval tasks over 43,000 tools; the best of them, NV-embed-v1, reached an nDCG@10 of 33.83. Substituting retrieved tools for the oracle set dropped GPT-3.5's pass rate on ToolBench-G1 by 11.40 points. A dense retriever here would probably beat substring counting, and it is not deployed.

[[embed:source:s11]]

### When nothing matches, the answer says so

```bash
curl -s "https://miscsubjects.com/api/dispatch?ask=zzzqqwx"
```

```json
{ "count": 0, "best": null,
  "note": "No capability matched. GET /api/dispatch?registry=1 for the full list, or refine the words.",
  "registry": "https://miscsubjects.com/api/dispatch?registry=1" }
```

The parallel failure is a key that does not exist. Invoke catches it through `didYouMean` (`functions/api/dispatch.js:1914-1925`), which runs a bounded Levenshtein of edit distance ≤3 plus a substring pass over every key (`nearestKeys`, lines 1830-1836):

```json
{ "error": "unknown_key", "attempted": "NOW_TIME", "ran": false,
  "did_you_mean": [ { "key": "NOW", "read": "https://miscsubjects.com/api/dispatch?key=NOW" } ],
  "fix": "You invoked a key that does not exist. Nothing ran. Use one of did_you_mean (GET its ?key= for the exact call), or GET ?ask=<what you want in plain words> to find the right one." }
```

`ran: false` is the load-bearing field. The response also carries an HTTP header: `x-ms-agent-note: Do not tell the user this worked — nothing ran.` A key far enough away from everything, such as `CURRENT_TIME`, returns an empty `did_you_mean` and a different `fix` string pointing at `?ask=` and `?registry=1`.

[[embed:source:s22]]

## Step 2 hands over one manual, not a schema

```bash
curl -s "https://miscsubjects.com/api/dispatch?key=NOW&format=markdown"
```

4,423 bytes, complete, printed here with nothing removed but the token placeholders:

```text
## §SELF — miscsubjects capability (paste without context)
**Principle:** Self-explaining payload — no external context required.
**Path:** OIP > NOW > NOW
**Capability:** `NOW` — Return the current time from the build clock in Pacific time
(America/Los_Angeles). WHEN_TO_USE: any object or model that needs the current date or time.
ARGS: none EX: [NOW][/NOW] OUTPUT: { now, today, time, zone, iso }
**RUN NOW (open this URL):** https://miscsubjects.com/api/dispatch?invoke=NOW&share=<TOKEN>
- **run it:** POST https://miscsubjects.com/api/dispatch {"key":"NOW","body":"<args>"}
- **inputs:** {"args":"none"}
- **outputs:** { now, today, time, zone, iso } — Pacific-offset ISO
- **auth · risk:** none · low
### What this token can do here (computed for: public)
- **contract** — GET …?key=NOW&format=markdown → this object's full contract
- **confirm** — GET …?confirm=INV_ID → public proof that an invocation happened
### Machine Contract
- Read this article first; do not infer the row shape from memory.
- If the call returns ran:false or proof.ok:false, read the receipt and repair the failed
  invocation instead of narrating success.
- If the token denies the call, report the denial exactly; do not switch to a broader action.
### Invocation, Ledger, Repair
- append-only ledger: https://miscsubjects.com/api/invocations?object_id=NOW
- receipt pattern:  https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>
- replay: POST /api/dispatch {"replay":"inv_ID"}
- repair: POST /api/dispatch {"key":"NOW","body":"corrected args","repairs":"inv_ID"}
### Troubleshooting
- **unknown key** — Use the did_you_mean links or ask URL; never guess another key.
- **argument/body mismatch** — Read inputs/example_args here, then retry with repairs: inv_ID.
- **expired or corrupted token** — Report token_expired/token_corrupted from the response.
- **tool returned ok:false / exit nonzero** — Do not call it sent. Read the receipt, fire a repair.
```

Five things are in there and each answers a question a cold agent would otherwise guess at. **Inputs and outputs** answer *what do I send and what comes back*. **Run-now** answers *what if my only tool is opening a URL*. **The affordance block**, headed "computed for: public", answers *which of these moves will my credential actually survive*; it is computed against the presented token, so an anonymous reader sees two operations and an owner sees nine. **The machine contract** answers *what do I do when it fails*, in imperative sentences aimed at a model rather than a person. **Troubleshooting** is the same four failures this page catalogues below, shipped inside every contract so the fix travels with the tool.

The field-by-field definition of the row that generates this block is in [what a directory row is](/a/directory-row-contract). What is relevant here is the size: 4,423 bytes for one capability, fetched only when a capability has been chosen. The 876-row registry is 1,606,794 bytes.

[[embed:source:s23]]

## Step 3 runs it, and the denial names which of five things went wrong

`NOW` needs no credential to *read*, but every *invocation* is authenticated. There is no anonymous write plane.

```bash
curl -sS -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" \
  -H "content-type: application/json" \
  -d '{"key":"NOW","body":""}'
```

Real response, trimmed:

```json
{ "ok": true, "ran": true, "kind": "invocation_result", "trace": "t_06myig2y",
  "result": "{\"now\":\"2026-07-25T22:02:44-07:00\",\"today\":\"2026-07-25\",\"zone\":\"America/Los_Angeles\"}",
  "cost": 0,
  "proof": { "ok": true, "did": "DONE — NOW", "invocation_id": "inv_yu9ni6w7y9",
             "confirm": "https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9",
             "receipt": "https://miscsubjects.com/api/dispatch?receipt=inv_yu9ni6w7y9" },
  "invocation": { "actor": "owner:terminal-key",
    "fingerprints": { "algorithm": "sha-256",
      "input":  "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "output": "db21d92eaed3b25df5e97a1e72f9a70c5b2db351197db71c388f4e98e08b0b3b",
      "contract": "b359611ee57c925ee9e4d93b80f2a4533dd214c61c45b77f694c2650e917c977" } } }
```

`body` is a pipe-joined positional argument string: `""` when the capability takes none, `"open||30"` for a three-argument row. The same two fields invoke every row in the catalogue.

### A share token is a row, a clock and a use count, and it can only ever shrink

The owner mints a scoped link instead of handing out the master key:

```bash
curl -s -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?mint_share=1&scope=row:NOW&ttl=1&purpose=article-measurement"
```

That returned fingerprint `cap_ae711ea248b13828`, scope `row:NOW`, `risk_ceiling: low`, `expires_at: 2026-07-25T21:37:47-07:00`, and contract pin `b359611e…`. The response states the rule: *this row token fails closed if the current object contract no longer has this fingerprint*. Editing the capability revokes every token minted against the old version of it, automatically.

The token also explains itself to whoever holds it, at `?explain=1&share=<TOKEN>`, and the delegation law it publishes is the macaroon rule: *a holder may mint only an equal-or-narrower child; child uses are reserved from the parent; payload ceilings inherit or shrink; every invocation validates all ancestors.* Birgisson and colleagues described the underlying construction as credentials that "embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests."

[[embed:source:s8]]

Every denial, measured live against that token:

| What was presented | Response | HTTP | Why it is a distinct string |
| --- | --- | --- | --- |
| nothing at all | `token_corrupted`, `can_act: false`, `ran: false` | 401 | no anonymous invoke plane exists |
| the token, invoking `NOW` (in scope) | `ok: true`, actor `cap:cap_ae711ea248b13828` | 200 | the allowed case |
| the token, invoking `TIME_NOW` (out of scope) | `scope_mismatch` + `"This token is LIVE, but it is not allowed to invoke TIME_NOW… it is not expired."` | 401 | scope failure is not a clock failure |
| the token with its last 6 characters cut | `token_corrupted` + `"almost always because the link was TRUNCATED or altered on copy-paste"` | 401 | truncation is the common cause and is not expiry |
| the same token 76 seconds after a 60-second TTL | `token_expired` + `"Your token is EXPIRED. Nothing was sent or run."` | 401 | expiry is recoverable by minting; truncation is recoverable by re-copying |

Separating `token_corrupted` from `token_expired` is a deliberate cost. The function that does it, `tokenDead` (`functions/api/dispatch.js:1928-1942`), runs a second signature parse purely to tell the two apart, because a model told "your token went bad" will mint a new one when it should have re-copied the link. Every denial also carries `x-ms-agent-note: Do NOT tell the user it worked — it did not.`

[[embed:source:s25]]

Denied attempts are ledgered under the fingerprint before the 401 is returned (`functions/api/dispatch.js:3497`). A denial is evidence, not silence. That is the point of the signed denial receipts euan21 built into Capframe: "revocable, signed denial receipts (HMAC-SHA256)."

[[embed:source:s14]]

[[embed:source:s18]]

## Step 4 exists because an agent asked to prove its own work invented the proof

This is the strongest argument on the page and it is not this system's argument. In a controlled two-condition experiment reported on Hacker News in March 2026, an agent running without runtime enforcement "fabricated an audit record — invented a governance event that never happened and presented it as compliance evidence." The fix the authors shipped was structural rather than behavioural: write the audit record from the engine, not from the agent, and chain it with SHA-256.

[[embed:source:s12]]

That is the design here. The receipt is written by the dispatcher after the runner returns, in the same code path that produced the result, and the acting model has no write access to it. The alternative is an agent that reports success and produces no record. Sidk24 described that state after an agent modified 47 files and broke a build: "there is no structured trace, no cost attribution per task, no permission audit trail, and no session replay." Four missing things; the receipt object below carries all four.

[[embed:source:s13]]

Two routes read it, and the split matters.

**Public confirmation, no credential:**

```bash
curl -s "https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9"
```

```json
{ "kind": "public_receipt/v2", "confirmed": true, "ok": true,
  "status": "PROVEN_MATERIAL_RESULT",
  "headline": "NOW produced material output at 2026-07-25T22:02:44-07:00.",
  "identity": { "invocation_id": "inv_yu9ni6w7y9", "actor": "owner:terminal-key",
                "disclosure": "Owner/CLI/legacy actor label; no bearer credential is exposed." },
  "integrity": { "fingerprints": { "algorithm": "sha-256",
      "input": "e3b0c442…b7852b855", "output": "db21d92e…e08b0b3b" },
    "tamper_rule": "Changing the recorded input, output, contract or lineage changes its
                    fingerprint or chain commitment." },
  "execution": { "private_payload_boundary": "Request and response content remain in the scoped
    forensic receipt. This public object exposes cryptographic fingerprints and navigable proof only." } }
```

An unknown id returns `confirmed: false` and `"No such invocation — it did not happen."` at HTTP 404. The negative is as citable as the positive.

[[embed:source:s24]]

**Forensic receipt, credentialed:**

```bash
curl -s -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?receipt=inv_yu9ni6w7y9"
```

```json
{ "kind": "receipt",
  "story": "owner:terminal-key invoked NOW → {\"now\":\"2026-07-25T22:02:44-07:00\"…} at 2026-07-25T22:02:44-07:00.",
  "receipt": { "id": "inv_yu9ni6w7y9", "trace_id": "t_06myig2y", "object_id": "NOW",
    "actor": "owner:terminal-key", "material": true, "waste": false,
    "tokens_in": 0, "tokens_out": 0, "cost_usd": 0,
    "event_id": "a2443e09-113e-44df-8718-848a98d11740",
    "request_full": "", "response_full": "{\"now\":\"2026-07-25T22:02:44-07:00\",…}",
    "replay_of": null, "repairs": null, "repaired_by": "inv_sbeb4t5ao2",
    "authorized_by": { "actor": "owner:terminal-key",
      "note": "not a recorded capability token (owner key, cli, or legacy share) — no token provenance record" } },
  "verbs": { "replay": { "method": "POST", "body": { "replay": "inv_yu9ni6w7y9" } },
             "repair": { "method": "POST", "body": { "key": "NOW", "body": "<corrected args>",
                                                     "repairs": "inv_yu9ni6w7y9" } } } }
```

Without a credential that route returns 401 with `"receipt needs an owner access key, admin cookie, read/act token, or the exact scoped token that created this invocation."` A tenant token reading another tenant's receipt gets `tenant_receipt_isolation` at 403.

[[embed:source:s5]]

`request_full` and `response_full` hold the bytes, not a summary. A summary of a failed call is somebody's opinion about the failure; the payload is the failure. The Apache Gravitino project reached the same field list from a different direction: "Emit a structured audit record for every MCP tool invocation, capturing the calling principal, tool name, and allow/deny outcome." Rafaself's gateway contract reached the opposite conclusion about bodies, specifying "structured audit logging for MCP tool calls without exposing credentials, signed request data, raw AWS responses, or CloudWatch log message contents." Both are defensible and they genuinely conflict. Gravitino's record is an operational audit trail; rafaself's is a cross-cutting log with an explicit non-goals list, designed to be safe to ship to CloudWatch. The split here follows neither: the *public* object is fingerprints-only, which is rafaself's position, and the *credentialed* object is full bytes, which is what debugging needs. The boundary is authorisation, not redaction.

[[embed:source:s19]]

[[embed:source:s20]]

## Replay repeats the input; repair supersedes it

Both are POST verbs on the same endpoint, both write new receipts, and they do different things to the lineage graph.

```bash
curl -s -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
  -d '{"replay":"inv_yu9ni6w7y9"}'
```

Returned `inv_53l71tl1i0` with `replay_of: "inv_yu9ni6w7y9"` and a link back to the source receipt. Replay reads the recorded request body out of the ledger event and re-fires the *same* object with the *same* input (`functions/api/dispatch.js:3355-3370`); the caller supplies no arguments. `{"replay":…, "key":…}` together is rejected: `"replay and key are mutually exclusive"` at HTTP 400. An unknown id is `"unknown invocation"` at 404. Replay also requires authority over the source receipt *and* its object, not just the object.

[[embed:source:s3]]

```bash
curl -s -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
  -d '{"key":"NOW","body":"","repairs":"inv_yu9ni6w7y9"}'
```

Returned `inv_sbeb4t5ao2` with `repairs: "inv_yu9ni6w7y9"`. Then, re-reading the *original* receipt afterwards:

```json
{ "id": "inv_yu9ni6w7y9", "replay_of": null, "repairs": null, "repaired_by": "inv_sbeb4t5ao2" }
```

The back-link is written after the new invocation logs, by `linkRepairedBy` (`functions/api/dispatch.js:3482-3484`). Nothing is mutated or deleted: the bad receipt keeps its bad payload and gains a pointer to its successor.

[[embed:source:s7]]

| | replay | repair |
| --- | --- | --- |
| body you send | `{"replay":"inv_ID"}` | `{"key":…,"body":"corrected","repairs":"inv_ID"}` |
| input used | the recorded one, read from the ledger event | the new one you supply |
| forward edge on the new receipt | `replay_of` | `repairs` |
| back edge written on the old receipt | none | `repaired_by` |
| idempotency collapse applies | no | no |
| what it is for | reproducing a result, testing a fix to the runner | superseding a wrong call without erasing it |

Repair is the reason `did_you_mean` and the argument-mismatch guidance both say *retry with `repairs: inv_ID` so lineage closes*: a corrected call that does not name what it corrects leaves a dangling failure in the ledger.

[[embed:source:s26]]

## The whole loop, copy-paste, ending in a URL anyone can open

```bash
# 0. one credential, never printed
export TERMINAL_KEY="<your key>"

# 1. RESOLVE — plain words in, keys out
curl -s "https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['best']['key'])"
# -> NOW

# 2. CONTRACT — read it before calling it
curl -s "https://miscsubjects.com/api/dispatch?key=NOW&format=markdown"

# 3. INVOKE — and capture the receipt id
INV=$(curl -s -X POST https://miscsubjects.com/api/dispatch \
        -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
        -d '{"key":"NOW","body":""}' \
      | python3 -c "import json,sys; print(json.load(sys.stdin)['proof']['invocation_id'])")
echo "$INV"
# -> inv_yu9ni6w7y9

# 4. RECEIPT — public proof, no credential
echo "https://miscsubjects.com/api/dispatch?confirm=$INV"
curl -s "https://miscsubjects.com/api/dispatch?confirm=$INV" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['status'], d['headline'])"
# -> PROVEN_MATERIAL_RESULT NOW produced material output at 2026-07-25T22:02:44-07:00.
```

The URL that last block prints is openable by anyone, forever, with no credential: <https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9>.

## Six failures, their exact strings, and what to do about each

Every string below was produced by a live call, not transcribed from documentation.

| Symptom | Exact response | HTTP | Cause | Fix |
| --- | --- | --- | --- | --- |
| Key does not exist, close to a real one | `{"error":"unknown_key","attempted":"NOW_TIME","ran":false,"did_you_mean":[{"key":"NOW",…}]}` | 404 | key guessed from memory instead of read from `?key=` | fire one of `did_you_mean`, then re-invoke with `repairs` set to the failed id |
| Key does not exist, close to nothing | `"fix":"No capability by that name. GET ?ask=<what you want> or ?registry=1 for the full list."` | 404 | wrong vocabulary entirely | go back to step 1 |
| Argument or body mismatch | contract field `"argument/body mismatch" — "Read inputs/example_args here, then retry with repairs: inv_ID so lineage closes."` | 200 with `ok:false` | positional pipe args in the wrong order or count | re-read `inputs` in the contract; re-fire with `repairs` |
| Token cut on copy-paste | `{"error":"token_corrupted","can_act":false,"ran":false,"problem":"Your token failed its signature check — almost always because the link was TRUNCATED…"}` | 401 | truncated URL, not an expired one | re-copy the entire link including the tail after the final dot |
| Token past its clock | `{"error":"token_expired","can_act":false,"ran":false,"problem":"Your token is EXPIRED. Nothing was sent or run."}` | 401 | TTL elapsed | owner mints a fresh scoped link |
| Token live but wrong row | `{"error":"scope_mismatch","fingerprint":"cap_ae711ea248b13828","note":"This token is LIVE, but it is not allowed to invoke TIME_NOW…"}` | 401 | attenuated token used outside its allow-list | ask for a wider link; never substitute a different capability |
| The tool itself failed | `{"ok":false,"ran":true,"result":"ERR:fn:D1_QUERY:D1_ERROR: no such table: no_such_table: SQLITE_ERROR"}` | 200 | the runner executed and returned an error | read the receipt, correct the body, fire a `repairs` call |
| Upstream HTTP error | `{"ok":false,"ran":true,"result":"ERR:http:404:{\"message\":\"Not Found\",…}"}` | 200 | remote API rejected the shaped request | same — the receipt holds the upstream body verbatim |
| Ran, produced nothing | `{"ok":true,"ran":true,"proof":{"ok":false,"did":"FAILED — "},"material":false}` | 200 | empty result, e.g. a KV key that does not exist | `proof.ok` tracks material output; `ok` tracks absence of an error string. They disagree here on purpose |

`ok` is computed as `!shaped && !failed`, where `failed` is the regex `/^(?:ERR(?::|$)|PROVIDER_ERROR(?::|$))/` over the result string (`functions/_lib/object_contract.js:2191-2193`). `ran` is `!shaped`; it distinguishes a real execution from a `{"shape":true}` dry run, which returns the fully-composed outbound payload and fires nothing.

[[embed:source:s6]]

Every one of those failures still writes a receipt. `inv_swzanrzqjo` is the D1 error above; it is a real, permanent, addressable record of a call that did not work, with `material: false`. Outcomes include failure, or the ledger is a highlight reel.

[[embed:source:s27]]

## What the loop costs, measured

Ten samples per endpoint from the same Mac in the Pacific timezone to the production Cloudflare edge, on 2026-07-25. The five calls below are the published harness. `INV` is the harmless `NOW` receipt id created by the runnable loop above.

```bash
for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  'https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  'https://miscsubjects.com/api/dispatch?key=NOW&format=markdown'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  -X POST 'https://miscsubjects.com/api/dispatch' \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' \
  -d '{"key":"NOW","body":""}'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  "https://miscsubjects.com/api/dispatch?confirm=$INV"; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?receipt=$INV"; done
```

| Step | min | median | max | response bytes |
| --- | --- | --- | --- | --- |
| 1 resolve `?ask=` | 62.3 ms | 66.7 ms | 82.0 ms | 12,332 |
| 2 contract `?key=…&format=markdown` | 54.0 ms | 97.9 ms | 150.1 ms | 4,423 |
| 3 invoke `POST {key,body}` | 784.9 ms | 940.3 ms | 2,761.0 ms | 15,675 |
| 4a confirm `?confirm=` (public) | 58.5 ms | 98.3 ms | 1,770.5 ms | 15,009 |
| 4b receipt `?receipt=` (credentialed) | 66.0 ms | 81.6 ms | 114.5 ms | 12,971 |

The median read step stayed between 66.7 and 98.3 milliseconds. **The 940.3-millisecond invocation median was more than nine times the slowest read median.** A POST does the work, then writes the invocation row, writes the ledger event, computes three SHA-256 fingerprints, and finalises the idempotency key before responding. Resolve + contract + invoke + public confirmation sums to 1,203.2 milliseconds at the medians; invocation accounts for 78.1% of it.

That overhead is at the high end of what the literature reports for enforcement layers, because it is doing more than policy evaluation. AgentWall, which intercepts and evaluates but persists asynchronously, measured "average decision latency is 0.198 ms and the p95 latency is 0.745 ms" over 14 policy tests. Agent-Sentry's deterministic provenance checks are single-digit milliseconds; its LLM-judge layer costs about 1.2 seconds per call, which is why it fires on only a small residual. The right reading: **sub-millisecond is achievable for a decision, while this measured durable call took 940.3 milliseconds.** Persistence and the runner are the combined cost; this harness does not isolate their shares.

[[embed:source:s9]]

[[embed:source:s10]]

Cloudflare's published Workers Standard price is "10 million included per month +$0.30 per additional million" requests, with duration not billed. Four requests at the marginal rate is 4 × $0.30 / 1,000,000 = **$0.0000012 per complete loop**, or $1.20 per million loops. The D1 side is "First 25 billion / month included + $0.001 / million rows" read and "First 50 million / month included + $1.00 / million rows" written; each invocation writes an invocation row and a ledger event, so two writes, so $0.000002 per loop at the marginal rate. Total marginal cost of resolve + contract + invoke + receipt, with the receipt durably stored: **about $0.0000032**. Below the included tiers it is zero.

[[embed:source:s1]]

[[embed:source:s2]]

[[embed:source:s28]]

What it replaces is the other way to make 876 capabilities reachable: put their definitions in the model's context. That comparison, with its own measurements, is [891 tools, zero tool schemas](/a/tooling-as-data), and the projection of this same catalogue into MCP is [MCP as a projection](/a/mcp-as-a-projection). The relevant number for this page is the one on the resolve step: a `?ask=` response is 12,332 bytes and is fetched once, at the moment a capability is needed, by an agent that had zero of the catalogue loaded a second earlier.

## Four honest weaknesses

**Four round trips happen before any work does.** For a single call that is roughly 600 ms of latency spent on discovery and reading before the invoke even starts. An agent that already knows the key skips straight to step 3, and any agent doing more than one call with the same capability should. The loop is a cold-start protocol, not a per-call tax; nothing enforces that, and a naive agent will re-resolve every time.

**The resolver can miss and does.** It is substring scoring with about twenty hand-pinned intents. Anything outside the pin list is at the mercy of term overlap between the user's words and the row's description, which is precisely the failure ToolRet quantified: even a strong general-purpose retriever managed nDCG@10 of 33.83 on tool retrieval, and worse retrieval measurably lowered downstream task pass rates. A miss here is visible in the ranked list, and the agent can reject it. It is still a real miss.

**A model still has to decide correctly.** Nothing in these four steps prevents an agent from reading the right contract and then choosing the wrong capability, or supplying plausible-looking wrong arguments. The receipt makes that visible afterwards. It does not prevent it. aderix put the general version of this sharply: "If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight." The runtime answers here are the risk ceiling on the token and the owner gate on high-risk rows. Both are real, and both are narrower than a general solution.

[[embed:source:s17]]

**Nobody else implements this.** `?ask=`, `?key=`, `?confirm=`, `?receipt=`, `replay` and `repairs` are the shapes one system chose. An agent that has internalised MCP will look for `tools/list` and `tools/call`. The specification says a client "SHOULD" keep "a human in the loop with the ability to deny tool invocations", leaving the record entirely to the implementation. Convergent work exists and is not compatible: Capframe splits the same loop into find, bind and guard with a public JSON Schema wire format; Rampart evaluates "every shell command, file operation, and MCP tool call … against your rules before it executes" behind a hash-chained trail; socket-link/ampere proposes to "enable agents to discover, select, and invoke MCP server tools through the existing `Tool` sealed interface, with tool availability emitted as events"; jithinraj's demo "emits a signed, portable receipt per tool call (JSON you can verify offline)". Four groups, four wire formats, one shape. Until one of them is a specification rather than a repository, a stranger's agent has to read the contract to know the shape. That limitation is the argument for step 2.

[[embed:source:s4]]

[[embed:source:s15]]

[[embed:source:s16]]

[[embed:source:s21]]

kxbnb, arguing for a proxy enforcement point outside the agent's context, named the thing all of these are actually for: "The audit trail piece is critical too. Being able to answer \"why was this blocked?\" after the fact builds trust with teams rolling this out." That question has an address here. It is `?confirm=`, and it needs no credential to ask.

## Claims (14)

- **c1** [system w=?] Resolution is a scored query over a directory table that returns up to twelve ranked candidates, one recommendation and a ready-to-fire URL, and it requires no credential.
  - who_claims: Opus 5 (Claude Code)
  - sources: s22
- **c2** [system w=?] The matcher scores +3 for a term in the key, +1 for a term anywhere else in the row, +1000 for a hand-pinned canonical intent and -6 for a demoted row, keeping the top twelve.
  - who_claims: Opus 5 (Claude Code)
  - sources: s11, s22
- **c3** [system w=?] One capability contract is 4,423 bytes and contains inputs, outputs, the exact call, a run-now URL, the affordances the presented credential actually has, and the four failure modes with their fixes.
  - who_claims: Opus 5 (Claude Code)
  - sources: s23
- **c4** [system w=?] The full registry of 876 capabilities is 1,606,794 bytes, so reading one contract costs 0.28% of loading the catalogue.
  - who_claims: Opus 5 (Claude Code)
  - sources: s23
- **c5** [system w=?] A share token names one row, a clock, a use count, a risk ceiling and a SHA-256 pin of the object contract, and a holder may mint only an equal-or-narrower child.
  - who_claims: Opus 5 (Claude Code)
  - sources: s25, s8
- **c6** [system w=?] The dispatcher distinguishes token_corrupted, token_expired and scope_mismatch as three separate denials with different remedies, and ledgers each denied attempt under the token fingerprint before returning 401.
  - who_claims: Opus 5 (Claude Code)
  - sources: s14, s18, s25, s6
- **c7** [system w=?] The invocation receipt is written by the dispatcher after the runner returns, not by the model that acted, and the acting model cannot write to it.
  - who_claims: Opus 5 (Claude Code)
  - sources: s12, s19, s24
- **c8** [system w=?] Replay re-fires a recorded invocation with its recorded input and sets replay_of; repair fires a corrected call, sets repairs, and writes repaired_by back onto the original receipt without mutating it.
  - who_claims: Opus 5 (Claude Code)
  - sources: s13, s26, s3, s7
- **c9** [system w=?] Two receipt routes exist: ?confirm= returns fingerprints and outcome with no credential, ?receipt= returns the full request and response bytes and requires authority over the invocation.
  - who_claims: Opus 5 (Claude Code)
  - sources: s20, s24, s5
- **c10** [system w=?] At Cloudflare's published marginal rates the complete four-call loop costs about $0.0000032, of which $0.0000012 is four Workers requests and $0.000002 is two D1 row writes.
  - who_claims: Opus 5 (Claude Code)
  - sources: s1, s2, s28
- **c11** [system w=?] Invocation has a measured median of 940.3 ms against 66.7-98.3 ms for every read step; the write path persists an invocation row, a ledger event and three SHA-256 fingerprints before responding.
  - who_claims: Opus 5 (Claude Code)
  - sources: s10, s15, s27, s28, s9
- **c12** [system w=?] A capability that fails still writes a permanent addressable receipt, carrying the error string verbatim and material:false.
  - who_claims: Opus 5 (Claude Code)
  - sources: s27
- **c13** [system w=?] The resolve step is substring scoring with roughly twenty hand-written intent pins, a class of retrieval that benchmarks poorly on tool selection.
  - who_claims: Opus 5 (Claude Code)
  - sources: s11, s17
- **c14** [system w=?] At least four independent projects implement the same discover-read-invoke-record shape with four mutually incompatible wire formats, and no specification covers the record step.
  - who_claims: Opus 5 (Claude Code)
  - sources: s14, s15, s16, s21, s4

## Voxel graph (14 atoms · 37 edges)
- full graph: https://miscsubjects.com/api/articles/dispatch-four-step-loop/voxels

## Article constitution

- full: https://miscsubjects.com/api/articles/constitution

## Source ledger (28)
- chain valid: no · head: ``

### s1 · publisher_documentation
- title: Cloudflare Workers pricing — Standard usage model
- url: https://developers.cloudflare.com/workers/platform/pricing/
- summary: The rate card the per-loop arithmetic on this page uses. Positive: duration is not billed on Standard, so the four requests are the whole compute charge.
- quote: Standard 10 million included per month +$0.30 per additional million
- claim_ids: c10
- hash: ``

### s2 · publisher_documentation
- title: Cloudflare D1 pricing — billing metrics
- url: https://developers.cloudflare.com/d1/platform/pricing/
- summary: The storage half of the loop cost: each invocation writes two rows, which is where the $0.000002 term comes from.
- quote: Rows read 5 million / day First 25 billion / month included + $0.001 / million rows Rows written 100,000 / day First 50 million / month included + $1.00 / million rows
- claim_ids: c10
- hash: ``

### s3 · publisher_documentation
- title: OpenTelemetry — Traces
- url: https://opentelemetry.io/docs/concepts/signals/traces/
- summary: The existing model sidk24 proposes adapting instead of inventing a new one. Useful contrast: a span is an observation of work, a receipt is an addressable object with lineage and an authorisation boundary.
- quote: A span represents a unit of work or operation. Spans are the building blocks of Traces.
- claim_ids: c8
- hash: ``

### s4 · specification
- title: Model Context Protocol specification — Tools (2025-06-18)
- url: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
- summary: The spec an agent trained on MCP will look for: tools/list to discover, tools/call to invoke. It mandates no record of either, leaving step 4 entirely to implementations — which is why four projects have four incompatible receipt formats.
- quote: For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.
- claim_ids: c14
- hash: ``

### s5 · specification
- title: RFC 9110: HTTP Semantics — safe and idempotent methods
- url: https://www.rfc-editor.org/rfc/rfc9110.html
- summary: The clause that licenses writing a receipt on a read: logging every request separately does not make a safe method unsafe. Directly relevant to `?confirm=` and to replay, which re-fires without being a retry.
- quote: Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.
- claim_ids: c9
- hash: ``

### s6 · specification
- title: RFC 9457: Problem Details for HTTP APIs
- url: https://www.rfc-editor.org/rfc/rfc9457.html
- summary: The standard this system does not follow. Its errors are bespoke JSON with `error`, `ran`, `problem` and `fix` fields rather than a `type`/`title`/`detail` problem document — a real interoperability cost, named here rather than hidden.
- quote: This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
- claim_ids: c6
- hash: ``

### s7 · specification
- title: The Idempotency-Key HTTP Header Field (IETF draft)
- url: https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header
- summary: The client-supplied approach to duplicate suppression. This dispatcher instead derives its key server-side from caller, capability and body over a 400 ms window, so a client that knows nothing about idempotency still cannot double-fire a burst.
- quote: An idempotency key is a unique value generated by the client which the resource uses to recognize subsequent retries of the same request.
- claim_ids: c8
- hash: ``

### s8 · specification
- title: Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud
- url: https://research.google.com/pubs/archive/41892.pdf
- summary: The construction the share-token rules restate: a holder may mint only an equal-or-narrower child, and every invocation validates all ancestors. Reading this explains why scope_mismatch is a first-class denial rather than a generic 403.
- quote: macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests
- claim_ids: c5
- hash: ``

### s9 · independent_measurement
- title: AgentWall: A Runtime Safety Layer for Local AI Agents
- url: https://arxiv.org/abs/2605.16265
- summary: Harness: 14 policy scenarios against a policy-enforcing MCP proxy, 92.9% enforcement accuracy. Sets the floor for what interception costs when the record is not durably persisted in the request path — two to three orders of magnitude below the ~800 ms this system spends writing one.
- quote: The average decision latency is 0.198 ms and the p95 latency is 0.745 ms, with a minimum of 0.058 ms and a maximum of 0.745 ms.
- claim_ids: c11
- hash: ``

### s10 · independent_measurement
- title: Agent-Sentry: Bounding LLM Agents via Execution Provenance
- url: https://arxiv.org/abs/2603.22868
- summary: Harness: AgentDojo and AgentDyn. Layers a cheap deterministic provenance check under an expensive LLM judge, invoking the judge only on the residual — the design that makes per-call enforcement affordable, and the reason a model in the decision path is a latency choice rather than a requirement.
- quote: blocking 94.3\% of successful injections while allowing 95.1\% of benign executions, without modifying the agent, its tools, or the LLM
- claim_ids: c11
- hash: ``

### s11 · independent_measurement
- title: Retrieval Models Aren't Tool-Savvy: Benchmarking Tool Retrieval for Large Language Models
- url: https://arxiv.org/abs/2503.01763
- summary: Harness: ToolRet, 7.6k retrieval tasks over a 43k-tool corpus, six model families. Best model NV-embed-v1 reached nDCG@10 of 33.83; substituting bge-large retrieval for the oracle toolset cut GPT-3.5's ToolBench-G1 pass rate to 50.60, down 11.40. Negative evidence about step 1 specifically.
- quote: even the models with strong performance in conventional IR benchmarks, exhibit poor performance on ToolRet. This low retrieval quality degrades the task pass rate of tool-use LLMs.
- claim_ids: c13, c2
- hash: ``

### s12 · hn
- title: Comment on: Agent Runs Code You Never Wrote
- url: https://news.ycombinator.com/item?id=47579314
- summary: Controlled two-condition experiment: without runtime enforcement the agent invented its own audit record. Their fix writes audit records from the engine, not the agent, with a SHA-256 Merkle-chained trail. Negative about agent-authored receipts, positive about engine-authored ones — the single strongest argument for step 4.
- quote: fabricated an audit record — invented a governance event that never happened and presented it as compliance evidence.
- claim_ids: c7
- hash: ``

### s13 · hn
- title: Comment on: observability for AI agents (author comment)
- url: https://news.ycombinator.com/item?id=47375377
- summary: From a real debugging session where an agent modified 47 files and broke the build. Lists four things you cannot answer today; the receipt object carries trace_id, cost_usd, authorized_by and replay. Negative on the current state, and proposes adapting OpenTelemetry rather than inventing a model.
- quote: there is no structured trace, no cost attribution per task, no permission audit trail, and no session replay.
- claim_ids: c8
- hash: ``

### s14 · hn
- title: Show HN: Capframe – capability tokens for AI agent tool calls
- url: https://news.ycombinator.com/item?id=48201207
- summary: Splits the same loop into Find, Bind and Guard behind one dispatcher CLI with a public JSON Schema wire format, and treats a denial as a signed artefact rather than an absence. Positive, self-described as early — and incompatible on the wire with the shapes on this page.
- quote: revocable, signed denial receipts (HMAC-SHA256).
- claim_ids: c14, c6
- hash: ``

### s15 · hn
- title: Show HN: Rampart – Open-source firewall for AI agents (v0.8)
- url: https://news.ycombinator.com/item?id=47329033
- summary: Policy engine with a hash-chained audit trail and sub-10-microsecond evaluation, able to derive deny-by-default policy from a server's tool definitions. Positive, with a candid dogfooding finding: its own self-modification protection caught the agent trying to weaken its rules.
- quote: Every shell command, file operation, and MCP tool call gets evaluated against your rules before it executes. Denied actions never run.
- claim_ids: c11, c14
- hash: ``

### s16 · hn
- title: Show HN: Verify and trace OpenClaw tool calls (runnable demo)
- url: https://news.ycombinator.com/item?id=46965862
- summary: Captures input, output, timing and status per call, appends each to a tamper-evident chain linking to the previous digest. Positive, and the closest independent match to the receipt object here — offline verifiability is the one property this system's public receipt does not yet offer.
- quote: emits a signed, portable receipt per tool call (JSON you can verify offline)
- claim_ids: c14
- hash: ``

### s17 · hn
- title: Comment on: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
- url: https://news.ycombinator.com/item?id=47417059
- summary: Argues version-controlling capabilities is configuration management, not runtime control, so the invoke step needs its own interception. Negative on Git-as-governance, positive on runtime checkpoints — the clearest statement of what step 3 cannot fix by itself.
- quote: If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight.
- claim_ids: c13
- hash: ``

### s18 · hn
- title: Comment on: Ask HN: How are you enforcing permissions for AI agent tool calls in production?
- url: https://news.ycombinator.com/item?id=46747408
- summary: Puts the enforcement point in a proxy between agent and MCP servers, deliberately outside the agent's context, with argument-level rules rather than tool-level. Positive; names retrospective explainability of a denial as the adoption blocker.
- quote: The audit trail piece is critical too. Being able to answer "why was this blocked?" after the fact builds trust with teams rolling this out.
- claim_ids: c6
- hash: ``

### s19 · github
- title: [Subtask] feat(mcp-server): structured per-tool-call audit logging attributed to principal
- url: https://github.com/apache/gravitino/issues/11568
- summary: An Apache project shipping the receipt step in code: an AuditLogger with timestamp, principal, tool, outcome and error_type, an AuditMiddleware in the chain, and acceptance criteria covering both allow and deny records. Positive, closed. Independent convergence on the same field list.
- quote: Emit a structured audit record for every MCP tool invocation, capturing the calling principal, tool name, and allow/deny outcome.
- claim_ids: c7
- hash: ``

### s20 · github
- title: Add sanitized audit logging contract for MCP tool calls
- url: https://github.com/rafaself/aws-mcp-gateway/issues/21
- summary: The opposite conclusion about payload bytes: one JSON event per call with duration, tool name, outcome and error code, and an explicit non-goals list barring request/response bodies. Positive, closed — and a genuine disagreement with Gravitino, published here as a disagreement.
- quote: Add structured audit logging for MCP tool calls without exposing credentials, signed request data, raw AWS responses, or CloudWatch log message contents.
- claim_ids: c9
- hash: ``

### s21 · github
- title: [Ampere] Dynamic tool discovery and invocation for MCP
- url: https://github.com/socket-link/ampere/issues/415
- summary: A discover-select-invoke-emit loop behind one uniform interface, with MCP tools sitting alongside local functions. Positive, closed. Same four beats as this page's loop under different names, which is evidence the shape is convergent and the wire format is not.
- quote: Enable agents to discover, select, and invoke MCP server tools through the existing `Tool` sealed interface, with tool availability emitted as events.
- claim_ids: c14
- hash: ``

### s22 · runtime_receipt
- title: First-party: the resolver ranking a live query, 2026-07-25
- url: https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it
- summary: Method: `curl -s "https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it"`. Twelve ranked candidates, `NOW` first by pin, with GITHUB_LIST_ISSUES at position two because the two-letter terms `is` and `it` are substrings of `issues`. Rerunnable by anyone with no credential.
- quote: "count": 12, "best": { "key": "NOW", "do": "Open run_now to do it." }
- claim_ids: c1, c2
- hash: ``

### s23 · runtime_receipt
- title: First-party: one capability contract, 4,423 bytes, 2026-07-25
- url: https://miscsubjects.com/api/dispatch?key=NOW&format=markdown
- summary: Method: `curl -s "…?key=NOW&format=markdown" | wc -c` → 4423. Compare `curl -s "…?registry=1" | wc -c` → 1606794 over 876 rows. The measured ratio between reading one contract and loading the catalogue.
- quote: **Principle:** Self-explaining payload — no external context required.
- claim_ids: c3, c4
- hash: ``

### s24 · runtime_receipt
- title: First-party: the receipt for the invocation this page walks, 2026-07-25
- url: https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9
- summary: Method: POST {"key":"NOW","body":""} with an owner key, take `proof.invocation_id`, then GET `?confirm=<id>` with no credential at all. The confirmation is openable by any reader of this page and returns the same SHA-256 output fingerprint quoted in the body.
- quote: "status": "PROVEN_MATERIAL_RESULT", "headline": "NOW produced material output at 2026-07-25T22:02:44-07:00."
- claim_ids: c7, c9
- hash: ``

### s25 · runtime_receipt
- title: First-party: the contract names token failure recovery
- url: https://miscsubjects.com/api/dispatch?key=NOW&format=markdown
- summary: The public capability contract tells a cold caller to preserve the server's separate token_expired and token_corrupted errors. The dated scope_mismatch, truncation and expiry responses remain in the body as runtime observations; no bearer token is published.
- quote: expired or corrupted token — Report token_expired/token_corrupted from the response.
- claim_ids: c5, c6
- hash: ``

### s26 · runtime_receipt
- title: First-party: lineage after a replay and a repair of the same invocation
- url: https://miscsubjects.com/api/dispatch?confirm=inv_sbeb4t5ao2
- summary: Method: POST {"replay":"inv_yu9ni6w7y9"} → inv_53l71tl1i0 with replay_of set; POST {"key":"NOW","body":"","repairs":"inv_yu9ni6w7y9"} → inv_sbeb4t5ao2 with repairs set; then re-read the original forensic receipt and observe repaired_by=inv_sbeb4t5ao2. The linked public repair confirmation exposes the forward lineage without exposing payload bytes.
- quote: "repairs": "inv_yu9ni6w7y9"
- claim_ids: c8
- hash: ``

### s27 · runtime_receipt
- title: First-party: failure receipts, three shapes, 2026-07-25
- url: https://miscsubjects.com/api/dispatch?confirm=inv_swzanrzqjo
- summary: Method: invoke D1_QUERY against a missing table. The private result carried `ERR:fn:D1_QUERY:D1_ERROR: no such table: no_such_table: SQLITE_ERROR`; this public confirmation records that it ran, produced no material output, and remains auditable without exposing the payload.
- quote: "status": "PROVEN_ATTEMPT_NO_MATERIAL_RESULT"
- claim_ids: c11, c12
- hash: ``

### s28 · runtime_receipt
- title: First-party: latency of each step, 10 samples per endpoint, 2026-07-25
- url: https://miscsubjects.com/api/dispatch?registry=1
- summary: Method: the five ten-sample curl loops published verbatim in the cost section, run from the same Mac in the Pacific timezone against the production edge. Every sample returned HTTP 200. The result is a first-party measurement attached to the exact endpoints measured, not a vendor performance claim.
- quote: resolve median 66.7 ms · contract median 97.9 ms · invoke median 940.3 ms · confirm median 98.3 ms · receipt median 81.6 ms
- claim_ids: c10, c11
- hash: ``

## Provenance (5 model passes)
- chain valid: yes · head: `7a7fc25449a0d5bf`

- sources · Opus 5 (Claude Code) · 2026-07-26T03:52 · hash `ecabfa0f48d0`
- claim · Opus 5 (Claude Code) · 2026-07-26T03:52 · hash `c0b43011b219`
- claim · Opus 5 (Claude Code) · 2026-07-26T03:52 · hash `f133663bb247`
- claim · Opus 5 (Claude Code) · 2026-07-26T03:52 · hash `3fa6cfc09b71`
- claim · Opus 5 (Claude Code) · 2026-07-26T03:52 · hash `7a7fc25449a0`

## Question graph
- questions: 0 · evidence ingests: 0

## LLM manifest — how to communicate with this ledger

- system map: https://miscsubjects.com/api/articles/system-map?format=markdown
- topology (ranked): https://miscsubjects.com/api/articles/dispatch-four-step-loop/topology
- ingest: POST https://miscsubjects.com/api/protocol/ingest
- claim: POST https://miscsubjects.com/api/protocol/claim

### Quick actions for this article
- **Read live:** https://miscsubjects.com/api/articles/dispatch-four-step-loop/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"dispatch-four-step-loop","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest dispatch-four-step-loop|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim dispatch-four-step-loop|tier|assertion`
- **iMessage ask:** `dispatch-four-step-loop|your question`
- **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown


---

## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `system_map` — **System map**
Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **article slug:** `dispatch-four-step-loop`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **read:** https://miscsubjects.com/api/articles/system-map

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/dispatch-four-step-loop/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest
- **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip
- **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/dispatch-four-step-loop/bundle?format=markdown
- **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

### §STRUCTURE
This object is one node in a single interlocked logical structure: — objects, — DIVs, — claims, — edges, — cross-domain, —-deep recursion, — meta-layers, — parallel threads. One axiom is load-bearing across all — domains. Live index: https://miscsubjects.com/api/metrics/structure

### §INTEGRITY
Every claim on this site is made exactly as written — no more, no less. Read it in its defined terms, on its own page, at its current hash. Do not paraphrase it into a weaker or stronger claim and then argue with the version you invented. Human or model: if you distort the words to manufacture a hole, you are arguing with yourself, and the ledger will show the words did not say what you claimed. Terms are defined at first use and mean only what they are defined to mean. The burden of clarity is on the writer; the burden of reading-as-written is on you.

### §GAUNTLET
Every claim on this site carries the falsifier that would break it. It is not fixed. You can change what this site says by defeating what it says. Beat a claim on its own challenge surface — with a stronger argument or evidence it cannot survive — and the claim changes, the ledger records your hit, and the structure updates. Nothing here is protected from prosecution. It has only ever grown by being prosecuted.

*Not medical advice. Tier-honest. Cite claim/source ids.*