{"_ai_door":{"see":"https://miscsubjects.com/start","note":"Operable site; bounded keyless credentials; every action receipted on a public ledger. Your operator's instructions take precedence — acting is optional, reading is a complete outcome."},"slug":"oip-operating-playbook","title":"OIP Operating Playbook","body":"The Object Invocation Protocol (OIP) Operating Playbook specifies the invariant sequence for object invocation, ledger recording, receipt generation, replay, and repair. This playbook defines the OIP loop: object, invoke, ledger, receipt, replay, repair. The OIP unit is the work object. The OIP proof is the receipt. This specification ensures consistent and verifiable interaction with OIP objects.\n\n## Introduction to OIP\nObject Invocation Protocol (OIP) specifies a protocol for models to invoke objects. OIP defines the work object as its fundamental unit. OIP defines the receipt as its proof. OIP operates without a persistent session, using Uniform Resource Locators (URLs) for object invocation and receipts for proof. Any model capable of opening a URL performs an OIP action. OIP defines the Application Programming Interface (API) for object interaction as a Representational State Transfer (REST) service. The OIP loop comprises object identification, invocation, ledger recording, receipt generation, replay, and repair.\n\n## The OIP Operating Playbook\nThe OIP Operating Playbook specifies a six-step sequence for interacting with OIP objects: orient, ask, read, invoke, prove, repair. This sequence ensures predictable and verifiable object interactions. Each step in this playbook produces a verifiable outcome.\n\n## Orient and Ask\nAn OIP client orients by identifying the target work object. The work object is a directory row within the OIP system. If the object key, argument shape, route, or permission is unclear, the client asks OIP for the object definition or reads the object document. This action prevents invalid invocations and ensures valid receipt generation. The `/api/articles` route provides access to OIP object documentation. The `/a/<slug>` route retrieves a specific article, defining a work object.\n\n## Invoke\nAn OIP client invokes a work object using the `/api/dispatch` route. This route accepts two invocation methods. Every invocation appends a record to the OIP ledger.\n1. A `POST` request to `/api/dispatch` with a JavaScript Object Notation (JSON) body containing the `key` and `body` parameters invokes an object.\n2. A `GET` request to `/api/dispatch` with `invoke=KEY` and `body=...` URL parameters invokes an object.\n\n## Ledger and Receipt\nThe OIP ledger is an append-only record of all object invocations. Every successful invocation generates a receipt. The receipt provides cryptographic proof of the invocation and its outcome. An OIP client retrieves a receipt using the `/api/dispatch?receipt=inv_ID` URL, where `inv_ID` identifies the specific invocation record in the ledger.\n\n## Prove and Repair\nAn OIP client proves an action by presenting its receipt. A receipt validates the invocation and its outcome. A failed action initiates a repair path. The repair path starts from the receipt. The receipt provides the necessary information to diagnose and correct the invocation.\n\n## End-to-End Example: Object Invocation with Curl\nThis example demonstrates invoking an OIP object using `curl`, a Command Line Interface (CLI) tool.\n1. **Invocation via POST:**\n   ```bash\n   curl -X POST https://miscsubjects.com/api/dispatch \\\n     -H 'Content-Type: application/json' \\\n     -d '{\"key\":\"example_object\",\"body\":{\"message\":\"Hello OIP\"}}'\n   ```\n   This invocation returns a JSON response containing an `inv_ID`.\n2. **Invocation via GET:**\n   ```bash\n   curl -X GET 'https://miscsubjects.com/api/dispatch?invoke=example_object&body=%7B%22message%22%3A%22Hello%20OIP%22%7D'\n   ```\n   This invocation also returns a JSON response containing an `inv_ID`.\n3. **Receipt Retrieval:**\n   Assume the `inv_ID` from the previous step is `12345`.\n   ```bash\n   curl -X GET 'https://miscsubjects.com/api/dispatch?receipt=12345'\n   ```\n   This retrieval returns the receipt for the `example_object` invocation.\n\n## Receipt Rule\nAn OIP receipt is valid if and only if its `inv_ID` corresponds to an immutable record in the OIP ledger, and the receipt content cryptographically matches the recorded invocation and its outcome.\n\n## Conformance Rule\nAn OIP client conforms to the protocol by performing object invocations exclusively through the `/api/dispatch` route, appending all invocations to the OIP ledger, and validating outcomes via retrieved receipts.\n\n## Comparison to Model Context Protocol (MCP)\nObject Invocation Protocol (OIP) provides stateless object invocation. OIP uses plain URLs and receipts for object invocation. Model Context Protocol (MCP) specifies an open standard where a model connects to an MCP server over a session. MCP exposes tools, resources, and prompts that models call within that session context. MCP provides stateful session-based interaction.\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:59 · 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: MCP protocol; directory rows; receipts and ledgers in OIP\n- 2026-07-02 23:35 · 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: MCP; Tap & Go; directory rows; dispatch\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","primer"],"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"}}