Where OIP Ideas Come From - and What to Build Next

What this page is

A plain-English summary of a long research paper (July 2026) that traced where OIP's ideas came from and what to build next. Nothing here needs prior context. OIP (Object Invocation Protocol) is this site's rule system: every tool has a name, every run leaves a receipt, every token carries limits.

The one missing piece

For sixty years, people kept building the right structures and watching them fail for the same reason: the reader was missing.

• 2000: Roy Fielding said every web response should carry links telling you what you can do next. Failed - programs could follow links but could not understand them.
• 2006: Tim Berners-Lee said every fact should get an address so machines could walk from fact to fact. Failed - no machine could understand what it was walking through.
• 1966: Jack Dennis said permission should live in an unforgeable token you hold, not in a list someone keeps. Stayed in research labs - no software could manage tokens carefully enough.

All three needed a reader that understands what it reads. Language models are that reader. That is OIP's bet: the runways were built decades ago; the plane just landed.

The six things OIP combines

Each existed alone somewhere. No system combined all six before:

1. Every tool describes itself - what it does, what it needs, what it risks, how to check it ran.
2. One door - every tool runs through a single address, so every check happens in one place.
3. Tokens with limits - what it may run, when it dies, how many uses, what sensitivity. A handed-down token can only shrink, and revoking a parent kills every child.
4. Receipts - every run leaves a permanent record that proves what was asked and what came back. Failures are never erased; a fix links to the failure both ways.
5. The model as the operator - the reader that finally understands the contracts.
6. Self-description - the system explains itself to whoever asks, and the published rule suite now defines 25 checks.

The people who had the pieces first

• Luca Pacioli, 1494: books must balance - every transaction leaves paired, checkable entries. The receipt idea.
• Vannevar Bush, 1945: save the path you took so someone else can walk it again. The saved-sequence (trail) idea.
• Jack Dennis, 1966: holding the token IS the permission.
• Norman Hardy, 1988: a program tricked into misusing its own authority is the root security problem. The cure: authority travels with the request. This is why prompt injection does not scare a token system.
• Mark Miller, 1990s-2000s: hand-offs must only shrink, and revoking a parent must kill everything under it.
• Alan Kay, 1972: the message, not the machine, is the unit. One door for everything is his idea at web scale.
• Roy Fielding, 2000: responses should carry your next moves. OIP responses now list only the moves your token can actually take.
• Ted Nelson, 1965: links should run both ways and nothing should be erased. Repair links both ways.
• Leslie Lamport, 1978: distributed events need a recorded order. Replay depends on it.
• Terry Winograd and Fernando Flores, 1986: a request is not done when the work runs - it is done when the asker says so.

What the paper recommended - and what shipped

OIP 1.0 now ships the four concrete recommendations from the paper:

1. Every receipt carries SHA-256 fingerprints of the exact input, exact output, and tool contract.
2. When output contains a durable URL, file path, article path, or R2 key, the receipt lists it as a structured artifact link.
3. Work moves through asked, promised, done, and closed. Only the promisor may mark it done; only the original asker may close it.
4. Every token limited to one tool is pinned to that tool's exact contract fingerprint. If the contract changes, the token fails before the tool runs.

These were proved through real dispatch calls after deployment: fingerprinted receipt and artifact-bearing receipt. A contract-drift probe succeeded before the contract fingerprint changed and then failed closed with HTTP 409. A two-token work probe moved asked → promised → done → closed and refused a close attempt from anyone except the asker.

The two larger research problems remain open: deciding when a linked object deserves trust, and representing long-running work that spans many calls, people, and days.

How this could be proven wrong

The design publishes its own kill conditions: if receipts can be faked cheaply, if failure-fix links break down at scale, or if the one door becomes a choke point, the architecture fails. The live rule check runs at /api/dispatch?conformance=1 - open it and read pass or fail per rule.

Read the full lineage map

The sourced, longer comparison is OIP's intellectual lineage - and what is actually worth carrying forward.