4 Protocol Design Principles

🧭 4. Protocol Design Principles

Every successful protocol has a set of core beliefs guiding its technical decisions — HTTP's "statelessness" allows the Web to scale infinitely, Markdown's "readability first" makes source text readable even without rendering. ICP likewise follows 6 core design principles that collectively define the protocol's technical philosophy and constrain all subsequent design choices.

Principle 1: Annotation-Based Enhancement, Not Replacement

ICP does not replace natural language, but overlays structured annotations on top of it. Removing all annotations leaves the original text fully readable.

This principle stems from the "marking expressed information" methodology in Chapter 3 — we reference Markdown's use of special characters for specific meanings, and Java's annotation principle for explaining and triggering auxiliary functions. ICP's annotations are "marginal notes" on natural language, not rewrites or encodings.

For example, a user says "Help me send the !!before end of work today!! project report to @Zhang San." Removing all annotation markers, this sentence remains fluent natural language: "Help me send the project report to Zhang San before end of work today." But with annotations, the system can identify the deadline (priority marker), key content (emphasis marker), and recipient (person reference marker), generating an action card with deadline, attachment, and send button.

This means: the lowest degradation form of an ICP document is plain text. Any system that doesn't support ICP can safely ignore annotations and display only the original text.

Principle 2: Terminal Agnosticism

The protocol itself does not assume any specific terminal's capabilities. ICP only describes "what" (semantic content), not "how to display" (rendering method).

This principle directly responds to the "significant differences in human-machine interfaces across different terminals" problem in Chapter 3. Since we cannot predict what device information will ultimately be presented on, the protocol should not bind to any specific display form. Terminals choose the best presentation method based on their own capabilities, and unsupported annotations can be safely ignored.

For example, the same ICP document containing "expense report review" semantics: desktop renders it as a large-screen interface with tables and attachment previews; mobile shows only key information and two buttons (approve/reject); smart speaker reads out a summary and waits for voice confirmation; AR glasses display an approval notification floating in the user's field of view. Four terminals, four presentations, but completely identical semantics.

Principle 3: Explicit Context

All context information that affects understanding should be explicitly attached to messages. The protocol does not rely on AI's ability to "read between the lines" to infer implicit meaning.

This principle stems from the "adding context information" methodology in Chapter 3, and the core argument in the "is intermediate language necessary" discussion — AI's control over the environment is limited, and AI may not be that close to humans. Therefore, we choose the prudent approach: better redundant than missing.

For example, a user says "book a restaurant Marry likes nearby." If only this sentence is transmitted, AI doesn't know where "nearby" is, who Marry is, or what the budget is. Through ICP's explicit context, location coordinates, Marry's dining preferences, historical order records, and budget range are all explicitly attached to the message, allowing AI to understand precisely without guessing.

Principle 4: Progressive Enhancement

The simplest ICP document is a plain text message. Annotations, context, and rendering hints are all optional enhancement layers. Implementers can start with the simplest support and gradually add capabilities.

This means the entry barrier is extremely low, while the ceiling is extremely high. A system that only supports plain text is already a legitimate ICP implementation; as capabilities grow, it can progressively support annotation parsing, context management, dynamic interface assembly, cross-terminal coordination, and other advanced features.

For example, the progressive enhancement process of an ICP document:

• Layer 1 (plain text): "Help me book a meeting room for tomorrow afternoon"
• Layer 2 (add annotations): "Help me book [tomorrow afternoon]'s **meeting room**" — system identifies time and key object
• Layer 3 (add context): Attach user's calendar information, preferred meeting rooms, number of attendees
• Layer 4 (add rendering hints): Specify display as a form card showing available meeting rooms sorted by distance

Principle 5: Backward Compatibility

New versions of the protocol must be able to handle old version documents. Unknown annotation types should be safely ignored rather than causing errors.

Protocol evolution will not break the existing ecosystem. This is crucial for a protocol aspiring to become infrastructure — adopters need confidence that systems built on ICP v1 today will not become invalid when v2 is released.

For example, when a v2 parser encounters a v1 document: the v1 document doesn't contain the v2-added rendering_hint field, and the parser processes normally using default rendering strategies. Conversely, when a v1 parser encounters a v2 document: the v2 document contains a visibility_marker annotation type that v1 doesn't recognize, and the parser preserves the raw text content, ignores the unknown annotation, and continues processing without interruption.

Principle 6: Open Interoperability

ICP is not bound to any specific AI model, platform, or vendor. Through the skills mechanism, ICP bridges with existing protocols like MCP (Model Context Protocol), A2A (Agent-to-Agent), and OpenAPI.

ICP is a connection layer, not a closed ecosystem. Its value lies in providing a unified semantic description for human-machine interaction, while specific AI reasoning, tool invocation, and inter-agent communication are handled by their respective specialized protocols.

For example, an ICP document can declare through the skills registry: invoke a weather query service (via OpenAPI binding), execute file operations (via MCP tool binding), request assistance from another AI agent (via A2A binding). ICP is responsible for describing interaction semantics and user context, while the actual service calls are completed by the corresponding protocols.