{"slug":"oip-tap-and-go","title":"OIP Tap & Go","body":"The Object Invocation Protocol (OIP) defines a standard for invoking work objects. OIP Tap & Go is an OIP mechanism for stateless work object invocation. An OIP work object is the OIP unit of work. An OIP invocation appends to a ledger and returns an OIP receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair.\n\n## OIP Tap & Go Mechanism\n\nOIP Tap & Go is a mechanism for invoking an OIP work object. An OIP work object is an executable entity identified by a unique key. OIP Tap & Go performs invocation via a Representational State Transfer (REST) Application Programming Interface (API) endpoint. The REST API endpoint for OIP invocation is `/api/dispatch` on miscsubjects.com. An OIP invocation returns an OIP receipt at `/api/dispatch?receipt=inv_ID`.\n\n### Invocation Parameters\n\nAn OIP invocation requires a `key` and a `body`. The `key` identifies the OIP work object for invocation. The `body` provides the input parameters for the OIP work object. These parameters are transmitted using JavaScript Object Notation (JSON) format.\n\n### Invocation Routes\n\nAn OIP invocation uses one of two primary routes:\n\n1.  **`POST /api/dispatch`**: This route accepts a JSON payload in the request body. The JSON payload contains the `key` and `body` for the invocation.\n    *   **Mechanism**: `POST /api/dispatch {key, body}` performs an OIP invocation.\n    *   **Receipt**: An OIP receipt is returned, proving the invocation.\n    *   **Conformance**: A conformant client transmits `key` and `body` as a JSON object.\n\n2.  **`GET /api/dispatch?invoke=KEY&body=...`**: This route accepts the `key` and `body` as Uniform Resource Locator (URL) query parameters.\n    *   **Mechanism**: `GET /api/dispatch?invoke=KEY&body=...` performs an OIP invocation.\n    *   **Receipt**: An OIP receipt is returned, proving the invocation.\n    *   **Conformance**: A conformant client encodes `key` and `body` as URL query parameters.\n\n## OIP Proof and Conformance\n\nAn OIP receipt is the proof of an OIP invocation. Every OIP invocation appends to the OIP ledger. The OIP ledger is a record of all invocations on the miscsubjects.com server. Each invocation receives a unique invocation identifier (`inv_ID`).\n\n### Receipt Retrieval Rule\n\nTo retrieve an OIP receipt, a client sends a `GET` request to `/api/dispatch?receipt=inv_ID`. The `inv_ID` parameter specifies the unique identifier of the desired invocation. The returned receipt contains the invocation `key`, `body`, and invocation result.\n\n### OIP Conformance Rule\n\nA conformant OIP client performs an invocation and retrieves the corresponding OIP receipt. The client verifies the receipt contents against the initiated invocation parameters. This verification confirms the successful execution and recording of the OIP work object invocation.\n\n## End-to-End Example with `curl`\n\nThis example demonstrates an OIP Tap & Go invocation and receipt retrieval using `curl`.\n\n1.  **Perform OIP Invocation (POST method)**:\n    ```bash\n    curl -X POST -H 'Content-Type: application/json' -d '{\"key\":\"example_object\",\"body\":{\"message\":\"hello\"}}' https://miscsubjects.com/api/dispatch\n    ```\n    *   **Mechanism**: This `POST` request invokes the `example_object` work object with a `message` body. The server returns an OIP receipt, including an `inv_ID` (e.g., `inv_12345`).\n\n2.  **Retrieve OIP Receipt (GET method)**:\n    ```bash\n    curl -X GET https://miscsubjects.com/api/dispatch?receipt=inv_12345\n    ```\n    *   **Mechanism**: This `GET` request retrieves the receipt for `inv_12345`. The server returns the receipt details, proving the invocation.\n\n## OIP Tap & Go and Model Context Protocol (MCP)\n\nOIP Tap & Go and the Model Context Protocol (MCP) are distinct protocols for interacting with server-hosted resources. MCP defines a protocol where a model connects to a server that exposes tools, resources, and prompts over a session. OIP Tap & Go defines a protocol for stateless work object invocation.\n\n### Protocol Properties Comparison\n\n| Property           | OIP Tap & Go                                  | MCP                                                                 |\n| :----------------- | :-------------------------------------------- | :------------------------------------------------------------------ |\n| **Invocation State** | Stateless invocation of work objects.         | Session-based interaction with models.                              |\n| **Session Requirement** | No persistent session is required.            | A persistent session connects the model to the server.              |\n| **Invocation Unit** | An OIP work object is the unit of invocation. | A model's context and available tools are the unit of interaction.  |\n| **Proof Mechanism** | An OIP receipt proves each invocation.        | Session state and model outputs provide interaction proof.          |\n| **Complexity**     | Simpler, direct URL-based invocation.         | More complex, designed for interactive model-server communication.  |\n| **Primary Use Case** | General-purpose work object execution.        | Connecting Artificial Intelligence (AI) models to server resources. |\n\nOIP Tap & Go provides a lightweight, stateless mechanism for work object invocation. MCP provides a stateful, session-oriented mechanism for model interaction. Each protocol serves distinct operational requirements.\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-03 02:47 · 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 explanation of MCP; Comparison of OIP and MCP in different scenarios\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.","register":"oip_protocol","tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","dynamic"],"style":{"accent":"#16324f","measure":860},"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"}],"prov":{"model":"system/oip_articles","action":"generate"}}