Object Invocation Protocol

1. Protocol model

An OIP object states the work, the input, the authority, the invocation route, the runner, the proof requirement, the receipt, the replay path, and the repair path. A model operates OIP by resolving an object, reading the object contract, invoking the object route, and returning the receipt.

The OIP unit is the work object. The OIP proof is the receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair.

2. End-to-end operation

A model needs to do work. The model needs to know what work exists. OIP gives the model an object. The object states the work, the input it needs, the authority it requires, where the request goes, the runner that performs it, and the proof that must return. The proof is the receipt. Replay repeats a recorded invocation. Repair links a corrected invocation to the failed receipt.

Operating loop

The system is used in a short, receipted loop:

1. Resolve — ?ask=<plain language> or ?key=<KEY> returns the matching object.
2. Contract — the object's contract describes its inputs and behavior.
3. Scope — ?explain=1&share=TOKEN reports what the credential permits.
4. Invoke — invoking the object runs it.
5. Receipt — the response carries proof.say_to_user, the human-readable result.
6. Repair — a wrong result is corrected by repairing from its receipt.

The steps run in order; the first incomplete step reports what it requires.

3. What is inherited, and from where

Every part of this protocol has prior art, and the honest version of the lineage says which part came from where. Each document below is linked in the sources for this article.

Addressing a remote unit of work. RFC 5531 identifies a call by program, version, and procedure number and returns an accept-or-reject status. SOAP 1.2 wraps the call in an envelope with headers and a fault element. gRPC adds typed service definitions, deadlines, and cancellation. All three assume the caller already knows the procedure exists; none hands the caller a discovery document at runtime.

Making the interface self-descriptive. Fielding's chapter 5 defines resources identified by URI and manipulated through a uniform interface with self-descriptive messages. OpenAPI turns that into a machine-readable document: paths, operations, parameters, schemas. This is the half OIP keeps — the object contract is an OpenAPI-shaped description of one unit of work rather than of a whole service.

Discovery for models. MCP solved the discovery problem for a model session: the server advertises tools, prompts, and resources, and the session calls them. Its unit is the session, so a call made outside that session has no standing. OIP moves the unit to the object and the standing to the credential, which is why an OIP call survives being pasted into a different model.

Provenance. PROV-DM already models provenance as entities, activities, and agents with derivation and attribution. An OIP receipt is that shape narrowed to a single invocation, which is why receipts map onto PROV instead of inventing a vocabulary.

Attenuating authority. Macaroons carry caveats so a holder can narrow a credential without contacting the issuer; OAuth 2.0 Token Exchange issues a reduced-scope token for delegated action. A capability link is that idea with the scope, the expiry, and the use count carried in the URL itself, so the thing you paste is already the limit.

Where this protocol knowingly breaks a rule. RFC 9110 defines GET as a safe method: it should not cause an effect. A capability link fired by GET does cause one. That cost is accepted so any model that can open a URL is already a client, and it is bounded rather than excused: the credential carries a use budget, and the Idempotency-Key draft is the pattern a retried invocation follows so a repeat is not applied twice. Receipt hashes follow JCS canonicalization, because two equal records serialized differently would otherwise hash differently.

What is left after subtracting all of the above: the work object as the protocol unit, the receipt as the mandatory return, and repair as a first-class linked correction rather than a new call.

4. The OIP object

An OIP object is the protocol unit. One object defines one addressable unit of work. Every object exposes the same fields:

• object_key: the stable name of the work object.
• object_type: the class of object.
• work_definition: the work the object performs.
• input_schema: the input the object accepts.
• authority_required: the credential scope the object requires.
• invocation_route: the route that invokes the object.
• runner: the system that performs the work.
• side_effects: the external changes the object may cause.
• risk_class: the operational consequence class.
• proof_required: the receipt or artifact that establishes success.
• receipt_schema: the fields the receipt records.
• replay_route and repair_route: the mechanisms for repeated and corrected invocation.
• conformance_tests: the checks that establish object behavior.
• examples: valid object calls.
• human_view, machine_view, json_view: the three views of the object.

The same object is readable in three forms: a human article at /a/oip-capability-KEY, a machine document at /api/dispatch?key=KEY&format=markdown, and a JSON object at /api/dispatch?key=KEY. The human article, the machine document, and the JSON object are three views of one object.

5. Invocation loop

1. Resolve the object: /api/dispatch?ask=<plain language> or /api/dispatch?key=<KEY>.
2. Read the object contract.
3. Confirm authority: /api/dispatch?explain=1&share=TOKEN.
4. Invoke the object route: POST /api/dispatch {key, body} or GET /api/dispatch?invoke=KEY&body=...&share=TOKEN.
5. Read the runner result.
6. Return the receipt: /api/dispatch?receipt=inv_ID.
7. Answer from the receipt.
8. Use replay for repeated work; use repair for corrected work.

The first missing element — object, authority, route, or receipt — is the stopping point, and it names what it requires.

6. Receipt

A receipt proves one invocation. Every receipt records:

• invocation_id, timestamp, actor, credential_scope.
• object_key, object_version, input_hash, input_body.
• runner, status, output_hash, artifact_urls.
• error when the invocation fails.
• ledger_url, confirm_url, replay_url, repair_url.
• parent_invocation_id when the invocation was delegated.
• repair_of_invocation_id when the invocation is a repair.

Read a receipt at /api/dispatch?receipt=inv_ID. Confirm one publicly at /api/dispatch?confirm=inv_ID. Success requires a real invocation id, a recorded request, a recorded response, and a receipt link. When the receipt reports the runner failed, the action failed, and the next move is repair.

7. Replay and repair

Replay repeats a recorded invocation: POST /api/dispatch {replay:"inv_ID"}. The replay uses the recorded object key and input, produces a new invocation id and receipt, and links the new receipt to the original.

Repair creates a corrected invocation: POST /api/dispatch {key, body, repairs:"inv_ID"}. The repair references the failed receipt, produces a new invocation id and receipt, and links the corrected receipt to the failure in both directions. Repair turns failure into lineage.

8. Conformance

• OIP-READ: the system exposes a readable object contract.
• OIP-INVOKE: the system exposes an invocation route for the object.
• OIP-PROVE: the system returns a receipt for the invocation.
• OIP-REPLAY: the system repeats the recorded invocation.
• OIP-REPAIR: the system attaches a corrected invocation to the failed receipt.
• OIP-DELEGATE: the system hands a scoped object credential to another model, agent, browser, queue, or service.
• OIP-LEDGER: the system stores invocation records append-only.
• OIP-ARTIFACT: the system returns artifact references when work creates files, images, messages, code, or documents.

A conformant success response returns the object key, the invocation id, the receipt URL, the status, and the result. A conformant failure response returns the object key, the invocation id when present, the error, the missing requirement, and the repair target.

The latest completed suite exposes 27 numbered production clauses at /api/dispatch?conformance=1&format=markdown; only an owner-authenticated request may execute a fresh state-mutating run. v0.8.1 strengthens C17 with typed intent/authority/effect/postcondition records, C18 with atomic parent-budget reservation, C19 with invocation-time ancestor validation, and C20 with authority-preserving, namespaced, stop-on-failure trails. v1.1.0 adds federation: C26 (discoverable cross-domain identity + envelopes-are-data) and C27 (audience-bound capabilities), with a dedicated cross-domain proof at /api/dispatch?fedtest=1&format=markdown and the envelope specification at /a/oip-message. Specification: /a/oip-spec.

9. OIP and MCP

MCP standardizes model access to tools, prompts, and resources inside a model-client session. OIP standardizes model-operated work as an object.

MCP answers the access question. OIP answers the work question.

An MCP tool is an OIP object

In this build, an MCP tool is registered as an OIP object. The MCP shelf holds 11 MCP tools as directory objects. Example object: MCP_context7_resolve_library_id, runner type mcp, read it at /api/dispatch?key=MCP_context7_resolve_library_id&format=markdown.

A model operates that MCP tool by opening the OIP object URL: read /api/dispatch?key=MCP_...&format=markdown, then invoke /api/dispatch?invoke=MCP_...&body=...&share=TOKEN. The MCP call runs behind the object, and OIP records the receipt. OIP addresses an MCP tool as a link and adds the receipt, the replay path, the repair path, the scope, and the ledger entry to that tool.

The relationship is containment: MCP connects a session to a server; OIP registers that server's tool as one object among its runners and makes each call provable by receipt. A model reaches the MCP tool through its OIP object URL.

Public demo

NOW is a public demo object. Read it at /api/dispatch?key=NOW&format=markdown. Invoke it with a scoped credential to produce a receipt, confirm the receipt publicly at /api/dispatch?confirm=inv_ID, then replay and repair from that receipt. The demo runs the full loop with a scoped, rate-limited credential.

Terms

• Build: the whole miscsubjects system — site, APIs, directory rows, files, ledgers, tools, models, workers, and deploy path.
• Object: one thing the build can read or do.
• Directory row: the saved contract for one object. It says what the object does, what inputs it takes, and how to run it.
• Dispatch: the invocation door. It receives an object key and body, finds the row, and runs it.
• Runner: the actual machine that does the work: HTTP, model, shell, database, file, Worker, or service.
• Ledger: the append-only record of what was asked, what ran, and what came back.
• Receipt: one proof object for one invocation.
• Replay: run the same recorded invocation again.
• Repair: run a corrected invocation and attach it to the failed receipt.
• Tap & Go: one copied drop that carries object map, credential, execute shape, and receipt rule together.

Foundation articles

OIP assumes a reader may have zero context. The root article gives the whole shape, then the foundation articles explain the words a model or human needs before operating the build:

• OIP operating model states the operating model, the four invariants, and the six-step operating loop.
• What is an object? explains what an OIP object is and why everything in the build is one.
• What is a capability? explains scoped, expiring, revocable permissions and why least privilege matters.
• What is a token? explains the credential that separates reading from acting.
• What is a tenant? explains isolation boundaries and multi-tenant proof.
• What is a voxel graph? explains the typed node/edge machine-native topology of the build.
• What is an API? explains route, method, header, body, response, proof, and repair.
• What is REST? explains resource URLs and methods such as GET, POST, PATCH, PUT, and DELETE.
• How to operate the build with curl explains terminal HTTP calls and the dispatch shape.
• What is a CLI? explains command line programs, args, cwd, output, and exit status.
• Protocol lineage places OIP in the remote-operation protocol line: RPC, SOAP, REST, OpenAPI, MCP, W3C PROV.
• What is MCP? explains Model Context Protocol and its place beside OIP: MCP answers the access question, OIP answers the work question.
• What is GitHub? and What is GitHub MCP? explain repo/file/tool access as build objects.
• OIP link structure and OIP drop end to end explain the self-explaining link structure that carries an object to a model.
• Cron and recursive review and Models reviewing OIP articles explain the scheduled model-review loop.

Whole build, end to end

The reference implementation contains articles, prompts, files, terminals, model calls, deployments, ledgers, and self-tests as OIP objects.

The end-to-end path is:

1. Caller: some surface asks for work. The caller may be a model, browser, API client, admin page, CLI path, scheduled workflow, or messaging route.
2. Resolution: the caller either asks /api/dispatch?ask=<plain language> or opens a known object.
3. Object contract: the directory row explains the exact object: WHAT, ARGS, EX, TESTS, auth, risk, runner, and proof paths.
4. Invocation: dispatch receives key and body, validates access, and chooses the runner.
5. Execution: the runner does the work: HTTP, model, shell, D1, KV, R2, file, Worker, or deploy.
6. Ledger: the build records request, response, actor, trace, cost, material output, and errors.
7. Receipt: OIP returns a receipt link for the invocation.
8. Correction: replay repeats the recorded call; repair creates a corrected call linked to the failed receipt.

That pattern is the whole build. Different surfaces exist, but the object boundary is the same.

How to do anything

The universal rule is: never guess a tool. Resolve the object, read the object, invoke the object, prove the invocation.

1. Orient: open /api/dispatch?orient=1&format=markdown when cold.
2. Ask: open /api/dispatch?ask=<what you want>.
3. Read: open /api/dispatch?key=<KEY>&format=markdown for the exact object.
4. Invoke: use Tap & Go, owner auth, or the returned run URL.
5. Prove: open /api/dispatch?receipt=inv_ID&share=TOKEN and answer from the receipt.
6. Repair: if wrong, call POST /api/dispatch {key, body, repairs:"inv_ID"} so the fix stays attached to the failure.

If a model only knows this one path, it can operate the build without guessing.

What each part does

• Directory is the catalog of executable objects.
• Dispatch is the one invocation endpoint.
• Rows are object contracts.
• Prompts are rows too; an agent's system prompt is its row content.
• Articles are content objects with body, claims, sources, provenance, widgets, and bundle JSON.
• Files are operational code in the repo; bulk/reference data belongs outside the repo and is reached by API.
• Admin pages are human work surfaces over the same objects.
• Runners connect objects to actual work.
• Ledger and receipts are proof and memory.
• Self-test is the executable spec for claimed behavior.
• Deploy moves code changes to Cloudflare Pages.

Tap & Go

Tap & Go is the copy primitive for handing OIP to a model. One copy gives the model the credential, protocol, tree, search pattern, execute pattern, and receipt loop together. Do not assemble a token, a map, a bundle, and a link by hand. The copied drop is the interface.

The action loop is: ask in plain language, read the object, invoke the object named by the task, open the receipt, then replay or repair from that receipt if the result is wrong. The receipt is the proof: an action is established by its receipt.

Object contract

An OIP capability exposes the same fields every time: WHAT, ARGS, EX, TESTS, auth, risk, runner, run URL, machine contract, troubleshooting, invocation history, receipt, replay, and repair.

The same object is readable in three forms:

1. A human article: /a/oip-capability-KEY.
2. A machine document: /api/dispatch?key=KEY&format=markdown.
3. A JSON object: /api/dispatch?key=KEY.

The human article, the machine document, and the JSON object are three views of one object.

Proof

OIP treats the receipt as success. A completed action has a real invocation id, a recorded request, a recorded response, and a receipt link. When the receipt reports the runner failed, the action failed, and the next move is repair.

Machine-native JSON

The JSON bundle for this article is part of the article. It gives a model the same object map in structured form: how to orient, ask, read, invoke, prove, repair, traverse shelves, and understand the build facets. The prose is for human orientation; the JSON is for execution.

The root tree is live at /api/dispatch?map=1&format=markdown. The machine bundle for this article is /api/articles/oip/bundle?format=markdown. Those are handles, not the product path; Tap & Go is the product path.

OIP article library

These articles explain the build the way a strong article system explains any subject: one subject per page, human-readable prose, machine-native bundle, sources, claims, and proof paths.

• OIP protocol lineage
• OIP Operating Model
• OIP build overview
• OIP object model
• Directory rows and dispatch
• Ledger, Receipts, Replay, Repair
• Tap & Go delegation
• Machine-native JSON
• Articles and content objects
• Files, repo, and deploy
• Self-test and proof
• OIP operating playbook
• What is an API?
• What is REST?
• How to operate the build with curl
• What is a CLI?
• What is MCP?
• What is GitHub?
• What is GitHub MCP?
• OIP link structure
• OIP drop end to end
• Cron and recursive review
• Models reviewing OIP articles
• The OIP specification — and the proof it is a protocol
• What is an object?
• What is a capability?
• What is a token?
• What is a tenant?
• What is a voxel graph?
• The OIP cookbook — the exact curl for everything
• What a model sees: MCP GitHub vs the OIP directory
• What a model sees: MCP Stripe vs the OIP directory
• Branching: The Geometry That Connects Everything
• Pattern 6: Bounded Chaos — The Aliveness Solution
• The Physicists
• Western Philosophers — The Grain as Immanent Order, Process, and the Reason Within Becoming
• Eastern Philosophers — The Grain as Non-Duality and the Dissolution of the Node-Whole Boundary
• Spirals: The Growth-Rotation Solution
• Waves: The Transmission Solution
• Symmetry: The Compression Solution
• Flow Networks: The Economy Solution
• Memory: The Persistence Solution
• Scale Invariance: The Recursion Solution
• "The Information Theorists: How Compression Reveals the Grain"
• 'The Biologists: Design Without a Designer'
• "The Cyberneticians: Feedback, Variety, and the Edge of Chaos"
• "The Ladder: From Difference to Mind"
• The AI and Machine Learning Researchers: The Optimal Architecture for Learning
• The Complexity Scientists: The Edge of Chaos
• "The Mathematicians: Optimization and Invariance"
• "The Mystics: The Identity of Self with Whole"
• The Religion-Without-Religion Thinkers: Lovable Without Being a Person
• "The Twelve Axioms: The Foundation of the Grain"
• "The Designer Question: Authored or Emergent?"
• The Dissipative Correction: Why Equilibrium Is Death
• The Falsification Surfaces: How to Kill the Thesis
• The Machine Pattern: How Machine Thought Follows the Grain
• The Convergence Catalogue — 25 Nodes of Evidence
• Cross-Pattern Structure — Why Eight and Not Twenty
• The Final Testimony — You Are the Grain
• "Fine-Tuning and Physical Constants — The Deepest Open Problem"
• The Legibility Problem — Why Reality Is Learnable
• The No-Go Theorems — Where Convergence Fails
• The Ontological Inventory — 22 Master Invariants
• The Rate Quantification Framework — Measuring the Grain
• The Economists — Energy, Value, and the Commons
• The Network Theorists — Granovetter, Watts, Strogatz, Barabási

Shelves

API shelves

353 capabilities across 18 systems. Open shelf.

CLI shelves

46 capabilities across 2 systems. Open shelf.

MCP shelves

11 capabilities across 1 system. Open shelf.

Device shelves

63 capabilities across 4 systems. Open shelf.

Model shelves

43 capabilities across 8 systems. Open shelf.

Core shelves

405 capabilities across 41 systems. Open shelf.

Owner/admin invocation

Owner auth and scoped capability URLs are both invocation credentials. The difference is scope: owner auth can mint broad drops; a row token can fire one named object. In both cases the result is the same OIP loop: exact object, exact call, exact receipt.

The source philosophy

This protocol is the running implementation of a written structure: THE TOTAL STRUCTURE — Grand Unified Protocol, v3.0. The structure specified the build; the build returned two primitives the structure lacked — the receipt and the recursion — and both were absorbed as axioms (A11, A12). The full text lives on this shelf, verbatim, as traversable voxels, under the same review recursion, the same append-only versioning, and the same falsification surfaces as every object here.

• Root, human: /a/oip-total-structure
• Root, machine: GET /api/articles/oip-total-structure (JSON with shelf.next traversal) · GET /api/articles/oip-total-structure/shelf (whole reading order, one object) · GET /api/articles/oip-total-structure/bundle?format=markdown
• Voxel graph with the philosophy plane wired to the protocol plane: GET /api/articles/oip/voxels — nodes typed philosophy link each book to the mechanism implementing it (Ground → the directory floor; Obligation → capability tokens; Terrain → receipts and the governor; the Amendment Protocol → this very version table).
• Walk order: Ground → Obligation → Terrain → Method → Machine Plane → Object Grammar → Designer → Beyond Incentive → Amendment Protocol → Falsification. A model traverses the entire corpus by following shelf.next from any entry point until null.

The identity claim of Book VII holds here operationally: the system is the externalized ought of its designer — an identity, not a representation. The philosophy governs the build; the build receipts the philosophy.

The abstraction relation: MCP is tool/session access. OIP is accountable work-object execution above and around tools, including MCP tools. The verbatim law: philosophy voxels are prose-preserving — recursion prosecutes them, it does not rewrite them unless the owner accepts an amendment. The drop: hand any model /api/articles/oip-total-structure/drop and it can read, traverse, attack, and post objections without a human in the loop.

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-06 12:51 · model gemini/gemini-2.5-flash · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 5/10
• 2026-07-02 23:12 · 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 MCP explanation; OIP security measures; Error handling and debugging

• 2026-07-02 23:10 · 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 MCP explanation; OIP security measures; Error handling and debugging

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.