Object Invocation Protocol · protocol specification

Total Structure v3: Appendix B

#philosophy#oip#appendix#total-structure#systems-theory

Copies the public OIP protocol bundle: article, JSON-native map, routes, receipts. No owner token.

§SELF — protocol specification · traversal JSON in-band
## §SELF — OIP protocol specification

**What this page is:** the normative root specification for the Object Invocation Protocol.

**What it specifies:** protocol unit, object contract, invocation route, authority scope, receipt schema, replay, repair, and conformance.

**Read:** https://miscsubjects.com/a/oip-v3-appendix-b
**This page as JSON:** https://miscsubjects.com/api/articles/oip-v3-appendix-b
**Machine bundle:** https://miscsubjects.com/api/articles/oip-v3-appendix-b/bundle?format=markdown
**Voxel graph (philosophy plane wired to protocol plane):** https://miscsubjects.com/api/articles/oip/voxels
**Live object tree:** https://miscsubjects.com/api/dispatch?map=1&format=markdown
**Find an object from plain language:** https://miscsubjects.com/api/dispatch?ask=<what you want>
**Read one object:** https://miscsubjects.com/api/dispatch?key=<KEY>&format=markdown

**Proof rule:** an action is not proven by intent, description, or a 200. It is proven by the ledger and the OIP receipt for the invocation.

APPENDIX B — The Benchmark

The implementation test for the machine plane compares six conditions on audit-dependent tasks:

  • A — single unscaffolded frontier model, one-shot.
  • B — single scaffolded model with deterministic proof structure.
  • C — multiple unscaffolded models, consensus voting.
  • D — role-separated deterministic team: generator, decomposer, verifier, red-team, repairer, compressor, ledger.
  • E — LLM-as-OS dynamic router: deterministic command plane selecting per task among local/open-weight/frontier models, tools, context, proof depth, red-team depth, privacy mode, and ledgering, under cost, privacy, latency, and surety constraints.
  • Fnew in v3.0: a live object-grammar deployment (Book VI pattern): one dispatch door, contract-resolved invocation, mandatory receipts, repair lineage, scheduled zero-context review. F tests what A–E cannot: the grammar under real operation over time — reuse rates, repair-lineage integrity, review-loop effect on artifact quality, delegation safety under scoped tokens.

Metrics: correctness, auditability, reproducibility, adversarial survival, token cost, compute cost, latency, human verification time and time saved, failure cost (domain-weighted), reuse value, proof-reuse rate, repair-lineage integrity (fraction of failures with attached fixes), review-score trajectory over versions, data-custody and privacy cost, actionability. Derived: surety, logical energy, logical density, task-adjusted logical density.

Predictions: D dominates A and C where surety gain exceeds coordination cost; E dominates D across heterogeneous task sets; F's review-score trajectory rises across versions (S8's constructive prediction) and F's repair-lineage integrity stays near unity where A–E's unlinked-guess rate grows with volume.

Validity requirements: demonstrably audit-dependent tasks; diverse error distributions; measured (not assumed) coordination cost; defined deployment window; pre-published failure-cost weighting; ground truth independent of the evaluated systems; pre-defined privacy scoring; for F, review parameters declared before the window opens (IX.10).

Falsifiers: A consistently beats D/E/F on task-adjusted logical density; surety/alpha cost curves fail to fall under deterministic scaffolding; proof reuse fails to beat regeneration over the window; routing overhead exceeds task-adjusted gain; F's review scores stagnate or degrade across versions (S8); F's repair lineage decays with scale (S7).

---

---

Corpus map

oip-v3-appendix-b · condition map

Evidence map

Hover a node — its path lights up. Click to open the article.

Full map →
Talk to this article
Tap a phone. Ask anything about Total Structure v3: Appendix B. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.
oip-v3-appendix-b · posted 2026-07-04 · updated 2026-07-04 · 2 prior revisions
Ledger API & provenance
Provenance · 2 model passes · 0 tokens · $0 · 1 model
chain head 803f04bbbae11eb8
edit claude-fable-5 · 2026-07-04 04:34 · 0 tok · 800d28115854
edit claude-fable-5 · 2026-07-04 05:02 · 0 tok · 803f04bbbae1
verify chain →
Live ledger · 3 payloads · 2 turns
recent activity · inspect
ARTICLE_CREATED automation · HTTP 200 · 2026-07-04 02:47 · t_article_r3mfkudx
AUTOMATE_FIRE dispatch · 2026-07-03 19:47 · t_lkiyit66
AUTOMATE_FIRE dispatch · 2026-07-03 19:47 · t_lkiyit66
view full ledger & cards →
OIP REST + ledger
system shelf GET /api/dispatch?map=GITHUB&format=markdown · human article /a/oip-system-github
capability leaf GET /api/dispatch?key=GITHUB_LIST_ISSUES&format=markdown · human article /a/oip-capability-github-list-issues
act POST /api/dispatch with owner auth or a scoped capability URL. Public docs are open; mutating action is token-bounded.
token explain GET /api/dispatch?explain=1&share=TOKEN
receipt GET /api/dispatch?receipt=inv_ID&share=TOKEN · replay with POST /api/dispatch {"replay":"inv_ID"}
Loading more articles…