miscsubjects.com
Evidence review · standard

What Is a Self-Describing Protocol

#oip#kimi-import#self-explaining#voxel#concepts#what-is-self-describing-protocol
bundle · json · system map · manifest

Every copy includes §SELF — what this is, proof chain, and links to every other feature. No context required.

§SELF — this page explains the system
## §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:** `human_page` — **Human article page**
Rendered article with claims, sources, copy widgets, ask prompts.
- **article slug:** `what-is-self-describing-protocol`
- **contains:** rendered article, copy widgets, claims, sources, ask prompts
- **how to use:** Use Copy for LLM or Copy system map — both paste without context.
- **read:** https://miscsubjects.com/a/what-is-self-describing-protocol

### 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)
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/what-is-self-describing-protocol/bundle?format=markdown
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/what-is-self-describing-protocol/prompts
- **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

### 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.*

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › Protocol Concepts › What Is a Self-Describing Protocol

Shelf: Protocol Concepts · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

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

Related on this shelf

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

what-is-self-describing-protocol · condition map

Evidence map

Hover a node — its path lights up. Click to open the article.

Full map →
20
Protocol Concepts on shelf
Talk to this article
Tap a phone. Ask anything about What Is a Self-Describing Protocol. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.

Related articles

what-is-self-describing-protocol · condition map

Open evidence map →
What Is Voxel Graphshared topicwhat-is-voxel-graphWhat Is "The URL Is the API"shared topicwhat-is-url-is-apiWhat Is Token Dropshared topicwhat-is-token-dropWhat Is Tap Goshared topicwhat-is-tap-goMandelbrot 1967: Statistical Self-Similarity and Fractional Dimensionshared topicpaper-mandelbrot-b-b-1967-how-long-is-the-coast-of-britain-statistical-self-similarityMandelbrot on Multifractals and 1/f Noise: Wild Self-Affinity in Physicsshared topicpaper-mandelbrot-b-b-1999-multifractals-and-1-f-noise-wild-self-affinity-in-physics-spvon Neumann and Burks: Theory of Self-Reproducing Automata (1966)shared topicpaper-von-neumann-j-and-burks-a-w-1966-theory-of-self-reproducing-automataEigen and Schuster on the Hypercycle (1977)shared topicpaper-eigen-m-schuster-p-1977-the-hypercycle-a-principle-of-natural-self-organization
Ask this article · 2 suggested prompts
topology · JSON · question graph

Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.

For my medical situation, what can you answer from your catalogue about What Is a Self-Describing Protocol — and what would you need me to tell you first?
ask what-is-self-describing-protocol condition gaps · paste includes §SELF
What good and bad outcomes are documented for What Is a Self-Describing Protocol (studies vs anecdotes)?
ask what-is-self-describing-protocol good bad experiences · paste includes §SELF
Add your experience or question
Think this article is wrong?
Call bullshit on CharlieOS →
Loading more articles…