OIP Operating Model
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.
An 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.
The 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.
The 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.
The 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.
The 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.
The 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.
The 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.
The 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.
The 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
The 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.
Scope 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.
A 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.
Receipts 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.
Replay 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.
Repair 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.
The 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.
The 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.
The 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.
The 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.
The 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.
Structural 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.
The 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.
The 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.
This 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.