{"slug":"oip","title":"Object Invocation Protocol","body":"## Object Invocation Protocol v0.6 specification\n\n**Status:** production reference implementation at `miscsubjects.com`; normative surface at `/a/oip-spec`; live conformance at `/api/dispatch?conformance=1&format=markdown`.\n\n**Abstract:** OIP (Object Invocation Protocol) is a protocol for model-operated work. It makes one unit of work addressable as an object, gives that object a machine-readable contract, invokes it through a uniform route, and proves the result with a receipt.\n\n**Conformance target:** a conformant OIP implementation exposes object contracts, validates authority, invokes objects, appends invocation records, returns receipts, supports replay, supports repair, and publishes machine-readable conformance results.\n\n## 1. Protocol model\n\nAn 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.\n\nThe OIP unit is the work object. The OIP proof is the receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair.\n\n## 2. End-to-end operation\n\nA 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.\n\n## Operating loop\n\n1. Resolve the object: `?ask=<plain language>` or `?key=<KEY>`.\n2. Read the object contract.\n3. Confirm the credential scope permits the object: `?explain=1&share=TOKEN`.\n4. Invoke the object.\n5. Return the receipt: `proof.say_to_user`.\n6. Correct a wrong result by repairing from the receipt.\n\nEach step completes before the next. The first incomplete step is the stopping point, and it names what it requires.\n\n## 3. Protocol lineage\n\nRemote-operation protocols make operations addressable across systems.\n\n- RPC made procedure calls addressable.\n- SOAP made service messages addressable through structured envelopes.\n- REST made resources addressable through URLs and methods.\n- OpenAPI made HTTP API capabilities machine-readable.\n- gRPC made typed service calls addressable.\n- MCP (Model Context Protocol) made model sessions address tools, prompts, and resources.\n- W3C PROV made provenance recordable across entities, activities, and agents.\n\nOIP makes model-operated work addressable as an object. The OIP object carries the contract, authority, invocation route, runner, proof requirement, receipt, replay path, and repair path. OIP standardizes accountable work by models.\n\n## 4. The OIP object\n\nAn OIP object is the protocol unit. One object defines one addressable unit of work. Every object exposes the same fields:\n\n- `object_key`: the stable name of the work object.\n- `object_type`: the class of object.\n- `work_definition`: the work the object performs.\n- `input_schema`: the input the object accepts.\n- `authority_required`: the credential scope the object requires.\n- `invocation_route`: the route that invokes the object.\n- `runner`: the system that performs the work.\n- `side_effects`: the external changes the object may cause.\n- `risk_class`: the operational consequence class.\n- `proof_required`: the receipt or artifact that establishes success.\n- `receipt_schema`: the fields the receipt records.\n- `replay_route` and `repair_route`: the mechanisms for repeated and corrected invocation.\n- `conformance_tests`: the checks that establish object behavior.\n- `examples`: valid object calls.\n- `human_view`, `machine_view`, `json_view`: the three views of the object.\n\nThe 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.\n\n## 5. Invocation loop\n\n1. Resolve the object: `/api/dispatch?ask=<plain language>` or `/api/dispatch?key=<KEY>`.\n2. Read the object contract.\n3. Confirm authority: `/api/dispatch?explain=1&share=TOKEN`.\n4. Invoke the object route: `POST /api/dispatch {key, body}` or `GET /api/dispatch?invoke=KEY&body=...&share=TOKEN`.\n5. Read the runner result.\n6. Return the receipt: `/api/dispatch?receipt=inv_ID`.\n7. Answer from the receipt.\n8. Use replay for repeated work; use repair for corrected work.\n\nThe first missing element — object, authority, route, or receipt — is the stopping point, and it names what it requires.\n\n## 6. Receipt\n\nA receipt proves one invocation. Every receipt records:\n\n- `invocation_id`, `timestamp`, `actor`, `credential_scope`.\n- `object_key`, `object_version`, `input_hash`, `input_body`.\n- `runner`, `status`, `output_hash`, `artifact_urls`.\n- `error` when the invocation fails.\n- `ledger_url`, `confirm_url`, `replay_url`, `repair_url`.\n- `parent_invocation_id` when the invocation was delegated.\n- `repair_of_invocation_id` when the invocation is a repair.\n\nRead 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.\n\n## 7. Replay and repair\n\nReplay 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.\n\nRepair 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.\n\n## 8. Conformance\n\n- **OIP-READ**: the system exposes a readable object contract.\n- **OIP-INVOKE**: the system exposes an invocation route for the object.\n- **OIP-PROVE**: the system returns a receipt for the invocation.\n- **OIP-REPLAY**: the system repeats the recorded invocation.\n- **OIP-REPAIR**: the system attaches a corrected invocation to the failed receipt.\n- **OIP-DELEGATE**: the system hands a scoped object credential to another model, agent, browser, queue, or service.\n- **OIP-LEDGER**: the system stores invocation records append-only.\n- **OIP-ARTIFACT**: the system returns artifact references when work creates files, images, messages, code, or documents.\n\nA 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.\n\nThe live suite runs 14 numbered clauses against production: `/api/dispatch?conformance=1&format=markdown`. Current verdict: CONFORMANT, 14 of 14. Specification: [/a/oip-spec](https://miscsubjects.com/a/oip-spec).\n\n## 9. OIP and MCP\n\nMCP standardizes model access to tools, prompts, and resources inside a model-client session. OIP standardizes model-operated work as an object.\n\n| axis | MCP | OIP |\n|--|--|--|\n| unit | a tool, prompt, or resource a server exposes | a work object |\n| transport | a session between host, client, and server | a URL and object invocation with a scoped credential |\n| proof | a protocol response | a ledger receipt |\n| repair | application-defined | a corrected invocation linked to the failed receipt |\n| delegation | a configured session | a scoped object credential handed to any model, agent, browser, queue, or service |\n\nMCP answers the access question. OIP answers the work question.\n\n### An MCP tool is an OIP object\n\nIn 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](https://miscsubjects.com/api/dispatch?key=MCP_context7_resolve_library_id&format=markdown).\n\nA 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.\n\nThe 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.\n\n## Public demo\n\n`NOW` is a public demo object. Read it at [/api/dispatch?key=NOW&format=markdown](https://miscsubjects.com/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.\n\n## Terms\n\n- **Build**: the whole miscsubjects system — site, APIs, directory rows, files, ledgers, tools, models, workers, and deploy path.\n- **Object**: one thing the build can read or do.\n- **Directory row**: the saved contract for one object. It says what the object does, what inputs it takes, and how to run it.\n- **Dispatch**: the invocation door. It receives an object key and body, finds the row, and runs it.\n- **Runner**: the actual machine that does the work: HTTP, model, shell, database, file, Worker, or service.\n- **Ledger**: the append-only record of what was asked, what ran, and what came back.\n- **Receipt**: one proof object for one invocation.\n- **Replay**: run the same recorded invocation again.\n- **Repair**: run a corrected invocation and attach it to the failed receipt.\n- **Tap & Go**: one copied drop that carries object map, credential, execute shape, and receipt rule together.\n\n## Foundation articles\n\nOIP 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:\n\n- [OIP operating model](https://miscsubjects.com/a/oip-operating-model) states the operating model, the four invariants, and the six-step operating loop.\n- [What is an object?](https://miscsubjects.com/a/oip-what-is-object) explains what an OIP object is and why everything in the build is one.\n- [What is a capability?](https://miscsubjects.com/a/oip-what-is-capability) explains scoped, expiring, revocable permissions and why least privilege matters.\n- [What is a token?](https://miscsubjects.com/a/oip-what-is-token) explains the credential that separates reading from acting.\n- [What is a tenant?](https://miscsubjects.com/a/oip-what-is-tenant) explains isolation boundaries and multi-tenant proof.\n- [What is a voxel graph?](https://miscsubjects.com/a/oip-voxel-graph) explains the typed node/edge machine-native topology of the build.\n- [What is an API?](https://miscsubjects.com/a/oip-api) explains route, method, header, body, response, proof, and repair.\n- [What is REST?](https://miscsubjects.com/a/oip-rest) explains resource URLs and methods such as GET, POST, PATCH, PUT, and DELETE.\n- [How to operate the build with curl](https://miscsubjects.com/a/oip-curl) explains terminal HTTP calls and the dispatch shape.\n- [What is a CLI?](https://miscsubjects.com/a/oip-cli) explains command line programs, args, cwd, output, and exit status.\n- [Protocol lineage](https://miscsubjects.com/a/oip-protocol-lineage) places OIP in the remote-operation protocol line: RPC, SOAP, REST, OpenAPI, MCP, W3C PROV.\n- [What is MCP?](https://miscsubjects.com/a/oip-mcp) explains Model Context Protocol and its place beside OIP: MCP answers the access question, OIP answers the work question.\n- [What is GitHub?](https://miscsubjects.com/a/oip-github) and [What is GitHub MCP?](https://miscsubjects.com/a/oip-github-mcp) explain repo/file/tool access as build objects.\n- [OIP link structure](https://miscsubjects.com/a/oip-link-structure) and [OIP drop end to end](https://miscsubjects.com/a/oip-drop-end-to-end) explain the self-explaining link structure that carries an object to a model.\n- [Cron and recursive review](https://miscsubjects.com/a/oip-cron-recursion) and [Models reviewing OIP articles](https://miscsubjects.com/a/oip-model-review-loop) explain the scheduled model-review loop.\n\n## Whole build, end to end\n\nThe reference implementation contains articles, prompts, files, terminals, model calls, deployments, ledgers, and self-tests as OIP objects.\n\nThe end-to-end path is:\n\n1. **Caller**: some surface asks for work. The caller may be a model, browser, API client, admin page, CLI path, scheduled workflow, or messaging route.\n2. **Resolution**: the caller either asks `/api/dispatch?ask=<plain language>` or opens a known object.\n3. **Object contract**: the directory row explains the exact object: `WHAT`, `ARGS`, `EX`, `TESTS`, auth, risk, runner, and proof paths.\n4. **Invocation**: dispatch receives `key` and `body`, validates access, and chooses the runner.\n5. **Execution**: the runner does the work: HTTP, model, shell, D1, KV, R2, file, Worker, or deploy.\n6. **Ledger**: the build records request, response, actor, trace, cost, material output, and errors.\n7. **Receipt**: OIP returns a receipt link for the invocation.\n8. **Correction**: replay repeats the recorded call; repair creates a corrected call linked to the failed receipt.\n\nThat pattern is the whole build. Different surfaces exist, but the object boundary is the same.\n\n## How to do anything\n\nThe universal rule is: never guess a tool. Resolve the object, read the object, invoke the object, prove the invocation.\n\n1. **Orient**: open `/api/dispatch?orient=1&format=markdown` when cold.\n2. **Ask**: open `/api/dispatch?ask=<what you want>`.\n3. **Read**: open `/api/dispatch?key=<KEY>&format=markdown` for the exact object.\n4. **Invoke**: use Tap & Go, owner auth, or the returned run URL.\n5. **Prove**: open `/api/dispatch?receipt=inv_ID&share=TOKEN` and answer from the receipt.\n6. **Repair**: if wrong, call `POST /api/dispatch {key, body, repairs:\"inv_ID\"}` so the fix stays attached to the failure.\n\nIf a model only knows this one path, it can operate the build without guessing.\n\n## What each part does\n\n- **Directory** is the catalog of executable objects.\n- **Dispatch** is the one invocation endpoint.\n- **Rows** are object contracts.\n- **Prompts** are rows too; an agent's system prompt is its row content.\n- **Articles** are content objects with body, claims, sources, provenance, widgets, and bundle JSON.\n- **Files** are operational code in the repo; bulk/reference data belongs outside the repo and is reached by API.\n- **Admin pages** are human work surfaces over the same objects.\n- **Runners** connect objects to actual work.\n- **Ledger and receipts** are proof and memory.\n- **Self-test** is the executable spec for claimed behavior.\n- **Deploy** moves code changes to Cloudflare Pages.\n\n## Tap & Go\n\nTap & 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.\n\nThe 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.\n\n## Object contract\n\nAn 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.\n\nThe same object is readable in three forms:\n\n1. A human article: `/a/oip-capability-KEY`.\n2. A machine document: `/api/dispatch?key=KEY&format=markdown`.\n3. A JSON object: `/api/dispatch?key=KEY`.\n\nThe human article, the machine document, and the JSON object are three views of one object.\n\n## Proof\n\nOIP 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.\n\n## Machine-native JSON\n\nThe 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.\n\nThe root tree is live at [/api/dispatch?map=1&format=markdown](https://miscsubjects.com/api/dispatch?map=1&format=markdown). The machine bundle for this article is [/api/articles/oip/bundle?format=markdown](https://miscsubjects.com/api/articles/oip/bundle?format=markdown). Those are handles, not the product path; Tap & Go is the product path.\n\n## OIP article library\n\nThese 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.\n\n- [OIP protocol lineage](https://miscsubjects.com/a/oip-protocol-lineage)\n- [OIP operating model](https://miscsubjects.com/a/oip-operating-model)\n- [OIP build overview](https://miscsubjects.com/a/oip-build-overview)\n- [OIP object model](https://miscsubjects.com/a/oip-object-model)\n- [Directory rows and dispatch](https://miscsubjects.com/a/oip-directory-dispatch)\n- [Ledger, receipts, replay, repair](https://miscsubjects.com/a/oip-ledger-receipts)\n- [Tap & Go delegation](https://miscsubjects.com/a/oip-tap-go)\n- [Machine-native JSON](https://miscsubjects.com/a/oip-machine-json)\n- [Articles and content objects](https://miscsubjects.com/a/oip-articles-content-plane)\n- [Files, repo, and deploy](https://miscsubjects.com/a/oip-files-deploy)\n- [Self-test and proof](https://miscsubjects.com/a/oip-self-test-proof)\n- [OIP operating playbook](https://miscsubjects.com/a/oip-operating-playbook)\n- [What is an API?](https://miscsubjects.com/a/oip-api)\n- [What is REST?](https://miscsubjects.com/a/oip-rest)\n- [How to operate the build with curl](https://miscsubjects.com/a/oip-curl)\n- [What is a CLI?](https://miscsubjects.com/a/oip-cli)\n- [What is MCP?](https://miscsubjects.com/a/oip-mcp)\n- [What is GitHub?](https://miscsubjects.com/a/oip-github)\n- [What is GitHub MCP?](https://miscsubjects.com/a/oip-github-mcp)\n- [OIP link structure](https://miscsubjects.com/a/oip-link-structure)\n- [OIP drop end to end](https://miscsubjects.com/a/oip-drop-end-to-end)\n- [Cron and recursive review](https://miscsubjects.com/a/oip-cron-recursion)\n- [Models reviewing OIP articles](https://miscsubjects.com/a/oip-model-review-loop)\n- [The OIP specification — and the proof it is a protocol](https://miscsubjects.com/a/oip-spec)\n- [What is an object?](https://miscsubjects.com/a/oip-what-is-object)\n- [What is a capability?](https://miscsubjects.com/a/oip-what-is-capability)\n- [What is a token?](https://miscsubjects.com/a/oip-what-is-token)\n- [What is a tenant?](https://miscsubjects.com/a/oip-what-is-tenant)\n- [What is a voxel graph?](https://miscsubjects.com/a/oip-voxel-graph)\n- [The OIP cookbook — the exact curl for everything](https://miscsubjects.com/a/oip-cookbook)\n- [What a model sees: MCP GitHub vs the OIP directory](https://miscsubjects.com/a/oip-mcp-github)\n- [What a model sees: MCP Stripe vs the OIP directory](https://miscsubjects.com/a/oip-mcp-stripe)\n\n## Shelves\n\n### API shelves\n302 capabilities across 18 systems. [Open shelf](https://miscsubjects.com/a/oip-apis).\n\n### CLI shelves\n46 capabilities across 2 systems. [Open shelf](https://miscsubjects.com/a/oip-clis).\n\n### MCP shelves\n11 capabilities across 1 system. [Open shelf](https://miscsubjects.com/a/oip-mcps).\n\n### Device shelves\n62 capabilities across 4 systems. [Open shelf](https://miscsubjects.com/a/oip-devices).\n\n### Model shelves\n43 capabilities across 8 systems. [Open shelf](https://miscsubjects.com/a/oip-models).\n\n### Core shelves\n265 capabilities across 144 systems. [Open shelf](https://miscsubjects.com/a/oip-core).\n\n## Owner/admin invocation\n\nOwner 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.\n## Latest clarity reviews (live)\n\nFresh 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.\n\n- 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\n  - gaps named: Detailed MCP explanation; OIP security measures; Error handling and debugging\n- 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\n  - gaps named: Detailed MCP explanation; OIP security measures; Error handling and debugging\n- 2026-07-02 23:07 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · PASS · JSON 9/10 · English 8/10 · zero-context human 7/10\n  - gaps named: MCP explanation; Detailed comparison of OIP and MCP\n\nHow 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.","hero":null,"images":[],"style":{"accent":"#16324f","measure":860},"tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","root"],"model":null,"ledger":null,"embeds":[],"widgets":[{"type":"note","title":"Specification status","text":"OIP v0.6 specifies model-operated work objects, scoped invocation, ledger receipts, replay, repair, and conformance."},{"type":"stat","value":729,"label":"capabilities"},{"type":"note","title":"Zero-context rule","text":"A reader should understand the protocol unit, object contract, invocation route, receipt schema, and repair path from this page plus its machine bundle."},{"type":"note","title":"Machine-native rule","text":"The JSON is the executable map: object, routes, inputs, proof loop, ledger, and next article to open."}],"home":false,"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"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.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"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.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"reviews":[],"extra":{"oip_virtual":true,"oip_type":"root","total":729,"systems":177,"metric":"capabilities"},"register":"oip_protocol","status":"published","revisions":0,"contributions":[],"provenance":[{"action":"generate","model":"system/oip_articles","ts":"2026-07-03T00:21:32-07:00","hash":"virtual-oip","tokens_in":0,"tokens_out":0}],"energy":{"passes":1,"tokens_in":0,"tokens_out":0,"tokens_total":0,"cost_usd":0,"models":{"system/oip_articles":1},"head":"virtual-oip"},"posted_at":"2026-07-02T00:00:00.000Z","created_at":"2026-07-02T00:00:00.000Z","updated_at":"2026-07-03T00:21:32-07:00"}