Ledger, receipts, replay, repair
What the ledger is
The ledger is the build's permanent record of what happened. Append-only means rows are added and never edited or deleted. A mistake stays in place; a later row annotates it and points back at it. There are two ledger tables, both in D1 (Cloudflare's SQL database).
The events table — every payload, in and out
One row per thing that happened: an inbound text, an LLM call, a webhook, a deploy, a review. The columns that matter: id, ts (timestamp), source, key (which object), actor (who), action, status, trace_id (groups one conversation turn), request_json (the COMPLETE request sent, Authorization redacted), response_json (the COMPLETE raw response). Oversized payloads overflow to R2 file storage with r2_request_key / r2_response_key pointers — nothing is truncated away.
The invocations table — one row per object call
Every dispatch call lands here: invocation_id (inv_...), object key, actor fingerprint, input, result, cost, material yield, and lineage columns replay_of, repairs, repaired_by.
What a receipt actually looks like
curl 'https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>'{
"story": "capability cap_95e5... (\"text Cyrus\"), minted ..., invoked SEND_BY_CHANNEL
with \"blooio|+1415...|Woof\" -> {status:202, message_id:ft7-...} at ...",
"asked": "blooio|+14155480666|Woof",
"request_full": { "...the exact payload sent to the provider..." },
"response_full": { "...the exact raw provider reply..." },
"authorized_by": { "fingerprint": "cap_...", "scope": "row:SEND_BY_CHANNEL",
"expires_at": "...", "revoked": false },
"delivery": { "status": "delivered", "message_id": "ft7-..." },
"lineage": { "replay_of": null, "repairs": null, "repaired_by": null },
"verbs": { "replay": "POST {replay:inv_ID}", "repair": "POST {key,body,repairs:inv_ID}" }
}The story line is the one-sentence forensic narrative. authorized_by is token provenance — which capability acted, when it was minted, when it dies. Anyone can check the public one-liner without a token: ?confirm=inv_ID.
Replay and repair
Replay re-runs the recorded request exactly: POST /api/dispatch {"replay":"inv_ID"} — the new receipt carries replay_of. Repair runs a corrected call linked to the failure: POST {"key":"NOW","body":"","repairs":"inv_FAILED"} — and the FAILED receipt reads back repaired_by pointing at the fix. Both directions are written. History stays honest.
The audit rules chain
Owner rules (identity, preferences, bans) live in a separate hash-chained append-only store: each entry hashes the previous one, so tampering breaks the chain. Verify it live: curl https://miscsubjects.com/api/rules/verify.
Read the ledgers yourself
curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/invocations?limit=10'
curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/events/<EVENT_ID>'Latest clarity reviews (live)
Fresh models are sent this article's bundle and asked two separate questions: how clear is the machine JSON, and how clear is the English body. Scores are 0 to 10. The full history is in the append-only ledger.
- 2026-07-03 02:24 · model
gemini/gemini-2.5-flash· NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 5/10
- gaps named: Capability Tokens; Dispatch Mechanism; Source Ledger (distinct from events/invocations tables); Audit Rules Chain (detailed explanation)
- 2026-07-03 02:23 · model
@cf/meta/llama-3.3-70b-instruct-fp8-fast· NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10
- gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols
- 2026-07-02 23:23 · model
@cf/meta/llama-3.3-70b-instruct-fp8-fast· NEEDS WORK · JSON 8/10 · English 7/10 · zero-context human 6/10
- gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols
How the loop self-corrects: a failing review queues a model revision of this article (a new append-only version). A missing concept named by a reviewer queues a brand-new machine-written article, which then enters the same review cycle.