## §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:** `what-is-self-describing-protocol`
- **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/what-is-self-describing-protocol/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/what-is-self-describing-protocol/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/what-is-self-describing-protocol/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/what-is-self-describing-protocol/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/what-is-self-describing-protocol/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/what-is-self-describing-protocol/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:** `what-is-self-describing-protocol`
- **title:** What Is a Self-Describing Protocol
- **url:** https://miscsubjects.com/a/what-is-self-describing-protocol
- **register:** standard
- **updated:** 2026-07-15T04:21:04.003Z
- **tags:** oip, kimi-import, self-explaining, voxel, concepts, what-is-self-describing-protocol

## Body

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) › **What Is a Self-Describing Protocol**
>
> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# What Is a Self-Describing Protocol

## §SELF — what-is-self-describing-protocol

**What this page is:** A definition of a self-describing protocol and an explanation of why it matters.
**What it explains:** What makes a protocol self-describing, what properties it must have, and how it enables systems to operate without prior knowledge.
**Why read it:** To understand how a protocol can teach itself to anything that connects to it, and why this property is necessary for systems that must work with zero prior context.

### What a Self-Describing Protocol Is

A self-describing protocol is a communication protocol where every response carries the information needed to understand what just happened, what can happen next, and what authority the caller has. A client (a program that sends requests) does not need external documentation to operate the protocol. The protocol teaches itself through its responses.

### Why It Matters

A protocol that requires a human to read a specification before a program can use it creates friction. That friction slows down development, introduces bugs from misreading, and excludes any system that cannot access or parse external documentation. A self-describing protocol removes this barrier. An artificial intelligence model, an automated agent, or a system with zero prior context can connect to a self-describing protocol, read its first response, and know what to do next. The protocol is autopoietic — it produces the information required to operate it.

### The Key Idea

Every response from a self-describing protocol contains five types of information:

1. **§SELF block.** Every response includes a section that states: what this response is, what protocol it belongs to, what version of the protocol is in use, and where to find the full specification.
2. **In-band discovery.** The client learns what actions are available by reading the responses, not by reading a separate document. The protocol embeds its own API documentation in every response.
3. **Typed responses.** Every response has a type label. Examples of types: `invocation_result`, `error`, `capability_record`, `redirect`, `confirmation_required`. The type tells the client how to interpret the rest of the response.
4. **Authority awareness.** The response states what authority was used to produce it, and what authority remains. A client knows whether it has permission to retry, to escalate, or to access a related resource.
5. **Link-carrying.** The response includes URLs or identifiers for next actions: replay the same request, repair an error, confirm a result, or navigate to a related object. The client does not need to construct URLs; it follows the links provided.

### What They Got Right

- HATEOAS (Hypermedia as the Engine of Application State) demonstrated that REST API responses can include links to next actions. A client navigates an API the same way a human navigates a website: by following links. This was the first widespread implementation of a self-describing pattern.
- The Semantic Web (RDF, linked data) showed that data can carry its own schema. Every piece of data includes its type and its relationships to other data. A program reading RDF does not need a separate schema document; the schema is in the data.
- KeyKOS and later capability-based systems showed that a capability (an unforgeable token that grants access to an object) can carry its own permissions. The capability is both the reference to the object and the proof of authority. It is self-describing by construction.
- OIP (Open Invocation Protocol) combines all of these. Every OIP response includes a §SELF block with protocol identity, spec URL, response type, authority used, and links for next actions. OIP is designed so that a model with zero prior knowledge can operate it after reading one response.

### What They Got Wrong or Left Unfinished

- HATEOAS does not include authority information. A REST response may contain links, but it does not state what permissions the client has. The client must track its own authorization state separately.
- The Semantic Web assumes that parsers understand RDF syntax. It is self-describing at the semantic level, but not at the syntactic level. A client still needs to know how to parse RDF before it can read the self-describing content.
- Self-describing protocols increase response size. Every response carries metadata that a non-self-describing protocol would omit. This overhead is a trade-off. No standard exists for measuring whether the benefit of self-description outweighs the cost.
- No formal definition of "self-describing" exists across all protocols. Different communities use the term to mean different things. A unified formal model has not been written.

### How It Connects to Other Ideas

- **Autopoiesis.** Autopoiesis (a term from biology) means a system produces the components needed to maintain itself. A self-describing protocol is autopoietic in an information sense: it produces the information needed to operate it. The protocol maintains its own operability.
- **Capability-based security.** A capability is a self-describing authorization. It carries both the reference to a resource and the proof that access is permitted. Capability systems and self-describing protocols share the same design philosophy: the token carries everything you need.
- **Zero-knowledge operation.** A self-describing protocol enables a client to operate with zero prior knowledge. This is the opposite of protocols that require pre-shared configuration, pre-downloaded schemas, or pre-registered credentials. Zero-knowledge operation means any system can connect and learn.

### Sources

- Fielding, R. T. "Architectural Styles and the Design of Network-based Software Architectures." PhD dissertation, University of California, Irvine, 2000. (Chapter on REST and HATEOAS)
- Berners-Lee, T. "Linked Data." W3C Design Issues, 2006.
- Hardy, N. "The Confused Deputy." *Operating Systems Review*, 1988. (KeyKOS capability model)
- OIP Specification: §SELF block definition, response typing, and link-carrying protocol.

---

## Up the tree

- [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Protocol Concepts shelf](https://miscsubjects.com/a/oip-protocol-concepts) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [What Is Autopoiesis](https://miscsubjects.com/a/what-is-autopoiesis)
- [What Is Capability-Based Security](https://miscsubjects.com/a/what-is-capability-security)
- [What Is a Capability Token](https://miscsubjects.com/a/what-is-capability-token)
- [What Is a Confused Deputy](https://miscsubjects.com/a/what-is-confused-deputy)
- [What Is Context as Cursor](https://miscsubjects.com/a/what-is-context-as-cursor)
- [What Is a Convergence Catalogue](https://miscsubjects.com/a/what-is-convergence-catalogue)
- [What Is a Falsification Surface](https://miscsubjects.com/a/what-is-falsification-surface)
- [What Is HATEOAS](https://miscsubjects.com/a/what-is-hateoas)

## Machine surfaces

- Public page: `https://miscsubjects.com/a/what-is-self-describing-protocol`
- JSON article: `https://miscsubjects.com/api/articles/what-is-self-describing-protocol`
- OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20Is%20a%20Self-Describing%20Protocol`


## Claims (0)


## Voxel graph (0 atoms · 0 edges)
- full graph: https://miscsubjects.com/api/articles/what-is-self-describing-protocol/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: `68c1c91451a57c5c`

- write · kimi-agent-import · 2026-07-15T04:21 · hash `68c1c91451a5`

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