## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `article_bundle` — **LLM article bundle**
Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution.
- **article slug:** `object-invocation-protocol-intellectual-lineage`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Reference block for Grok/GPT/Gemini. Section §SELF explains the system.
- **read:** https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/bundle?format=markdown

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/prompts
- **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node.
- **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/voxels
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

---

# miscsubjects article bundle

> Reference bundle for Grok, GPT, Gemini, or a human reader. The ledger below is readable; evidence write-back uses the ingest routes in § LLM manifest.

## Article
- **slug:** `object-invocation-protocol-intellectual-lineage`
- **title:** OIP's intellectual lineage — and what is actually worth carrying forward
- **url:** https://miscsubjects.com/a/object-invocation-protocol-intellectual-lineage
- **register:** technical
- **updated:** 2026-07-15T03:55:40.570Z
- **tags:** oip, object-invocation-protocol, protocol-history, capability-security, hateoas, linked-data, formal-methods

## Body

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

A long convergence paper was submitted against OIP. Its useful contribution is not the claim that earlier thinkers "invented OIP." They did not. The useful contribution is a map of recurring design pressures: address work without prior coordination, move authority without ambient privilege, preserve causal history, make interfaces explain themselves, and let independent parts compose safely.

This article separates **structural antecedent**, **operational adoption**, and **open research**. Similarity is not identity. A historical idea counts here only when it sharpens an OIP invariant or produces a testable protocol change.

## The five lineages that matter

| lineage | thinkers and systems | recurring idea | OIP expression |
|---|---|---|---|
| Addressability and discovery | Ted Nelson; Roy Fielding; Tim Berners-Lee | stable addresses and in-band links let a reader discover the next move | public object URLs, three views, machine-readable affordances |
| Messages and objects | Kristen Nygaard and Ole-Johan Dahl; Alan Kay; Carl Hewitt; Barbara Liskov; Robin Milner | computation is interaction among bounded objects with explicit interfaces | one dispatch door, directory objects, typed contracts, runner boundaries |
| Authority as an object | Jack Dennis; Norm Hardy; Mark Miller; Jerome Saltzer and Michael Schroeder | possession of a narrow reference conveys authority; authority can be attenuated and revoked | scoped capability records, parent-child delegation, risk ceilings, use budgets, revocation membrane |
| Causality and proof | Leslie Lamport; Pat Helland; event-sourcing systems; W3C PROV | distributed work needs causal ordering, durable evidence, and explicit correction | invocation receipts, replay_of, repairs/repaired_by, authority-preserving trails |
| Self-description and recursion | Douglas Engelbart; Norbert Wiener; Ross Ashby; Gordon Pask; Heinz von Foerster | a system improves when its operation and correction loop are visible to itself | self-describing payloads, live contracts, conformance clauses, revision and objection surfaces |

## 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](https://miscsubjects.com/api/dispatch?confirm=inv_sooi304em9). 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.**

## Claims (11)

- **c_slot_limits** [system w=?] Structural resemblance is not historical derivation. The submitted paper contained stale counts, unresolved footnote markers, and cryptographic overclaims, so those parts were not imported as facts.
  - who_claims: codex protocol review
  - slot: limitations
- **c_limits_1** [analysis w=?] Hashes are integrity identifiers but do not alone prove that an external action occurred.
  - who_claims: codex protocol review
- **c_lineage_1** [synthesis w=?] OIP combines addressable hypermedia, bounded object messaging, capability authority, causal receipts, and recursive self-description.
  - who_claims: codex protocol review
  - sources: fielding2000, linkeddata2006, miller2006, saltzer1975, lamport1978
- **c_reader_1** [inference w=?] Language models reduce the prior-coordination cost of interpreting unfamiliar in-band affordances, but server-side authority enforcement remains necessary.
  - who_claims: codex protocol review
  - sources: fielding2000, linkeddata2006
- **c_rule_1** [synthesis w=?] The model interprets; the protocol authorizes; the receipt records.
  - who_claims: codex protocol review
  - sources: oipproofv09
- **c_slot_disclaimer** [system w=?] This is an architectural research note. Live protocol responses and receipts supersede frozen counts or implementation claims in the essay.
  - who_claims: codex protocol review
  - slot: disclaimer
  - sources: oipproofv09
- **c_slot_known** [primary w=?] OIP v0.9 now enforces a per-invocation byte ceiling and prevents delegated child tokens from raising it.
  - who_claims: codex protocol review
  - slot: what_is_known
  - sources: oipproofv09
- **c_slot_unknown** [inference w=?] It remains unproved whether the convergence map is exhaustive, whether portable contract projections round-trip without loss, or whether externally verifiable receipts are needed for this deployment.
  - who_claims: codex protocol review
  - slot: what_is_unknown
- **c_slot_what** [system w=?] This article is a selective map of historical ideas that sharpen a testable OIP invariant; it is not a claim that any predecessor invented OIP.
  - who_claims: codex protocol review
  - slot: what_it_is
  - sources: fielding2000, linkeddata2006, miller2006, saltzer1975, lamport1978
- **c_slot_who** [system w=?] The historical descriptions come from the cited primary sources. The cross-system mapping and adoption decisions are the Codex protocol review requested by the owner.
  - who_claims: codex protocol review
  - slot: who_claims_what
  - sources: fielding2000, linkeddata2006, miller2006, saltzer1975, lamport1978
- **c_v09_1** [primary w=?] OIP v0.9 enforces max_body_bytes before runner execution and prevents descendants from widening the ceiling.
  - who_claims: codex protocol review
  - sources: oipproofv09

## Voxel graph (11 atoms · 32 edges)
- full graph: https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/voxels

## Article constitution

- full: https://miscsubjects.com/api/articles/constitution

## Source ledger (6)
- chain valid: no · head: ``

### fielding2000 · primary · live
- title: Architectural Styles and the Design of Network-based Software Architectures
- url: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
- summary: Primary REST dissertation; defines hypermedia as the engine of application state.
- claim_ids: c_lineage_1, c_reader_1
- hash: `44a7ec444c50eb07`

### lamport1978 · primary · live
- title: Time, Clocks, and the Ordering of Events in a Distributed System
- url: https://lamport.azurewebsites.net/pubs/time-clocks.pdf
- summary: Primary source for happened-before and logical ordering in distributed systems.
- claim_ids: c_lineage_1
- hash: `1d317c8ab607ae31`

### linkeddata2006 · primary · live
- title: Linked Data
- url: https://www.w3.org/DesignIssues/LinkedData
- summary: Primary design note on HTTP URIs, useful information, and links to discover related data.
- claim_ids: c_lineage_1, c_reader_1
- hash: `4130f3f4be938c97`

### miller2006 · primary · live
- title: Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control
- url: https://papers.agoric.com/papers/robust-composition/full-text/
- summary: Object-capability composition, authority through references, and attenuation.
- claim_ids: c_lineage_1
- hash: `bcc05c78b0fc0c42`

### oipproofv09 · live-proof · live
- title: OIP v0.9 accepted payload-ceiling invocation
- url: https://miscsubjects.com/api/dispatch?confirm=inv_sooi304em9
- summary: Public confirmation for an invocation accepted at the eight-byte ceiling; companion denials are recorded in the capability ledger.
- claim_ids: c_v09_1, c_rule_1
- hash: `74e63e6d4d35ee34`

### saltzer1975 · primary · live
- title: The Protection of Information in Computer Systems
- url: https://www.cs.virginia.edu/~evans/cs551/saltzer/
- summary: Primary statement of least privilege, complete mediation, fail-safe defaults, and related protection principles.
- claim_ids: c_lineage_1
- hash: `6d0f0e806d6c3cd1`

## Provenance (1 model passes)
- chain valid: yes · head: `3c52b2d5db40b9c3`

- moved from virtual OIP slug namespace so stored article subresources resolve correctly · unknown · 2026-07-15T03:52 · hash `3c52b2d5db40`

## Question graph
- questions: 0 · evidence ingests: 0

## LLM manifest — how to communicate with this ledger

- system map: https://miscsubjects.com/api/articles/system-map?format=markdown
- topology (ranked): https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/topology
- ingest: POST https://miscsubjects.com/api/protocol/ingest
- claim: POST https://miscsubjects.com/api/protocol/claim

### Quick actions for this article
- **Read live:** https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"object-invocation-protocol-intellectual-lineage","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest object-invocation-protocol-intellectual-lineage|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim object-invocation-protocol-intellectual-lineage|tier|assertion`
- **iMessage ask:** `object-invocation-protocol-intellectual-lineage|your question`
- **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown


---

## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `system_map` — **System map**
Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **article slug:** `object-invocation-protocol-intellectual-lineage`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **read:** https://miscsubjects.com/api/articles/system-map

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest
- **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip
- **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/object-invocation-protocol-intellectual-lineage/bundle?format=markdown
- **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*