{"_self":{"principle":"Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.","widget":"article_topology","feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","contains":"claims, sources, anecdotes, question_graph slice","slug":"what-is-self-describing-protocol","urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/topology"},"how_to_use":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","write":null,"imessage":null,"router_tag":null,"proof_chain":[{"step":1,"claim":"Articles are voxel graphs of tiered claims, not prose blobs.","verify":"https://miscsubjects.com/api/articles/constitution"},{"step":2,"claim":"Claims link to hash-chained sources via source_ids.","verify":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/sources"},{"step":3,"claim":"Ask reads topology; ingest/claim append to ledger.","verify":"https://miscsubjects.com/api/protocol"},{"step":4,"claim":"Models queue growth: populate → collaborate → repair → reflex.","verify":"https://miscsubjects.com/api/protocol/grow"},{"step":5,"claim":"Graph proves its own shape (reflex) and $/claim (yield).","verify":"https://miscsubjects.com/graph.html?layer=reflex"},{"step":6,"claim":"Full feature index + _explain on every API response.","verify":"https://miscsubjects.com/api/articles/system-map"}],"related_features":[{"id":"ask","name":"Ask protocol","what":"Answer only from topology; creates question_node with gaps and ingest_hint.","urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/prompts","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"graph_topology","name":"Cross-article graph","what":"Merged claims/sources across condition+stack slugs for one question.","urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/graph-topology?question=..."}},{"id":"question_graph","name":"Question graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output).","urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/question-graph","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"voxels","name":"Voxel graph","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance.","urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/voxels","write":"https://miscsubjects.com/api/protocol/claim"}}],"system_map":"https://miscsubjects.com/api/articles/system-map","system_map_markdown":"https://miscsubjects.com/api/articles/system-map?format=markdown","not_medical_advice":true},"_explain":{"feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","why":"Every feature is auditable collective intelligence","how":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","model":null,"verifies":null,"urls":{"read":"https://miscsubjects.com/api/articles/what-is-self-describing-protocol/topology"},"imessage":null,"router":null,"related":[{"id":"ask","what":"Answer only from topology; creates question_node with gaps and ingest_hint."},{"id":"graph_topology","what":"Merged claims/sources across condition+stack slugs for one question."},{"id":"question_graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output)."},{"id":"voxels","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance."}],"not_medical_advice":true},"slug":"what-is-self-describing-protocol","title":"What Is a Self-Describing Protocol","register":"standard","tags":["oip","kimi-import","self-explaining","voxel","concepts","what-is-self-describing-protocol"],"updated_at":"2026-07-15T04:21:04.003Z","body_excerpt":"<!-- hierarchy:nav -->\n> **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**\n>\n> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready\n> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)\n\n# What Is a Self-Describing Protocol\n\n## §SELF — what-is-self-describing-protocol\n\n**What this page is:** A definition of a self-describing protocol and an explanation of why it matters.\n**What it explains:** What makes a protocol self-describing, what properties it must have, and how it enables systems to operate without prior knowledge.\n**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.\n\n### What a Self-Describing Protocol Is\n\nA 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.\n\n### Why It Matters\n\nA 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.\n\n### The Key Idea\n\nEvery response from a self-describing protocol contains five types of information:\n\n1. **§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.\n2. **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.\n3. **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.\n4. **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.\n5. **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.\n\n### What They Got Right\n\n- 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.\n- 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.\n- 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 au","ranking":"safety-first (interaction_risk/limitations), then quote-gated effective_weight","claims":[],"sources":[],"anecdotal_sources":[],"scientific_sources":[],"user_reports":[],"related_articles":[],"question_graph":{"slug":"what-is-self-describing-protocol","questions":[],"evidence":[],"edges":[],"counts":{"questions":0,"evidence":0,"edges":0}},"honesty":{"active_claims":0,"retracted_claims":0,"cut_claims":0,"challenges":0,"scrub_events":0,"note":"Retracted/cut claims stay on ledger but are excluded from ask unless ?include_inactive=1"},"counts":{"claims":0,"claims_total":0,"sources":0,"anecdotal":0,"scientific":0,"user_reports":0,"questions":0,"evidence_ingests":0}}