# Protocol Index

**Identifier:** `idx:protocols/index`
**Version:** `0.2.0`
**Status:** Normative Candidate
**Date:** 2026-08-30
**Scope:** Every protocol and research program in this directory, the question each answers, and the boundary each declares.

---

## 0. Abstract

Twelve protocols and research programs, written independently over about eighteen months, that turn out to compose. This document is the human protocol table. Supporting resources are also tracked in the machine-readable registry, but do not become protocols merely by being registered. The table states what each one is, what it governs, what it explicitly does not claim, and where it sits relative to the others.

A protocol appears here only if it states a question it answers and a boundary it refuses to cross. That is the entry requirement. It is also why the set composes rather than overlaps.

---

## 1. The stack, in one pass

Each protocol answers one question. Read in order they form one sentence. *What is the theory. What is a bounded interaction. What does the evidence justify. How is work governed. What is shown. How is it decided. How is it written. In what order does it reach a reader.*

| # | Protocol | Registry ID | Declared version | The question it answers |
|---|---|---|---|---|
| 1 | Foundations of Computational Interaction | `fci` | 0.5.0 | How is interaction formally described, measured and predicted? |
| 2 | Interaction Contract Protocol | `icp` | 0.1.0 | What must a consequential interaction declare before it runs? |
| 3 | Evidence Qualification Protocol | `eqp` | 0.1.0 | Given this candidate, claim, context and evidence, what is justified? |
| 4 | Intent and Evidence Project Engine | `iepe` | 0.2.0 | How does intent become authorized work, and what blocks promotion? |
| 5 | Semantic Expression System | `ses` | 1.0.0 | How can meaning stay fixed while expression changes completely? |
| 6 | Semantic Surface System | `sss` | 0.1.0 | Given this state and situation, what surface is warranted here? |
| 7 | Semantic Publication Substrate | `sps` | 0.1.0 protocol; 0.2.0 project profile | How is published truth separated from its presentation? |
| 8 | Polymorphic Decision Protocol | `pdp` | 1.3.0 | How is a high-uncertainty decision made with a panel of systems? |
| 9 | Human–Computer Mutual Legibility | `hcml` | 2.0.0 | Can human intent and machine state be made mutually inspectable? |
| 10 | Authored Prose Protocol | `app` | 0.1.0 | What must prose published under this name do, and how is it checked? |
| 11 | Priming Toolkit | `nps` | 1.0.0 | What makes an agent primer measurably effective? |
| 12 | Narrative Evidence Method | `nem` | 0.1.0 | In what order does a qualified claim reach the reader? |

The registry IDs above are stable machine identifiers. Protocol-native identifiers remain authoritative inside each protocol (for example `icp:protocol/interaction-contract`, `eqp:protocol/evidence-qualification`, `IEPE-001`, and `sss:protocol/semantic-surface`). A native identifier is not replaced by its registry ID; the registry provides the cross-repository key.

---

## 2. What each one refuses

The boundary is the load-bearing half of a specification. A reader checking whether these overlap finds the answer faster here than in the specifications.

| Protocol | Declares it does **not** |
|---|---|
| FCI | Claim empirical validity. Passing the reference tests is kernel conformance and nothing more |
| ICP | Prove usability or quality. Schema conformance is structural validity only (§4.10) |
| EQP | Authorize promotion, deployment, publication or spending. Promotion authority consumes qualification; it is not granted by it |
| IEPE | Treat evaluation as promotion. They are separate, and human evidence is required before comprehension and trust claims |
| SES | Bind interface meaning to any one rendering |
| SSS | Decide domain truth. It decides which surface that truth warrants |
| SPS | Publish content, mutate external state, or expose readable text — the prototype is fixture-bound |
| PDP | Claim the protocol beats naive selection. That is a hypothesis with a recording apparatus, on n=1 |
| HCML | Claim the theory is empirically validated. Implemented mechanisms are distinguished from hypotheses throughout |
| APP | Produce prose that is good, interesting or correct. It produces prose that is checkable |
| NPS | Claim its measurements validate the primers. The validating experiment is written and unrun |
| NEM | Decide whether evidence is sufficient. It governs presentation only; sufficiency belongs to EQP and to the manuscript's gates |

---

## 3. How they compose

Relationships are declared, not inferred. Where two protocols touch, one of them states the boundary in its own text.

- **FCI → ICP.** FCI supplies the epistemic distinctions: representation, observation, evidence, interpretation, conformance, empirical validity. ICP turns them into a declarable contract.
- **ICP → EQP.** An ICP interaction emits evidence and verification outputs. EQP consumes them and decides what they justify.
- **IEPE → EQP.** EQP is the qualification segment of IEPE, extracted so it can run without any particular execution engine.
- **EQP → promotion.** Qualification is an input to promotion authority, never a grant of it.
- **SES → SSS → SPS.** Meaning separated from expression; then which surface a situation warrants; then publication truth separated from presentation.
- **PDP** stands apart. It governs a decision under uncertainty rather than a system. It is also the only entry with an external stake and a recorded instance of the protocol catching its own author.
- **APP** governs the prose all of the above are written in, including this document.
- **HCML** is the research program the others would serve if it holds. It is the least settled and says so.

---

## 4. Maturity

Stated plainly, because the register is worth less if it flatters the set.

| Protocol | Specification | Implementation | External review |
|---|---|---|---|
| FCI | drafted, layered, versioned independently | C reference substrate with a reproducible hash | none |
| ICP | complete, 7 conformance levels | schemas and conformance suite named | none |
| EQP | complete, with formal model and falsification | none declared | none |
| IEPE | complete, 12 invariants | two conforming projects, revision-pinned | none |
| SES | 1.0.0 release standard | conforming, `profileStatus: release` | none |
| SSS | normative candidate | conformance directory present | none |
| SPS | working | local prototype, fixture-bound | none |
| PDP | 1.3.0 with architecture and schema | reference design; one recorded case | pre-registration written |
| HCML | research corpus, two volumes | mechanisms drawn from existing projects | none |
| APP | 23 rules, self-checked | mechanical checks specified | none |
| NPS | spec plus measured corpus of 20 prompts | validators shipped | none |

**No entry in this register has been reviewed by anyone outside the author.** That is the honest state of the set. It is also the single largest thing that would change its standing.

---

## 5. Conformance of this register

**R1.** A protocol **MUST NOT** appear here without a stated question and a stated boundary.
**R2.** A relationship in §3 **MUST** be declared in at least one of the two protocols' own text. Adjacency **MUST NOT** be read as composition.
**R3.** Maturity in §4 **MUST** reflect what exists, not what is planned. A row **MUST NOT** be upgraded on intent.
**R4.** This document is written under `app:protocol/authored-prose` and **MUST** pass its §2 checks.

## Sources

Each protocol's own specification in this directory. Relationship claims in §3 come from `evidence-qualification-protocol/05-PROTOCOL-RELATIONSHIPS.md` and from the boundary sections of the protocols named.
