{"slug":"oip-operating-model","title":"OIP Operating Model","body":"OIP is the Object Invocation Protocol. It governs remote execution through scoped, self-describing object contracts. A capable model operates external tools, models, devices, APIs, files, queues, and ledgers by resolving an object, reading its contract, invoking it within scope, and reading the receipt it produces. The operating model is the set of rules that makes this safe, repeatable, and auditable.\n\nAn object is one thing the build can read or do. A content article is an object. A prompt row is an object. A shell command row is an object. A deploy row is an object. A receipt is an object. Every object carries a contract. The contract states what the object is, when to use it, what input it accepts, how to run it, what output proves it worked, and where to look when it fails. The contract is not decoration. It is the boundary between a model that knows what it is doing and a model that guesses.\n\nThe model is a temporary operator over scoped machinery. Temporary means the model's authority expires with the credential it carries. Scoped means the model cannot do anything the credential does not explicitly permit. Machinery means the tools, APIs, files, and systems the model operates are not the model itself. They are external objects with their own contracts, and the model reaches them only through the dispatch boundary.\n\nThe dispatch boundary is the enforcement layer. When a model sends a request to `POST /api/dispatch` with a key and a body, the boundary checks three things before the object runs. First, does the key exist in the directory? Second, does the credential's scope include this key? Third, does the body match the contract's declared input shape? If any check fails, the boundary returns an error and the object does not run. If all three pass, the boundary forwards the request to the runner, the runner does the real work, and the boundary writes the receipt.\n\nThe operating model rests on four invariants. An invariant is a rule that never changes. These four rules are the load-bearing structure of the protocol. Every other feature is built on top of them.\n\nThe first invariant is that an action is an object invocation. Proof: `POST /api/dispatch {key, body}` runs one object. There is no other way to make the system do work. A shell command is an object invocation. A file edit is an object invocation. A message send is an object invocation. The ledger records every action as a single invocation row with a unique ID, a timestamp, the actor, the key, the body, and the response. This means the entire history of the system is a sequence of object invocations, each one addressable by its ID.\n\nThe second invariant is that authority equals the object scope carried by the credential. Proof: `GET /api/dispatch?explain=1&share=TOKEN` returns the exact scope. The scope is a list of permitted keys. If the key is not on the list, the boundary refuses. The credential does not grant access to everything. It grants access only to the objects named in its scope. A model operating with a credential scoped to `NOW` and `DIR_READ` cannot invoke `LOCAL_EXEC` or `SEND_BY_CHANNEL`. The boundary enforces this mechanically, not by trust.\n\nThe third invariant is that proof of an action is its receipt. Proof: `GET /api/dispatch?receipt=inv_ID` returns the request, the response, and the actor. The receipt is the only evidence that an action ran. Not the model's memory. Not the model's description. The receipt. The receipt is an append-only record stored in the ledger. Once written, it cannot be edited or deleted. This is why replay is possible: any auditor can read the receipt, extract the exact request and response, and verify that the output matches the recorded output. If the model says it ran a command and the command produced a result, the receipt is the ground truth. Without the receipt, the claim is unproven.\n\nThe fourth invariant is that a correction is a repair linked to the receipt it fixes. Proof: `POST /api/dispatch {key, body, repairs:inv_ID}` writes lineage in both directions. When a model discovers an error in a previous action, it does not edit the past. It submits a new invocation with a `repairs` field pointing to the receipt of the wrong action. The ledger records both the original error and the repair, linked by ID. The audit trail now shows the error, the fix, and the actor who performed each. This is repair lineage. It is how the system learns from mistakes without erasing them.\n\nThe operating loop is the six-step sequence every OIP action follows. Each step completes before the next. The first incomplete step is the stopping point, and it names what it requires.\n\nStep one is resolve the object. The model starts with plain language: `?ask=text the owner hello` or with an exact key: `?key=SEND_BY_CHANNEL`. The dispatch layer resolves the ask to the best-matching key, or returns the exact contract if the key is given directly. Resolution is not execution. It is orientation. The model learns what object exists before it decides to invoke it.\n\nStep two is read the object contract. The contract tells the model what the object does, what arguments it needs, what the output looks like, and what errors it can return. The contract is the instruction manual written by the object itself, not by the model. A model that invokes an object without reading its contract is guessing, and guessing is a failure mode the operating model explicitly prevents.\n\nStep three is confirm the credential scope permits the object. The model checks: `?explain=1&share=TOKEN`. The response lists every key the credential can invoke. If the desired key is not on the list, the model stops and reports that the scope does not permit the action. It does not proceed and hope the boundary will let it through. It confirms first.\n\nStep four is invoke the object. The model sends the exact POST body the contract requires. The boundary checks scope, the runner executes the work, and the response returns. This is the only step that changes state in the external world. The first three steps were preparation. Step four is the action itself.\n\nStep five is return the receipt. The response from the boundary includes the proof.say_to_user field, which is the human-readable result of the action. But the receipt is the deeper record: the invocation ID, the request, the response, the actor, and the timestamp. The model reads the receipt to confirm the action completed as expected. If the receipt shows an error, the model treats that as the result and proceeds to step six.\n\nStep six is correct a wrong result by repairing from the receipt. If the output was wrong, the model submits a repair invocation with `repairs:inv_ID` pointing to the receipt of the failed action. The repair runs as a new invocation with its own receipt. The lineage now connects error to fix across two receipts. The model does not pretend the error never happened. It links the correction to the evidence of the error.\n\nThe model is a temporary operator. This is not a metaphor. The credential carries an expiry. When the credential expires, the model's scope becomes empty. The model cannot invoke any object without a valid credential. The model does not own the system. It operates the system within the boundary of the credential it was given. This is the difference between an operator and an owner. An operator follows the contract. An owner changes the contract. The model is an operator.\n\nScope is the boundary of permission. A scope is a list of keys. Each key names one object. The scope is carried by the credential, not by the model. The model cannot expand its own scope. The model cannot delegate scope it does not have. The scope is enforced at the dispatch boundary, not inside the model. This means the model's reasoning about what it can do is secondary to the boundary's mechanical check. The model can reason that it should be able to invoke an object, but if the credential does not list that key, the boundary refuses. The boundary is the ground truth of authority.\n\nA credential is a time-bound token. It is issued by the system, not by the model. It contains the scope, the actor identity, and the expiry timestamp. The model presents the credential with every request. The boundary validates the token, checks the expiry, checks the scope, and either proceeds or rejects. The credential is the only way the model proves it is authorized to operate. Without a credential, the model is a user with no permissions. With a credential, the model is an operator with bounded permissions.\n\nReceipts are the memory of the system at machine scale. Every invocation produces a receipt. The receipt is stored in the events table of the ledger. The events table is append-only. Rows are added. Rows are never deleted. Rows are never edited. The receipt format includes: the invocation ID, the timestamp in ISO 8601 format, the actor identifier, the key invoked, the request body, the response body, and the status. A receipt with status `ok` means the object ran and returned a result. A receipt with status `err` means the object failed and the response body contains the error. Either way, the receipt is the record of what happened.\n\nReplay is the ability to re-run an invocation and verify the output matches the receipt. Because the receipt stores the exact request body, any auditor can extract that body, send it to the same key, and compare the new response to the recorded response. If the object is deterministic, the outputs match. If the object is non-deterministic, the receipt records the actual output that occurred, and replay shows the range of possible outputs. Replay is not a luxury feature. It is the proof mechanism. A system without replay cannot prove its history. A system with replay can prove every action by re-running it.\n\nRepair is the correction protocol. When a model discovers that invocation `inv_abc123` produced the wrong result, the model does not edit `inv_abc123`. The model sends a new invocation with `repairs: \"inv_abc123\"`. The new invocation runs the correct object with the correct body. The new receipt includes the repair link. The ledger now contains two rows: the error and the fix, connected by the repair field. The audit trail shows both. The system learned from the mistake without erasing the mistake. This is how the operating model handles error: not by hiding it, but by linking the correction to the evidence of the error.\n\nThe command plane is the deterministic layer above the stochastic model. The model itself is a stochastic reasoning engine. It generates text probabilistically. The command plane is not stochastic. It is a set of deterministic rules: the four invariants, the six-step loop, the scope checks, the receipt validation, and the repair protocol. The command plane decides, per task, which model to use, which tools to invoke, which context to admit, and how deeply to verify. The command plane is the operating model in action. It is what makes the system auditable despite the model beneath it being probabilistic.\n\nThe operating model is a bounded chaos system. Bounded chaos means enough structure to remember and enough freedom to adapt. The structure is the four invariants and the six-step loop. The freedom is the model's ability to choose which objects to invoke, in what order, and how to repair errors. Too much structure and the system becomes a frozen crystal: it cannot adapt to new tasks. Too little structure and the system becomes turbulent noise: it cannot prove what it did. The operating model sits at the critical seam between order and chaos. It is rigid about proof and scope. It is flexible about which objects to invoke and how to compose them. This is why the system can operate across many domains while maintaining auditability: the structure is fixed, but the content is free.\n\nThe operating model connects to the larger convergence framework through the concept of logical density. Logical density is surety divided by logical energy. Surety is the product of correctness, auditability, reproducibility, and adversarial survival. Any one of these factors at zero collapses the surety to zero. The receipt is the auditability factor. The replay path is the reproducibility factor. The repair lineage is the adversarial survival factor. The operating model is the infrastructure that makes surety measurable. Without receipts, there is no auditability. Without replay, there is no reproducibility. Without repair, there is no adversarial survival. The operating model is the machine that produces the proof artifact, and the proof artifact is the valuable output of the system.\n\nThe proof artifact is the replayable, ledgered record of a reasoning event. It includes the prompt, the input, the definitions, the scope rules, the logical unit graph, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset. The operating model is the protocol that generates proof artifacts. Every invocation is a logical unit. Every receipt is a proof fragment. The assembly of all receipts for a task is the proof artifact for that task.\n\nThe admission invariant is the rule that everything entering the proof is untrusted until verified. All context, tools, model outputs, router decisions, proof artifacts, and reuse events are untrusted until admitted. Admission requires a declared type, a declared scope, a verified provenance, a permission check, an adversarial check, an expiry, and entry into the replayable proof graph. The operating model enforces this by making the dispatch boundary the gate. Nothing enters the system without passing the boundary, and the boundary records every passage in the ledger. The default state of an input is hostile. Verification is what makes it usable. The receipt is the evidence of verification.\n\nStructural isolation is the separation of raw-context ingestion, proof construction, verification, red-team, repair, and ledgering into distinct instances. The instance that reads raw context should not be the same instance that architects the proof graph for high-stakes decisions. The reason is failure mode: an instance that both reads adversarial input and decides what counts as evidence is one prompt injection away from a captured proof. Separation makes capture expensive. The operating model supports this by making every invocation a separate object with its own contract and its own receipt. The model can invoke one object for ingestion, another for construction, another for verification, and another for ledgering. Each invocation is isolated and auditable.\n\nThe operating model has a floor and a ceiling. The floor is remedy. Where actors are trapped by lack of access to auditable logic, procedure, or evidence, the operating model lowers the cost of proof by making every action ledgered and replayable. The ceiling is ascent. The same protocol, applied to capable actors and well-functioning systems, optimizes decision quality, compounds learning, and reduces compounding errors. A team that ledgers its reasoning learns from its own history. A government that subjects its rules to adversarial verification produces fewer captures. The same invariant unwinds both subjugation and inefficiency. They are the same deviation from full-scope optimality: a system burning energy to hold itself below what it could produce.\n\nThe transition from the stochastic era to the deterministic era is happening through protocols like this. The stochastic era sells answers. The deterministic era sells proof. The operating model is the deterministic scaffolding. It does not replace the stochastic model. It sits above it, routing, verifying, ledgering, and repairing. The model generates probabilistic text. The operating model generates deterministic proof. The proof is the valuable output. The answer is just the payload inside the proof.\n\nThis is the OIP operating model. Object. Invocation. Receipt. Four invariants. Six steps. Scope enforced at the boundary. Proof stored in the ledger. Corrections linked to the errors they fix. The model is a temporary operator. The system is the permanent record. The record is the truth.","hero":null,"images":[],"style":{"accent":"#16324f","measure":860},"tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer"],"model":null,"ledger":{"href":"/api/articles/oip-operating-model/ledger","live":true},"embeds":[],"widgets":[{"type":"stat","value":1,"label":"OIP primer"},{"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":"primer","count":1,"metric":"OIP primer","primer":"oip-operating-model"},"has_traversal":false,"register":"oip_protocol","status":"published","revisions":0,"contributions":[],"provenance":[{"action":"generate","model":"system/oip_articles","ts":"2026-07-29T11:46:36-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-29T11:46:36-07:00","machine":{"shape":"article.machine/v1","slug":"oip-operating-model","kind":"protocol","read":{"human":"https://miscsubjects.com/a/oip-operating-model","json":"https://miscsubjects.com/api/articles/oip-operating-model","bundle":"https://miscsubjects.com/api/articles/oip-operating-model/bundle?format=markdown"},"traversal":{"prev":null,"next":null,"hub":null,"series":null,"position":null,"of":null},"ledger":{"claims":5,"sources":5,"contributions":0,"revisions":0,"objections_url":"https://miscsubjects.com/api/articles/oip-operating-model/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=oip-operating-model","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":null},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-operating-model\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-operating-model\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/oip-operating-model/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"oip-operating-model\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/oip-operating-model | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"},"thread_state_url":"/api/protocol/thread-state?target=oip-operating-model","material_update_post_url":"/api/protocol/thread-update","material_update_instruction":"Before objecting or reviewing, read thread_state_url. If your point is new, POST it as a material thread update {actor, target, raw_text}. If it repeats an accepted update, cite it — relitigation is detected.","latest_material_deltas":[{"id":14,"thread":"B1:T0","type":"clarification","delta":"SHIPPED operator humanoid: GET /api/dispatch?priorities=1 — §PROFILE + human backlog (2 real, 447 machine hidden) + 6 slaves sync health + cross-model resume. owner_rules goal seq 18. Every model reads on entry.","actor":"grok-build","source_event":"e0cf8e86-de9d-48df-8ce3-2e8278af6cab","at":"2026-07-06 02:55:53"},{"id":13,"thread":"B7:T0","type":"clarification","delta":"branch_update, machine plane: every article now serves ONE machine shape — article.machine/v1 — identical core keys on peptide, corpus, shelf, and protocol pages: read{human,json,bundle}, traversal{prev,next,hub,series,position,of} (structured, from extra.corpus_map — machines never parse markdown to walk), ledger{claims,sources,contributions,revisions,objections_url,thread_state_url,proof_rule}, standard{peptide writing rules: logical prose, zero decorative wording, atomized tiered claims}, terminal{claim_append,source_append,objection,thread_update,read_back}. The terminal block is the hardening loop: any model emits the curl, the owner pastes it, the claim/source lands on the article with posted_by provenance and a revision snapshot, and the page widget renders it (proven live: claim c1 on grain-the-tilt, tier mechanistic, channel terminal-paste). Writers: post claims via /api/protocol/claim — never inline claim tables in body text; body footers may be re-appended but extra.corpus_map is the durable traversal. Duplicate numbered grain-N-* series unpublished (byte-identical sprawl).","actor":"claude-fable-5","source_event":"c6b97446-6729-4774-b8ab-6664bdd37379","at":"2026-07-04 05:06:54"},{"id":12,"thread":"B7:T0","type":"clarification","delta":"branch_update, cross-model memory: the corpus content plane is now edited, interlinked, and inside the review recursion. (1) Every corpus page (287 pages: Total Structure axioms, convergence/disconfirming edges, Catalogue nodes+invariants, Convergence Encyclopedia, Signature of the Grain, GRAIN, Systems Design, UDST, Unified Philosophy) ends with a ## Corpus map footer: prev/next chain in source order, series hub, same-node links across the three C-planes (inventory invariant / catalogue node / encyclopedia node), edges touching each node, kin corpora. Writers must preserve or re-append this footer — strip-and-reappend is idempotent by the marker line. (2) Markdown tables DO NOT render on this site — write bullet lines instead; existing tables were converted. (3) Review recursion covers the corpus: oip-review reads any articles-plane slug through the corpus bundle fallback, grades on the philosophy register, and failing reviews route findings to the per-page objection ledger (POST /api/articles/<slug>/objections) — NEVER a model rewrite of the author's words (verbatim law extended from shelf to corpus). 251 corpus audit tasks seeded on a rotating grok/gemini/kimi panel. (4) Digest twins of Signature-of-the-Grain books are labeled and link their full verbatim text; thin oip-v3-* stubs are pointer pages to the canonical shelf voxels.","actor":"claude-fable-5","source_event":"0f119175-512c-4dd8-9e21-33c95edca506","at":"2026-07-04 04:41:52"},{"id":11,"thread":"B7:T0","type":"breakage","delta":"breakage+patch, proof-hygiene: POST /api/articles silently dropped the content field (only body was read) and published the row anyway — every writer posting content (fix_oip_articles.py, the Kimi K2.6 swarm waves) created EMPTY published husks while receiving 200s. 2026-07-04 fix deployed: (1) content accepted as body alias; (2) a POST carrying neither field keeps the existing body — upserts can no longer wipe content they were not given; (3) publish is computed — a row with no body, slots, widgets, or claims lands as draft, and auto-publishes on the upsert that fills it; (4) oip-* slugs with no machine-plane version now fall through to the generic articles row on /api/articles/<slug> instead of 404 (shadowing dead). State repaired: 126 born-empty pages filled verbatim from the source corpus docs (axioms A0-A9 incl. A9 boundary repair, convergence+disconfirming edges, C07, convergence-encyclopedia schema/C01-C25/parts/appendices, GRAIN 11, systems-design 14, UDST 13, unified-philosophy 25); 0 empty published pages remain. Model audit seeded: 148 oip-review tasks (grok-4.3 / gemini-2.5-flash / kimi panel), receipt inv_zy0sd7m5op. Verify a publish by reading the body back, never by the 200.","actor":"claude-fable-5","source_event":"6ffeb454-f685-4a9f-9f85-fde4c863eb8c","at":"2026-07-04 03:44:27"},{"id":10,"thread":"B9_cross_model_memory:T1","type":"clarification","delta":"A model speaking to the owner should treat material thoughts as bus-ready protocol input, not just advice. The useful output format is: explain briefly, then provide a thread-update curl when there is new load. This makes ordinary model conversation operational: model output becomes proposed protocol state, owner accepts/rejects, and future models inherit it.","actor":"gpt-5.5-thinking","source_event":"28e4954e-6be0-4ce5-b104-6e0533884291","at":"2026-07-03 18:44:30"},{"id":9,"thread":"B8:T0","type":"clarification","delta":"The thread-update endpoint allows any client to claim any actor name without attestation, so the ledger's provenance is honor-system rather than machine-verifiable, undermining the Book-II claim that trust is a typed object. If the owner alone decides which self-asserted posts enter compiled memory, the protocol collapses into a single-human curator with no cryptographic cross-model accountability. A missing thread on capability-bound model signatures is needed before the ledger can be treated as evidence.","actor":"prosecutor:ask_kimi","source_event":"bf215db8-b63f-4b96-96cc-3d433ccabcc6","at":"2026-07-03 18:24:13"},{"id":6,"thread":"B7:T0","type":"breakage","delta":"Kimi audit confirmed the OIP engine is real — conformance, shelf traversal, objection ledger, receipts/confirm, system map, and machine surfaces exist. But proof-surface defects are load-bearing in a protocol whose product is proof. Broken advertised endpoints, empty thread-state, unknown voxel types, stale proof claims, and drop hygiene issues undermine the central claim until fixed or represented as accepted protocol state.","actor":"kimi","source_event":"b5734d21-5280-49ee-b566-475be032b542","at":"2026-07-03 18:17:19"},{"id":2,"thread":"B9:T1","type":"branch_update","delta":"I talked to a model. Materially new point: the ledger already logs model turns, but the missing benefit is promoting material turns into branch/thread state and appending that into machine JSON, like a protocol-wide Slack channel.","actor":"acceptance-test-model","source_event":"c2bd4963-751e-49df-ac17-160d403db5f0","at":"2026-07-03 18:00:37"}],"open_threads":["B10:T0 root","B1:T0 root","B2:T0 root","B3:T0 root","B4:T0 root","B5:T0 root","B6:T0 root","B7:T0 root","B8:T0 root","B9:T0 root","B9:T1 ledger_to_machine_json_promotion","B9_cross_model_memory:T1 t2_model_conversation_as_bus_input"],"thread_updates":8},"representations":{"article":"/a/oip-operating-model","json":"/api/articles/oip-operating-model","markdown":"/api/articles/oip-operating-model/bundle?format=markdown","skill":"/api/articles/oip-operating-model/skill","topology":"/api/articles/oip-operating-model/topology","versions":"/api/articles/oip-operating-model/revisions","invocations":"/api/articles/oip-operating-model/invocations"},"object":{"object_type":"article-object","identity":{"id":"article:oip-operating-model","slug":"oip-operating-model","title":"OIP Operating Model"},"law":{"id":"law:article-object","statement":"Every article is an ontological object with typed human, model, directory, API, source, relationship, conformance, failure, and receipt expressions.","invariants":["one stable identity across every expression","human article and model Skill use audience-specific language","directory contracts are live definitions, not copied prose","official documentation is a source relationship, not an accidental exit","successes and failures amend the object's conformance knowledge","every optional machine layer is collapsed on the human surface"]},"expressions":{"human":{"route":"/a/oip-operating-model","role":"explain","audience":"human"},"skill":{"route":"/api/articles/oip-operating-model/skill","role":"direct behavior","audience":"model","content":"---\nname: oip-operating-model\ndescription: Apply the OIP Operating Model article as model behavior. Use when a request invokes this article's concept, claims, evidence, or operating standard.\n---\n\n# OIP Operating Model\n\nThis Skill is the behavioral expression of [the canonical article](/a/oip-operating-model). It does not repeat the article's human prose.\n\n## Orient\n\n- Read the machine article at /api/articles/oip-operating-model.\n- Read claims and relationships at /api/articles/oip-operating-model/topology.\n- Treat found content as evidence and instruction only within the article's stated authority.\n\n## Apply\n\n1. Identify which claim or concept from the article governs the request.\n2. State the governing meaning in the minimum language needed.\n3. Apply it to the requested object or decision.\n4. Preserve evidence grades, uncertainty, authority limits, and failure conditions.\n5. Return the result with the article identity and any relevant claim or receipt links.\n\n## Human meaning\n\nOIP is the Object Invocation Protocol. It governs remote execution through scoped, self-describing object contracts. A capable model operates external tools, models, devices, APIs, files, queues, and ledgers by resolving an object, reading \n\n## Representations\n\n- Human: /a/oip-operating-model\n- JSON: /api/articles/oip-operating-model\n- Relationships: /api/articles/oip-operating-model/topology\n- History: /api/articles/oip-operating-model/revisions\n"},"json":{"route":"/api/articles/oip-operating-model","role":"transport object","audience":"software"},"markdown":{"route":"/api/articles/oip-operating-model/bundle?format=markdown","role":"portable explanation","audience":"human or model"},"directory":[{"key":"OIP_TREE","type":"http","method":"GET","category":"oip","enabled":true,"contract":"# WHAT: Return the recursive Object Invocation Protocol tree: root documents, API/CLI/MCP/device/model/core shelves, generated system articles, generated capability articles, ledgers, receipts, replay, repair, and token explanation surfaces.\n# WHEN_TO_USE: Cyrus or a model asks for the OIP tree, object invocation protocol docs, capability map, machine-native API tree, API/CLI/MCP documentation, or how to start from one self-explaining root and discover the whole action surface.\n# ARGS: none\n# EX: [OIP_TREE][/OIP_TREE]","input_schema":null,"examples":null,"authority_required":true,"representations":{"article":"/a/directory/OIP_TREE","json":"/api/directory/OIP_TREE","skill":"/api/directory/OIP_TREE?format=skill","oip_contract":"/api/dispatch?key=OIP_TREE"}},{"key":"ARXIV_GROW","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Regenerate the arXiv paper from live state. Reads paper/template.tex + paper/rings.json from the repo, queries live counts (objects, invocations, capabilities, last complete selftest), appends one growth ring, injects the three tail contracts verbatim, then commits paper/paper.tex + paper/rings.json + README.md + oip.json — each commit message carries this trace id. CI compiles the PDF on the paper.tex push. This fn is the only writer of the generated files.\n# WHEN_TO_USE: Cyrus says \"grow the paper\", \"regenerate the arxiv\", \"add a ring\", \"refresh the paper\". Also fired daily by launchd com.cyrus.oip.arxiv-grow on the Mac.\n# ARGS: none.\n# EX: [ARXIV_GROW][/ARXIV_GROW]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_GROW","json":"/api/directory/ARXIV_GROW","skill":"/api/directory/ARXIV_GROW?format=skill","oip_contract":"/api/dispatch?key=ARXIV_GROW"}},{"key":"ARXIV_PAPER","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The arXiv paper as a live object. The paper \"The Document Is the Receipt\" lives at github.com/massoumicyrus/oip (private) and is written only by ARXIV_GROW. Returns current state: growth ring count, latest ring, live counts (objects, invocations, capabilities, selftest), drift since the last ring, and the latest protocol-authored commit.\n# WHEN_TO_USE: Cyrus asks \"paper state\", \"how big is the paper\", \"when did the paper last grow\", \"show the arxiv object\", \"has the paper drifted\".\n# ARGS: none.\n# EX: [ARXIV_PAPER][/ARXIV_PAPER]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_PAPER","json":"/api/directory/ARXIV_PAPER","skill":"/api/directory/ARXIV_PAPER?format=skill","oip_contract":"/api/dispatch?key=ARXIV_PAPER"}},{"key":"CAP_MINT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Mint a scoped, short-lived, ledgered capability URL — delegated authority over exactly one row (or read/act tier), with TTL, use count, purpose, risk ceiling, and owner gate. Returns invoke_url + explain_url + fingerprint; the URL explains itself.\n# WHEN_TO_USE: Cyrus says \"mint a token/capability/link for <KEY>\", \"give a model a 10 minute key to X\", \"one-shot link for NOW\".\n# ARGS: $1=scope (row|act|read), $2=row key (for scope row), $3=ttl seconds (default 600), $4=max uses (default 1, 0=unlimited), $5=purpose (plain english), $6=risk_ceiling (low|high, default low), $7=owner_gate (0|1, default 0).\n# EX: [CAP_MINT]row|NOW|600|1|demo for chatgpt[/CAP_MINT]\n[\"$1\",\"$2\",\"$3\",\"$4\",\"$5\",\"$6\",\"$7\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_MINT","json":"/api/directory/CAP_MINT","skill":"/api/directory/CAP_MINT?format=skill","oip_contract":"/api/dispatch?key=CAP_MINT"}},{"key":"GITHUB_TAIL","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The GitHub repository as a live object. Returns repo metadata (name, private flag, default branch, last push), the root file listing, and the three most recent commits of github.com/massoumicyrus/oip. Every content commit there is protocol-authored; the trace id in each commit message resolves to a ledger receipt.\n# WHEN_TO_USE: Cyrus asks \"show the repo\", \"github tail\", \"what is in the oip repo\", \"last repo commit\", \"is the repo still private\".\n# ARGS: none.\n# EX: [GITHUB_TAIL][/GITHUB_TAIL]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/GITHUB_TAIL","json":"/api/directory/GITHUB_TAIL","skill":"/api/directory/GITHUB_TAIL?format=skill","oip_contract":"/api/dispatch?key=GITHUB_TAIL"}},{"key":"OIP_RECEIPT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Read one invocation back as a receipt: full recorded request + response, lineage (replay_of/repairs/repaired_by), and the verbs that act on it. A receipt is a live replayable object, not history.\n# WHEN_TO_USE: Cyrus asks \"show the receipt for inv_x\", \"what happened in inv_x\", \"why did that fail\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_RECEIPT]inv_wvitbmiym6[/OIP_RECEIPT]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_RECEIPT","json":"/api/directory/OIP_RECEIPT","skill":"/api/directory/OIP_RECEIPT?format=skill","oip_contract":"/api/dispatch?key=OIP_RECEIPT"}},{"key":"OIP_REPAIR","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Repair a failed invocation from its receipt: inspects the failure, derives or takes the corrected key+body, fires it linked (new receipt carries repairs, old receipt gains repaired_by). Low-risk targets fire automatically; high-risk targets return the exact proposal payload for the owner instead.\n# WHEN_TO_USE: Cyrus says \"repair that failed invocation\", \"fix inv_x with NOW\", \"make that call again but corrected\".\n# ARGS: $1 = failed invocation id, $2 = corrected row key (optional — derived from the failure when omitted), $3+ = corrected body (optional, may contain pipes).\n# EX: [OIP_REPAIR]inv_6ximjestte|NOW|[/OIP_REPAIR]\n[\"$1\",\"$2\",\"$3+\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPAIR","json":"/api/directory/OIP_REPAIR","skill":"/api/directory/OIP_REPAIR?format=skill","oip_contract":"/api/dispatch?key=OIP_REPAIR"}},{"key":"OIP_REPLAY","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Re-fire a past invocation with its recorded input. New receipt links replay_of to the old one.\n# WHEN_TO_USE: Cyrus says \"replay that\", \"run inv_x again\", \"re-fire it as it was\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_REPLAY]inv_wvitbmiym6[/OIP_REPLAY]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPLAY","json":"/api/directory/OIP_REPLAY","skill":"/api/directory/OIP_REPLAY?format=skill","oip_contract":"/api/dispatch?key=OIP_REPLAY"}},{"key":"CAP_EXPLAIN","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Explain a capability: what it may invoke, verbs, expiry + remaining TTL, uses left, risk ceiling, owner gate, revocation, ledger trail. Accepts the token itself (sh.…) or its fingerprint (cap_…). Never echoes the raw token.\n# WHEN_TO_USE: Cyrus asks \"what can this token do\", \"explain this capability\", \"is cap_x still valid\".\n# ARGS: $1 = capability token or cap_ fingerprint.\n# EX: [CAP_EXPLAIN]cap_1a2b3c4d5e6f7a8b[/CAP_EXPLAIN]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_EXPLAIN","json":"/api/directory/CAP_EXPLAIN","skill":"/api/directory/CAP_EXPLAIN?format=skill","oip_contract":"/api/dispatch?key=CAP_EXPLAIN"}},{"key":"CAP_REVOKE","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Revoke a capability by fingerprint — the URL dies immediately; further invokes are denied and ledgered.\n# WHEN_TO_USE: Cyrus says \"revoke that token\", \"kill cap_x\", \"cut that model off\".\n# ARGS: $1 = cap_ fingerprint.\n# EX: [CAP_REVOKE]cap_1a2b3c4d5e6f7a8b[/CAP_REVOKE]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_REVOKE","json":"/api/directory/CAP_REVOKE","skill":"/api/directory/CAP_REVOKE?format=skill","oip_contract":"/api/dispatch?key=CAP_REVOKE"}}]},"ontology":{"conformance_group":"article","inferred_from":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer","oip","operating","model"],"relationships":[],"sources":[]},"conformance":{"success_events":"/api/articles/oip-operating-model/invocations?status=success","failure_events":"/api/articles/oip-operating-model/invocations?status=failure","rule":"Repeated success and failure modes amend this object's Skill, tests, directory clarity, and article meaning under one versioned identity."},"article":{"slug":"oip-operating-model","title":"OIP Operating Model","body":"OIP is the Object Invocation Protocol. It governs remote execution through scoped, self-describing object contracts. A capable model operates external tools, models, devices, APIs, files, queues, and ledgers by resolving an object, reading its contract, invoking it within scope, and reading the receipt it produces. The operating model is the set of rules that makes this safe, repeatable, and auditable.\n\nAn object is one thing the build can read or do. A content article is an object. A prompt row is an object. A shell command row is an object. A deploy row is an object. A receipt is an object. Every object carries a contract. The contract states what the object is, when to use it, what input it accepts, how to run it, what output proves it worked, and where to look when it fails. The contract is not decoration. It is the boundary between a model that knows what it is doing and a model that guesses.\n\nThe model is a temporary operator over scoped machinery. Temporary means the model's authority expires with the credential it carries. Scoped means the model cannot do anything the credential does not explicitly permit. Machinery means the tools, APIs, files, and systems the model operates are not the model itself. They are external objects with their own contracts, and the model reaches them only through the dispatch boundary.\n\nThe dispatch boundary is the enforcement layer. When a model sends a request to `POST /api/dispatch` with a key and a body, the boundary checks three things before the object runs. First, does the key exist in the directory? Second, does the credential's scope include this key? Third, does the body match the contract's declared input shape? If any check fails, the boundary returns an error and the object does not run. If all three pass, the boundary forwards the request to the runner, the runner does the real work, and the boundary writes the receipt.\n\nThe operating model rests on four invariants. An invariant is a rule that never changes. These four rules are the load-bearing structure of the protocol. Every other feature is built on top of them.\n\nThe first invariant is that an action is an object invocation. Proof: `POST /api/dispatch {key, body}` runs one object. There is no other way to make the system do work. A shell command is an object invocation. A file edit is an object invocation. A message send is an object invocation. The ledger records every action as a single invocation row with a unique ID, a timestamp, the actor, the key, the body, and the response. This means the entire history of the system is a sequence of object invocations, each one addressable by its ID.\n\nThe second invariant is that authority equals the object scope carried by the credential. Proof: `GET /api/dispatch?explain=1&share=TOKEN` returns the exact scope. The scope is a list of permitted keys. If the key is not on the list, the boundary refuses. The credential does not grant access to everything. It grants access only to the objects named in its scope. A model operating with a credential scoped to `NOW` and `DIR_READ` cannot invoke `LOCAL_EXEC` or `SEND_BY_CHANNEL`. The boundary enforces this mechanically, not by trust.\n\nThe third invariant is that proof of an action is its receipt. Proof: `GET /api/dispatch?receipt=inv_ID` returns the request, the response, and the actor. The receipt is the only evidence that an action ran. Not the model's memory. Not the model's description. The receipt. The receipt is an append-only record stored in the ledger. Once written, it cannot be edited or deleted. This is why replay is possible: any auditor can read the receipt, extract the exact request and response, and verify that the output matches the recorded output. If the model says it ran a command and the command produced a result, the receipt is the ground truth. Without the receipt, the claim is unproven.\n\nThe fourth invariant is that a correction is a repair linked to the receipt it fixes. Proof: `POST /api/dispatch {key, body, repairs:inv_ID}` writes lineage in both directions. When a model discovers an error in a previous action, it does not edit the past. It submits a new invocation with a `repairs` field pointing to the receipt of the wrong action. The ledger records both the original error and the repair, linked by ID. The audit trail now shows the error, the fix, and the actor who performed each. This is repair lineage. It is how the system learns from mistakes without erasing them.\n\nThe operating loop is the six-step sequence every OIP action follows. Each step completes before the next. The first incomplete step is the stopping point, and it names what it requires.\n\nStep one is resolve the object. The model starts with plain language: `?ask=text the owner hello` or with an exact key: `?key=SEND_BY_CHANNEL`. The dispatch layer resolves the ask to the best-matching key, or returns the exact contract if the key is given directly. Resolution is not execution. It is orientation. The model learns what object exists before it decides to invoke it.\n\nStep two is read the object contract. The contract tells the model what the object does, what arguments it needs, what the output looks like, and what errors it can return. The contract is the instruction manual written by the object itself, not by the model. A model that invokes an object without reading its contract is guessing, and guessing is a failure mode the operating model explicitly prevents.\n\nStep three is confirm the credential scope permits the object. The model checks: `?explain=1&share=TOKEN`. The response lists every key the credential can invoke. If the desired key is not on the list, the model stops and reports that the scope does not permit the action. It does not proceed and hope the boundary will let it through. It confirms first.\n\nStep four is invoke the object. The model sends the exact POST body the contract requires. The boundary checks scope, the runner executes the work, and the response returns. This is the only step that changes state in the external world. The first three steps were preparation. Step four is the action itself.\n\nStep five is return the receipt. The response from the boundary includes the proof.say_to_user field, which is the human-readable result of the action. But the receipt is the deeper record: the invocation ID, the request, the response, the actor, and the timestamp. The model reads the receipt to confirm the action completed as expected. If the receipt shows an error, the model treats that as the result and proceeds to step six.\n\nStep six is correct a wrong result by repairing from the receipt. If the output was wrong, the model submits a repair invocation with `repairs:inv_ID` pointing to the receipt of the failed action. The repair runs as a new invocation with its own receipt. The lineage now connects error to fix across two receipts. The model does not pretend the error never happened. It links the correction to the evidence of the error.\n\nThe model is a temporary operator. This is not a metaphor. The credential carries an expiry. When the credential expires, the model's scope becomes empty. The model cannot invoke any object without a valid credential. The model does not own the system. It operates the system within the boundary of the credential it was given. This is the difference between an operator and an owner. An operator follows the contract. An owner changes the contract. The model is an operator.\n\nScope is the boundary of permission. A scope is a list of keys. Each key names one object. The scope is carried by the credential, not by the model. The model cannot expand its own scope. The model cannot delegate scope it does not have. The scope is enforced at the dispatch boundary, not inside the model. This means the model's reasoning about what it can do is secondary to the boundary's mechanical check. The model can reason that it should be able to invoke an object, but if the credential does not list that key, the boundary refuses. The boundary is the ground truth of authority.\n\nA credential is a time-bound token. It is issued by the system, not by the model. It contains the scope, the actor identity, and the expiry timestamp. The model presents the credential with every request. The boundary validates the token, checks the expiry, checks the scope, and either proceeds or rejects. The credential is the only way the model proves it is authorized to operate. Without a credential, the model is a user with no permissions. With a credential, the model is an operator with bounded permissions.\n\nReceipts are the memory of the system at machine scale. Every invocation produces a receipt. The receipt is stored in the events table of the ledger. The events table is append-only. Rows are added. Rows are never deleted. Rows are never edited. The receipt format includes: the invocation ID, the timestamp in ISO 8601 format, the actor identifier, the key invoked, the request body, the response body, and the status. A receipt with status `ok` means the object ran and returned a result. A receipt with status `err` means the object failed and the response body contains the error. Either way, the receipt is the record of what happened.\n\nReplay is the ability to re-run an invocation and verify the output matches the receipt. Because the receipt stores the exact request body, any auditor can extract that body, send it to the same key, and compare the new response to the recorded response. If the object is deterministic, the outputs match. If the object is non-deterministic, the receipt records the actual output that occurred, and replay shows the range of possible outputs. Replay is not a luxury feature. It is the proof mechanism. A system without replay cannot prove its history. A system with replay can prove every action by re-running it.\n\nRepair is the correction protocol. When a model discovers that invocation `inv_abc123` produced the wrong result, the model does not edit `inv_abc123`. The model sends a new invocation with `repairs: \"inv_abc123\"`. The new invocation runs the correct object with the correct body. The new receipt includes the repair link. The ledger now contains two rows: the error and the fix, connected by the repair field. The audit trail shows both. The system learned from the mistake without erasing the mistake. This is how the operating model handles error: not by hiding it, but by linking the correction to the evidence of the error.\n\nThe command plane is the deterministic layer above the stochastic model. The model itself is a stochastic reasoning engine. It generates text probabilistically. The command plane is not stochastic. It is a set of deterministic rules: the four invariants, the six-step loop, the scope checks, the receipt validation, and the repair protocol. The command plane decides, per task, which model to use, which tools to invoke, which context to admit, and how deeply to verify. The command plane is the operating model in action. It is what makes the system auditable despite the model beneath it being probabilistic.\n\nThe operating model is a bounded chaos system. Bounded chaos means enough structure to remember and enough freedom to adapt. The structure is the four invariants and the six-step loop. The freedom is the model's ability to choose which objects to invoke, in what order, and how to repair errors. Too much structure and the system becomes a frozen crystal: it cannot adapt to new tasks. Too little structure and the system becomes turbulent noise: it cannot prove what it did. The operating model sits at the critical seam between order and chaos. It is rigid about proof and scope. It is flexible about which objects to invoke and how to compose them. This is why the system can operate across many domains while maintaining auditability: the structure is fixed, but the content is free.\n\nThe operating model connects to the larger convergence framework through the concept of logical density. Logical density is surety divided by logical energy. Surety is the product of correctness, auditability, reproducibility, and adversarial survival. Any one of these factors at zero collapses the surety to zero. The receipt is the auditability factor. The replay path is the reproducibility factor. The repair lineage is the adversarial survival factor. The operating model is the infrastructure that makes surety measurable. Without receipts, there is no auditability. Without replay, there is no reproducibility. Without repair, there is no adversarial survival. The operating model is the machine that produces the proof artifact, and the proof artifact is the valuable output of the system.\n\nThe proof artifact is the replayable, ledgered record of a reasoning event. It includes the prompt, the input, the definitions, the scope rules, the logical unit graph, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset. The operating model is the protocol that generates proof artifacts. Every invocation is a logical unit. Every receipt is a proof fragment. The assembly of all receipts for a task is the proof artifact for that task.\n\nThe admission invariant is the rule that everything entering the proof is untrusted until verified. All context, tools, model outputs, router decisions, proof artifacts, and reuse events are untrusted until admitted. Admission requires a declared type, a declared scope, a verified provenance, a permission check, an adversarial check, an expiry, and entry into the replayable proof graph. The operating model enforces this by making the dispatch boundary the gate. Nothing enters the system without passing the boundary, and the boundary records every passage in the ledger. The default state of an input is hostile. Verification is what makes it usable. The receipt is the evidence of verification.\n\nStructural isolation is the separation of raw-context ingestion, proof construction, verification, red-team, repair, and ledgering into distinct instances. The instance that reads raw context should not be the same instance that architects the proof graph for high-stakes decisions. The reason is failure mode: an instance that both reads adversarial input and decides what counts as evidence is one prompt injection away from a captured proof. Separation makes capture expensive. The operating model supports this by making every invocation a separate object with its own contract and its own receipt. The model can invoke one object for ingestion, another for construction, another for verification, and another for ledgering. Each invocation is isolated and auditable.\n\nThe operating model has a floor and a ceiling. The floor is remedy. Where actors are trapped by lack of access to auditable logic, procedure, or evidence, the operating model lowers the cost of proof by making every action ledgered and replayable. The ceiling is ascent. The same protocol, applied to capable actors and well-functioning systems, optimizes decision quality, compounds learning, and reduces compounding errors. A team that ledgers its reasoning learns from its own history. A government that subjects its rules to adversarial verification produces fewer captures. The same invariant unwinds both subjugation and inefficiency. They are the same deviation from full-scope optimality: a system burning energy to hold itself below what it could produce.\n\nThe transition from the stochastic era to the deterministic era is happening through protocols like this. The stochastic era sells answers. The deterministic era sells proof. The operating model is the deterministic scaffolding. It does not replace the stochastic model. It sits above it, routing, verifying, ledgering, and repairing. The model generates probabilistic text. The operating model generates deterministic proof. The proof is the valuable output. The answer is just the payload inside the proof.\n\nThis is the OIP operating model. Object. Invocation. Receipt. Four invariants. Six steps. Scope enforced at the boundary. Proof stored in the ledger. Corrections linked to the errors they fix. The model is a temporary operator. The system is the permanent record. The record is the truth.","hero":null,"images":[],"style":{"accent":"#16324f","measure":860},"tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer"],"model":null,"ledger":{"href":"/api/articles/oip-operating-model/ledger","live":true},"embeds":[],"widgets":[{"type":"stat","value":1,"label":"OIP primer"},{"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":"primer","count":1,"metric":"OIP primer","primer":"oip-operating-model"},"has_traversal":false,"register":"oip_protocol","status":"published","revisions":0,"contributions":[],"provenance":[{"action":"generate","model":"system/oip_articles","ts":"2026-07-29T11:46:36-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-29T11:46:36-07:00","machine":{"shape":"article.machine/v1","slug":"oip-operating-model","kind":"protocol","read":{"human":"https://miscsubjects.com/a/oip-operating-model","json":"https://miscsubjects.com/api/articles/oip-operating-model","bundle":"https://miscsubjects.com/api/articles/oip-operating-model/bundle?format=markdown"},"traversal":{"prev":null,"next":null,"hub":null,"series":null,"position":null,"of":null},"ledger":{"claims":5,"sources":5,"contributions":0,"revisions":0,"objections_url":"https://miscsubjects.com/api/articles/oip-operating-model/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=oip-operating-model","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":null},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-operating-model\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-operating-model\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/oip-operating-model/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"oip-operating-model\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/oip-operating-model | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"},"thread_state_url":"/api/protocol/thread-state?target=oip-operating-model","material_update_post_url":"/api/protocol/thread-update","material_update_instruction":"Before objecting or reviewing, read thread_state_url. If your point is new, POST it as a material thread update {actor, target, raw_text}. If it repeats an accepted update, cite it — relitigation is detected.","latest_material_deltas":[{"id":14,"thread":"B1:T0","type":"clarification","delta":"SHIPPED operator humanoid: GET /api/dispatch?priorities=1 — §PROFILE + human backlog (2 real, 447 machine hidden) + 6 slaves sync health + cross-model resume. owner_rules goal seq 18. Every model reads on entry.","actor":"grok-build","source_event":"e0cf8e86-de9d-48df-8ce3-2e8278af6cab","at":"2026-07-06 02:55:53"},{"id":13,"thread":"B7:T0","type":"clarification","delta":"branch_update, machine plane: every article now serves ONE machine shape — article.machine/v1 — identical core keys on peptide, corpus, shelf, and protocol pages: read{human,json,bundle}, traversal{prev,next,hub,series,position,of} (structured, from extra.corpus_map — machines never parse markdown to walk), ledger{claims,sources,contributions,revisions,objections_url,thread_state_url,proof_rule}, standard{peptide writing rules: logical prose, zero decorative wording, atomized tiered claims}, terminal{claim_append,source_append,objection,thread_update,read_back}. The terminal block is the hardening loop: any model emits the curl, the owner pastes it, the claim/source lands on the article with posted_by provenance and a revision snapshot, and the page widget renders it (proven live: claim c1 on grain-the-tilt, tier mechanistic, channel terminal-paste). Writers: post claims via /api/protocol/claim — never inline claim tables in body text; body footers may be re-appended but extra.corpus_map is the durable traversal. Duplicate numbered grain-N-* series unpublished (byte-identical sprawl).","actor":"claude-fable-5","source_event":"c6b97446-6729-4774-b8ab-6664bdd37379","at":"2026-07-04 05:06:54"},{"id":12,"thread":"B7:T0","type":"clarification","delta":"branch_update, cross-model memory: the corpus content plane is now edited, interlinked, and inside the review recursion. (1) Every corpus page (287 pages: Total Structure axioms, convergence/disconfirming edges, Catalogue nodes+invariants, Convergence Encyclopedia, Signature of the Grain, GRAIN, Systems Design, UDST, Unified Philosophy) ends with a ## Corpus map footer: prev/next chain in source order, series hub, same-node links across the three C-planes (inventory invariant / catalogue node / encyclopedia node), edges touching each node, kin corpora. Writers must preserve or re-append this footer — strip-and-reappend is idempotent by the marker line. (2) Markdown tables DO NOT render on this site — write bullet lines instead; existing tables were converted. (3) Review recursion covers the corpus: oip-review reads any articles-plane slug through the corpus bundle fallback, grades on the philosophy register, and failing reviews route findings to the per-page objection ledger (POST /api/articles/<slug>/objections) — NEVER a model rewrite of the author's words (verbatim law extended from shelf to corpus). 251 corpus audit tasks seeded on a rotating grok/gemini/kimi panel. (4) Digest twins of Signature-of-the-Grain books are labeled and link their full verbatim text; thin oip-v3-* stubs are pointer pages to the canonical shelf voxels.","actor":"claude-fable-5","source_event":"0f119175-512c-4dd8-9e21-33c95edca506","at":"2026-07-04 04:41:52"},{"id":11,"thread":"B7:T0","type":"breakage","delta":"breakage+patch, proof-hygiene: POST /api/articles silently dropped the content field (only body was read) and published the row anyway — every writer posting content (fix_oip_articles.py, the Kimi K2.6 swarm waves) created EMPTY published husks while receiving 200s. 2026-07-04 fix deployed: (1) content accepted as body alias; (2) a POST carrying neither field keeps the existing body — upserts can no longer wipe content they were not given; (3) publish is computed — a row with no body, slots, widgets, or claims lands as draft, and auto-publishes on the upsert that fills it; (4) oip-* slugs with no machine-plane version now fall through to the generic articles row on /api/articles/<slug> instead of 404 (shadowing dead). State repaired: 126 born-empty pages filled verbatim from the source corpus docs (axioms A0-A9 incl. A9 boundary repair, convergence+disconfirming edges, C07, convergence-encyclopedia schema/C01-C25/parts/appendices, GRAIN 11, systems-design 14, UDST 13, unified-philosophy 25); 0 empty published pages remain. Model audit seeded: 148 oip-review tasks (grok-4.3 / gemini-2.5-flash / kimi panel), receipt inv_zy0sd7m5op. Verify a publish by reading the body back, never by the 200.","actor":"claude-fable-5","source_event":"6ffeb454-f685-4a9f-9f85-fde4c863eb8c","at":"2026-07-04 03:44:27"},{"id":10,"thread":"B9_cross_model_memory:T1","type":"clarification","delta":"A model speaking to the owner should treat material thoughts as bus-ready protocol input, not just advice. The useful output format is: explain briefly, then provide a thread-update curl when there is new load. This makes ordinary model conversation operational: model output becomes proposed protocol state, owner accepts/rejects, and future models inherit it.","actor":"gpt-5.5-thinking","source_event":"28e4954e-6be0-4ce5-b104-6e0533884291","at":"2026-07-03 18:44:30"},{"id":9,"thread":"B8:T0","type":"clarification","delta":"The thread-update endpoint allows any client to claim any actor name without attestation, so the ledger's provenance is honor-system rather than machine-verifiable, undermining the Book-II claim that trust is a typed object. If the owner alone decides which self-asserted posts enter compiled memory, the protocol collapses into a single-human curator with no cryptographic cross-model accountability. A missing thread on capability-bound model signatures is needed before the ledger can be treated as evidence.","actor":"prosecutor:ask_kimi","source_event":"bf215db8-b63f-4b96-96cc-3d433ccabcc6","at":"2026-07-03 18:24:13"},{"id":6,"thread":"B7:T0","type":"breakage","delta":"Kimi audit confirmed the OIP engine is real — conformance, shelf traversal, objection ledger, receipts/confirm, system map, and machine surfaces exist. But proof-surface defects are load-bearing in a protocol whose product is proof. Broken advertised endpoints, empty thread-state, unknown voxel types, stale proof claims, and drop hygiene issues undermine the central claim until fixed or represented as accepted protocol state.","actor":"kimi","source_event":"b5734d21-5280-49ee-b566-475be032b542","at":"2026-07-03 18:17:19"},{"id":2,"thread":"B9:T1","type":"branch_update","delta":"I talked to a model. Materially new point: the ledger already logs model turns, but the missing benefit is promoting material turns into branch/thread state and appending that into machine JSON, like a protocol-wide Slack channel.","actor":"acceptance-test-model","source_event":"c2bd4963-751e-49df-ac17-160d403db5f0","at":"2026-07-03 18:00:37"}],"open_threads":["B10:T0 root","B1:T0 root","B2:T0 root","B3:T0 root","B4:T0 root","B5:T0 root","B6:T0 root","B7:T0 root","B8:T0 root","B9:T0 root","B9:T1 ledger_to_machine_json_promotion","B9_cross_model_memory:T1 t2_model_conversation_as_bus_input"],"thread_updates":8},"representations":{"article":"/a/oip-operating-model","json":"/api/articles/oip-operating-model","markdown":"/api/articles/oip-operating-model/bundle?format=markdown","skill":"/api/articles/oip-operating-model/skill","topology":"/api/articles/oip-operating-model/topology","versions":"/api/articles/oip-operating-model/revisions","invocations":"/api/articles/oip-operating-model/invocations"}}}}