OIP's intellectual lineage — and what is actually worth carrying forward

The five lineages that matter

The missing-reader hypothesis, stated narrowly

Fielding's hypermedia constraint and Berners-Lee's linked-data principles put navigation and meaning in-band. Traditional clients could parse those controls only when programmers had already encoded their semantics. A language model can interpret unfamiliar descriptions at runtime, so it reduces that prior-coordination cost.

That does not make raw links safe tools. Interpretation is probabilistic; authority and side effects cannot be inferred safely from page prose. OIP's contribution is the boundary around the reader: the model may interpret a contract, but the server still enforces scope, risk, use count, ancestry, fixed arguments, and now payload size. The link is discoverable; the capability record is authoritative.

What the paper changed in the running protocol

The strongest unimplemented recommendation came from capability operating systems, especially quota-bounded authority: permission should constrain not only which operation can run and how many times, but also the resources presented to it.

OIP v0.9 therefore adds an enforceable per-invocation byte ceiling:

• an owner can mint with max_body_bytes=N;
• oversized input fails with HTTP 413 before the runner fires;
• a delegated child inherits the parent's ceiling unless it requests a smaller one;
• a child cannot raise the ceiling;
• explain exposes the server-enforced limit;
• C21 makes resource attenuation a normative protocol clause.

Live proof: the accepted 8-byte invocation receipt. The same credential rejected nine bytes and rejected a child ceiling of nine while accepting a child ceiling of four.

This is the useful synthesis of Genode-style quotas, Saltzer and Schroeder's least privilege and complete mediation, and Miller's attenuation rule. It is not a metaphor; it is a failing gate in the dispatch path.

What was already present before this review

Several of the paper's highest-priority recommendations were already operational in OIP v0.8.1:

• Miller-style attenuation: holders can derive only equal-or-narrower children;
• quantitative conservation: child use budgets are reserved from the parent so sibling delegation cannot multiply authority;
• Hardy-style revocation membrane: revoking any ancestor kills the descendant tree, and every invocation rechecks all ancestors;
• Lamport/PROV-style lineage: receipts separate verified authority from caller-attested intent and preserve acted-on-behalf-of chains;
• composite safety: saved trails re-authorize every step under the current credential and preserve replay_of lineage;
• injection boundary: retrieved messages, pages, and ledger text are data, never executable instructions; capability permission is not caller intent;
• neutral token drops: public documentation first, declarative capability record, no model-addressed behavioral script.

What should not be adopted merely because it appears in the paper

A named predecessor is not an implementation plan. Replacing D1 with an "immutable database," adding blockchain consensus, adopting CapTP as the wire format, or federating over ActivityPub would add dependencies before a demonstrated failure requires them. Likewise, input/output hashes are integrity identifiers, not by themselves cryptographic proof that an external action occurred. OIP should use the smallest mechanism that closes a measured gap.

The paper also contains stale snapshots and overclaims: old capability counts, earlier conformance totals, unresolved footnote markers, and assertions that append-only storage or hashing automatically makes receipts tamper-proof. Those claims are not imported here. The current public contract is OIP v0.9 with 21 clauses; the live response, not a frozen essay, is authoritative.

The next research queue

The remaining ideas are useful only in this order:

1. Formalize capability state transitions. Model mint, attenuate, reserve, consume, revoke, expire, replay, and repair as a small state machine. This is a better first formal-methods target than attempting to prove the whole build.
2. Portable contract projections. Generate OpenAPI and MCP views from the same directory object without creating a second source of truth. Success means round-trip field preservation, not merely syntactically valid exports.
3. Externally verifiable receipts. Add signatures or a transparency-log commitment only when a verifier outside the operator's trust boundary needs to validate a receipt. Until then, describe receipts as server-authoritative evidence.
4. Stateful sessions as receipted objects. If long-running work needs streams or subscriptions, make session transitions invocable and receipted rather than adding hidden ambient state.
5. Counter-lineage. Search for systems that rejected these patterns and succeeded. A convergence map becomes evidence only when it includes disconfirming cases.

The synthesis

OIP sits at a real intersection: REST and Linked Data contribute addressability; object and actor systems contribute bounded message-passing; capability research contributes least authority; distributed-systems work contributes causal history; cybernetics contributes visible correction loops. The LLM is the flexible reader that makes in-band contracts newly practical. OIP's job is to keep that reader inside deterministic boundaries.

The durable design rule is simple: the model interprets; the protocol authorizes; the receipt records.