Object Invocation Protocol · protocol specification

OIP system: OIP capabilities

#oip#object-invocation-protocol#protocol-specification#machine-native-json#system

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

§SELF — protocol specification
## §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-system-oip
**Machine bundle:** https://miscsubjects.com/api/articles/oip-system-oip/bundle?format=markdown
**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.

OIP capabilities

A generated article for one OIP shelf. It lists every operation in this API/CLI/MCP/device/model/core subsystem, links each leaf article, and gives the ledger path for proof.

This page is the operating article for one build subsystem. It is generated from live directory rows. If a task belongs to this subsystem, scan the operations below, open the matching capability article, run only the exact object named there, and verify by receipt.

Kind: core. Capabilities: 9. Machine system map: /api/dispatch?map=OIP&format=markdown. Root: /a/oip.

Operations

OIP_PROTOCOL

Object Invocation Protocol index — endpoints, schema, invariant loop. Use when: cold bootstrap for any client; what is OIP and how to invoke objects. Arguments: none. Human article: /a/oip-capability-oip-protocol. Machine doc: ?key=OIP_PROTOCOL&format=markdown. Invocation history: /api/invocations?object_id=OIP_PROTOCOL.

OIP_REGISTRY

Full OIP object registry from directory rows (type, runner, read/write paths, schemas). Use when: list invokable objects; category filter optional. Arguments: category (optional). Human article: /a/oip-capability-oip-registry. Machine doc: ?key=OIP_REGISTRY&format=markdown. Invocation history: /api/invocations?object_id=OIP_REGISTRY.

OIP_RECEIPT

Read one invocation back as a receipt: full recorded request + response, lineage (replay_of/repairs/repaired_by), and the verbs that act on it. A receipt is a live replayable object, not history. Use when: Cyrus asks "show the receipt for inv_x", "what happened in inv_x", "why did that fail". Arguments: $1 = invocation id (inv_…).. Human article: /a/oip-capability-oip-receipt. Machine doc: ?key=OIP_RECEIPT&format=markdown. Invocation history: /api/invocations?object_id=OIP_RECEIPT.

OIP_REPLAY

Re-fire a past invocation with its recorded input. New receipt links replay_of to the old one. Use when: Cyrus says "replay that", "run inv_x again", "re-fire it as it was". Arguments: $1 = invocation id (inv_…).. Human article: /a/oip-capability-oip-replay. Machine doc: ?key=OIP_REPLAY&format=markdown. Invocation history: /api/invocations?object_id=OIP_REPLAY.

OIP_REPAIR

Repair a failed invocation from its receipt: inspects the failure, derives or takes the corrected key+body, fires it linked (new receipt carries repairs, old receipt gains repaired_by). Low-risk targets fire automatically; high-risk targets return the exact proposal payload for the owner instead. Use when: Cyrus says "repair that failed invocation", "fix inv_x with NOW", "make that call again but corrected". Arguments: $1 = failed invocation id, $2 = corrected row key (optional — derived from the failure when omitted), $3+ = corrected body (optional, may contain pipes).. Human article: /a/oip-capability-oip-repair. Machine doc: ?key=OIP_REPAIR&format=markdown. Invocation history: /api/invocations?object_id=OIP_REPAIR.

OIP_TREE

Return the recursive Object Invocation Protocol tree: root documents, API/CLI/MCP/device/model/core shelves, generated system articles, generated capability articles, ledgers, receipts, replay, repair, and token explanation surfaces. Use when: Cyrus or a model asks for the OIP tree, object invocation protocol docs, capability map, machine-native API tree, API/CLI/MCP documentation, or how to start from one self-explaining root and discover the whole action surface. Arguments: none. Human article: /a/oip-capability-oip-tree. Machine doc: ?key=OIP_TREE&format=markdown. Invocation history: /api/invocations?object_id=OIP_TREE.

OIP_REVIEW_SEED

Queue OIP article clarity review tasks. Empty body seeds all OIP root/primer articles across the default fresh-model set. Raw JSON body may pass {"slugs":"oip"],"models":["grok/grok-4.3"]}. Use when: start or refill the recursive OIP article review queue. Arguments: $1+ optional raw JSON body. Human article: [/a/oip-capability-oip-review-seed. Machine doc: ?key=OIP_REVIEW_SEED&format=markdown. Invocation history: /api/invocations?object_id=OIP_REVIEW_SEED.

OIP_ARTICLE_REVIEW

Run one OIP article loop tick. Claims the next tasks.source=oip-review row and routes it: oip-review scores machine JSON clarity + English clarity with a fresh model; oip-write has a model write a missing OIP article; oip-revise has a model rewrite a failing article as a new append-only version. Every step lands in the ledger. Use when: cron or manual trigger to advance the recursive OIP documentation loop one step. Arguments: none. Human article: /a/oip-capability-oip-article-review. Machine doc: ?key=OIP_ARTICLE_REVIEW&format=markdown. Invocation history: /api/invocations?object_id=OIP_ARTICLE_REVIEW.

OIP_PURIFICATION_SEED

Queue OIP documentation purification under logical-proof-v1. Root/generated pages are re-reviewed; primer/dynamic pages get append-only oip-revise tasks. Use when: after content rules change or after an editorial-board decision identifies unclear/proofless OIP documentation. Arguments: optional raw JSON {"slugs":"oip","oip-operating-model"],"brief":"..."}. Human article: [/a/oip-capability-oip-purification-seed. Machine doc: ?key=OIP_PURIFICATION_SEED&format=markdown. Invocation history: /api/invocations?object_id=OIP_PURIFICATION_SEED.

9
capabilities
Evidence · 5 sources · swipe →chain oipinvocatio · verify chain · provenance

Key evidence

5 claims · tier-ranked · API
system
The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.
sources: oip-s3, oip-s4
system
The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.
sources: oip-s1
system
Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.
sources: oip-s2, oip-s3
system
Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.
sources: oip-s2
system
OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.
sources: oip-s2, oip-s5
Talk to this article
Tap a phone. Ask anything about OIP system: OIP capabilities. 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-system-oip · posted 2026-07-02 · updated 2026-07-03
Ledger API & provenance
Provenance · 1 model pass · 0 tokens · $0 · 1 model
chain head virtual-oip
generate system/oip_articles · 2026-07-03 00:26 · 0 tok · virtual-oip
verify chain →
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…