## §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:** `oip-where-the-ideas-come-from`
- **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/oip-where-the-ideas-come-from/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/oip-where-the-ideas-come-from/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/oip-where-the-ideas-come-from/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/oip-where-the-ideas-come-from/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/oip-where-the-ideas-come-from/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/oip-where-the-ideas-come-from/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:** `oip-where-the-ideas-come-from`
- **title:** Where OIP Ideas Come From - and What to Build Next
- **url:** https://miscsubjects.com/a/oip-where-the-ideas-come-from
- **register:** standard
- **updated:** 2026-07-15T04:14:45.756Z
- **tags:** oip, history, protocol

## Body

## 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](/api/dispatch?confirm=inv_k0uoh5rv9t) and [artifact-bearing receipt](/api/dispatch?confirm=inv_n55q2hp7ba). 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](/a/object-invocation-protocol-intellectual-lineage).

## Claims (0)


## Voxel graph (0 atoms · 0 edges)
- full graph: https://miscsubjects.com/api/articles/oip-where-the-ideas-come-from/voxels

## Article constitution

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

## Source ledger (0)
- chain valid: yes · head: `genesis`

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

- OIP 1.0 shipped-status update · codex · 2026-07-15T04:14 · hash `e574e3e3c294`

## 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/oip-where-the-ideas-come-from/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/oip-where-the-ideas-come-from/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"oip-where-the-ideas-come-from","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest oip-where-the-ideas-come-from|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim oip-where-the-ideas-come-from|tier|assertion`
- **iMessage ask:** `oip-where-the-ideas-come-from|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:** `oip-where-the-ideas-come-from`
- **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/oip-where-the-ideas-come-from/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/oip-where-the-ideas-come-from/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.*