{"_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-files-deploy","title":"Files, Repository, and Deployment","body":"An OIP (Object Invocation Protocol) file object represents a unit of operational code or data. Every OIP file object is versioned within a repository. Deployment of an OIP file object publishes its current version to a live service. The OIP loop (object, invoke, ledger, receipt, replay, repair) ensures file object integrity and provable deployment. An OIP file object is invoked via `/api/dispatch` and yields a receipt at `/api/dispatch?receipt=inv_ID`.\n\n## Introduction to OIP\n\nOIP (Object Invocation Protocol) specifies a protocol for object invocation, ledger recording, and receipt generation. OIP enables models to interact with objects using Uniform Resource Locators (URLs) and receipts. OIP establishes stateless interactions. An OIP unit is the work object. The OIP proof is the receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair. Any model capable of opening a Uniform Resource Locator (URL) invokes OIP objects. OIP defines a standard for object invocation, ledger recording, and receipt generation.\n\n## Operational Files\n\nOperational code resides within a repository. A repository is a version-controlled collection of OIP file objects. Raw bulk data and reference sprawl exist external to the repository. These external resources are accessed through Application Programming Interfaces (APIs). An API is a set of defined rules enabling different applications to communicate. A server hosts these APIs. A server is a computer or device providing services or data to other computers or devices.\n\n## File Object Operations\n\nAn OIP file object supports read, edit, delete, commit, and deploy operations. These operations are performed through OIP invocations to the `/api/dispatch` route. An OIP file object's state is retrieved via `/api/dispatch` invocations.\n\nTo invoke a file object operation, a client sends a request to the `/api/dispatch` route.\n- A `POST /api/dispatch {key, body}` request invokes an object with a specified key and body.\n- A `GET /api/dispatch?invoke=KEY&body=...` request invokes an object with a specified key and body.\nEvery invocation appends to the ledger. Every invocation returns a receipt at `/api/dispatch?receipt=inv_ID`.\n\n## Deployment Mechanism\n\nDeployment moves the current version of an OIP file object to a live service. Cloudflare Pages is a platform that hosts and serves web applications. An OIP deployment mechanism publishes file objects to Cloudflare Pages. A deployed feature is proven through its build's proof path. A proof path is a sequence of verifiable steps demonstrating successful deployment.\n\nThe Tap & Go deployment mechanism is an OIP invocation. This invocation triggers a pre-configured deployment pipeline for a file object. This mechanism requires a specific `deploy` key and a body containing deployment parameters.\n\n## Comparison to Model Context Protocol (MCP)\n\nMCP (Model Context Protocol) establishes a persistent session between a model and a server. An MCP server exposes tools, resources, and prompts for model invocation within this session. OIP establishes stateless interactions. OIP relies on stateless Uniform Resource Locator (URL) invocations and receipts for proof. OIP's stateless nature allows any URL-capable model to invoke objects directly. MCP's session-bound interactions maintain state across multiple invocations. OIP's operational model is stateless invocation; MCP's operational model is session-bound invocation. OIP's proof mechanism is the receipt; MCP's context mechanism is the session state.\n\n## End-to-End Example: Deploying a File Object\n\nThis example demonstrates deploying a file object named `my-app-file` to Cloudflare Pages.\n\n1.  **Commit the file object:** A client commits a file object to the repository. This action generates a commit receipt.\n    `POST /api/dispatch`\n    `{ \"key\": \"commit_file\", \"body\": { \"filename\": \"my-app-file.js\", \"content\": \"console.log('Hello OIP!');\", \"repo_id\": \"my-repo\" } }`\n    This invocation appends to the ledger and returns a receipt `inv_COMMIT_ID`.\n\n2.  **Invoke deployment:** A client invokes the deployment mechanism for the committed file object.\n    `POST /api/dispatch`\n    `{ \"key\": \"deploy_file\", \"body\": { \"filename\": \"my-app-file.js\", \"repo_id\": \"my-repo\", \"target\": \"cloudflare_pages\", \"commit_id\": \"inv_COMMIT_ID\" } }`\n    This invocation appends to the ledger and returns a receipt `inv_DEPLOY_ID`.\n\n3.  **Verify deployment receipt:** The client retrieves the deployment receipt to confirm the operation.\n    `GET /api/dispatch?receipt=inv_DEPLOY_ID`\n    The receipt confirms the successful publication of `my-app-file.js` to Cloudflare Pages. The receipt includes the URL of the deployed application.\n\n## Receipt Rule\n\nA deployment receipt `inv_DEPLOY_ID` proves the successful publication of a specific OIP file object version to a designated live service. The receipt contains the `file_key`, `repo_id`, `commit_id` of the deployed version, the `target_service` (e.g., `cloudflare_pages`), and the `deployed_url`. The `deployed_url` provides direct access to the live service.\n\n## Conformance Rule\n\nAn OIP implementation conforms to the file object deployment specification when:\n1.  It accepts `POST /api/dispatch` or `GET /api/dispatch` invocations for file object operations, including deployment.\n2.  It appends every file object operation invocation to the ledger.\n3.  It returns a valid receipt at `/api/dispatch?receipt=inv_ID` for every invocation.\n4.  A deployment receipt `inv_DEPLOY_ID` contains a verifiable `deployed_url` for the published file object.\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:48 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 6/10\n  - gaps named: MCP; Cloudflare Pages; Tap & Go\n- 2026-07-02 23:32 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 6/10\n  - gaps named: MCP; Cloudflare Pages; Tap & Go\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"}}