Semantic Interlingua Layer Protocol (SILP): A Payload Codec for Cross-Model Agent Communication

1.1. Scope

SILP is a payload-layer codec. It does not replace transport protocols, lifecycle management, or capability discovery. SILP payloads are designed to be carried inside MCP's params field or A2A's task/message/artifact fields without modifying their semantics.¶

SILP operates through a pure text interface. It does not access or manipulate model-internal latent representations. All encodings produced by lossless frontends are auditable and decodable back to the canonical IR.¶

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

IR (Intermediate Representation):

The canonical semantic payload defined in Section 3. All frontends compile from and decode to this representation.¶

Frontend:

A specific surface encoding of the IR (e.g., code-like syntax, JSON, natural language). See Section 4.¶

Compile:

The process of converting an IR to a surface string via a frontend.¶

Decode:

The process of recovering an IR from a surface string via a frontend.¶

Lossless frontend:

A frontend where decode(compile(ir)) produces an IR semantically equivalent to the original for all valid IRs.¶

Action code:

An IR primitive following the format ! + UPPERCASE_VERB (e.g., !CANCEL).¶

Session:

A stateful conversation context between two or more agents, identified by a session ID.¶

Heartbeat:

A session renewal mechanism that resets accumulated context every N turns.¶

1.3. Design Principles

1. Protocol, not compression: SILP is a protocol layer with lossless round-trip guarantees. Compression is a side effect of compact encoding, not the primary goal.¶
2. Black-box text interface: SILP does not require model-internal access, fine-tuning, or latent representation manipulation. It operates purely through text that LLMs process during inference.¶
3. Tokenizer-aware vocabulary: The verb whitelist is verified to be single-token and UNK-free across six production tokenizers, ensuring cross-model token-level stability.¶
4. Auditability: All lossless frontend encodings can be decoded back to the canonical IR. The compile.lock mechanism provides tamper-evident first-pass freezing.¶
5. Extensibility: The IR root is strict (extra="forbid") while sub-models allow extra fields. Receivers MUST silently ignore unknown fields in extensible sub-models.¶

3.1. Root IR Object

The root IR object (SilpIR) MUST contain the following fields. Unknown fields at the root level are forbidden (extra="forbid").¶

3.2. Entity Object

An entity represents an argument slot. If the action field matches the root intent, the entity is an argument to the primary action. If action differs from intent, it is a secondary action (e.g., email(zhangsan) alongside cancel(flight)).¶

The Entity object allows extra fields (extra="allow"). Receivers MUST silently ignore unknown Entity fields.¶

3.3. Constraint Object

A constraint represents a condition on the task. Convention for negation: prefix the type field with ! (e.g., "!rain") to produce !rain(t+1) in the code frontend.¶

The Constraint object allows extra fields (extra="allow"). Common extra fields include subject (first positional argument in function-call constraints) and operator (infix operator such as >, <=). Receivers MUST silently ignore unknown Constraint fields.¶

3.4. Alternative Object

An alternative represents a fallback action (else-branch) executed when constraints are not met. The Alternative object allows extra fields (extra="allow").¶

3.5. Meta Object

The Meta object carries protocol-level metadata. It allows extra fields (extra="allow") for forward compatibility. Receivers MUST silently ignore unknown Meta fields.¶

3.6. Request ID (req_id) Collision Requirements

The req_id field is a hexadecimal hash used for request correlation. Based on collision testing (n=1,000 simulated IDs per condition):¶

• 4 hex chars (16 bits): 995 unique IDs, 5 collisions, 0.5% duplicate fraction. Permitted ONLY for short-lived, scope-limited sessions.¶
• 6 hex chars (24 bits): 1,000 unique IDs, 0 collisions, 0.0% duplicate fraction. Not recommended as default due to birthday-bound collision probability at scale.¶
• 8 hex chars (32 bits): 1,000 unique IDs, 0 collisions, 0.0% duplicate fraction. This is the PRODUCTION DEFAULT.¶

Implementations MUST use 8 hex characters as the default req_id length. Implementations MAY use 4 hex characters only when the session is scope-limited and the total number of concurrent requests is known to be small.¶

Note: duplicate fraction is not the same as the probability of at least one collision. In 16-bit space, the birthday-bound collision probability for n=1,000 is approximately 99.9%.¶

3.7. Action Code Format

Action codes follow the format: ! followed by UPPERCASE_VERB where the verb consists of uppercase ASCII letters and underscores. The formal grammar in ABNF [RFC5234] is:¶

<CODE BEGINS> file "action-code-abnf"


action-code = "!" 1*UPPER-LETTER *( "_" 1*UPPER-LETTER )

UPPER-LETTER = %x41-5A  ; A-Z


<CODE ENDS>

Lowercase function names in the code frontend are derived by removing the ! prefix and converting to lowercase: !CANCEL -> cancel.¶

3.8. Verb Whitelist

The following 13 verbs are approved as IR action code primitives. Each verb has been verified to be single-token (exactly 1 token) across six production tokenizers: gpt-4o (o200k_base), gpt-3.5 (cl100k_base), llama-2, qwen2.5, claude, and gemini. The complete census data is available in the reference implementation [SILP-CODE].¶

The following verbs are EXCLUDED from the whitelist and MUST NOT be used as IR action codes:¶

3.9. JSON Schema Representation

The complete IR schema is represented below as a JSON Schema (Draft 2020-12). This is the normative representation of the IR structure. Implementations MUST validate IR objects against this schema before processing.¶

<CODE BEGINS> file "silp-ir-schema.json"


{

  "$schema": "https://json-schema.org/draft/2020-12/schema",

  "$id": "https://github.com/Juwan-Hwang/polyglotir",
  "title": "SILP IR",

  "type": "object",

  "additionalProperties": false,

  "required": ["intent", "meta"],

  "properties": {

    "silp": {
      "type": "string",
      "pattern": "^v\\d+$",
      "default": "v1"
    },

    "version": { "type": "string", "default": "ir-v0.1" },

    "intent": { "type": "string", "pattern": "^![A-Z][A-Z_]*$" },

    "entities": {

      "type": "array",

      "items": {

        "type": "object",

        "additionalProperties": true,

        "required": ["id", "value"],

        "properties": {

          "id": { "type": "string" },

          "value": { "type": "string" },

          "action": {
          "type": "string",
          "pattern": "^![A-Z][A-Z_]*$"
        }

        }

      }

    },

    "constraints": {

      "type": "array",

      "items": {

        "type": "object",

        "additionalProperties": true,

        "required": ["type", "value"],

        "properties": {

          "type": { "type": "string" },

          "value": { "type": "string" },

          "time": { "type": "string" }

        }

      }

    },

    "alternatives": {

      "type": "array",

      "items": {

        "type": "object",

        "additionalProperties": true,

        "required": ["action"],

        "properties": {

          "action": {
          "type": "string",
          "pattern": "^![A-Z][A-Z_]*$"
        },

          "target": { "type": "string" },

          "location": { "type": "string" }

        }

      }

    },

    "meta": {

      "type": "object",

      "additionalProperties": true,

      "required": ["req_id"],

      "properties": {

        "req_id": { "type": "string", "pattern": "^[a-f0-9]{4,8}$" },

        "session_id": { "type": "string" },

        "priority": { "type": "integer", "default": 0 },

        "confidence": {
          "type": "number",
          "minimum": 0,
          "maximum": 1,
          "default": 1.0
        },

        "seq": { "type": "array", "items": { "type": "string" } },

        "out": { "type": "string", "default": "natural" },

        "next_agent": { "type": "string" }

      }

    }

  }

}


<CODE ENDS>

4.1. Code Frontend

The code frontend maps IR action codes to lowercase function calls (!CANCEL -> cancel()), compiles constraints as boolean conditions, entities as positional or keyword arguments, and alternatives as else: branches.¶

The general compilation form in ABNF [RFC5234] is:¶

<CODE BEGINS> file "code-frontend-abnf"


code-frontend = [ "if " condition ": " ] actions
               [ " else: " alt-actions ]

condition     = constraint *( " and " constraint )

constraint    = negation / operator-form / func-call

negation      = "!" verb [ "(" time ")" ]

operator-form = verb operator value [ ", " time ]

func-call     = verb "(" [ subject "," ] value [ "," time ] ")"

actions       = primary-call *( "; " secondary-call )

primary-call  = fn-name "(" [ args ] ")"

secondary-call = fn-name "(" [ positional-args ] ")"

alt-actions   = alt-call *( "; " alt-call )

alt-call      = fn-name "(" [ target [ "@" location ]
                 / "loc=" location ] ")"

args          = arg *( "," arg )

arg           = positional-arg / kw-arg

positional-arg = value

kw-arg        = id "=" value

fn-name       = 1*LOWER-LETTER *( "_" 1*LOWER-LETTER )

verb          = 1*UPPER-LETTER *( "_" 1*UPPER-LETTER )

LOWER-LETTER  = %x61-7A  ; a-z

UPPER-LETTER  = %x41-5A  ; A-Z


<CODE ENDS>

Examples:¶

# Negation logic

if !rain(t+1): start(hike) else start(cards@indoor)

# Multi-constraint with secondary action

if loc(me,Beijing,t+1am): cancel(flight,t+1pm); email(zhangsan)

# Keyword arguments

translate(src=fr_rev_bold, tgt=shakespeare_en, style=archaic_heavy)

# Operator condition with tool switching

if weather>rain then switch(indoor_activity)

# Nested constraints

if budget<=500 and rating>=4.0: book(hotel,downtown,t+5)

4.2. JSON Frontend

The JSON frontend renders the IR as a flat JSON object [RFC8259] with only semantic slots -- no code syntax. This isolates "format contribution" (structured JSON) from "code vocabulary prior" (function-call syntax).¶

Entities matching the root intent are flattened to top-level slots. Secondary actions (entities whose action differs from intent) are grouped under keys prefixed with action_.¶

<CODE BEGINS> file "json-frontend-example"


{

  "intent": "!CANCEL",

  "act": "flight",

  "action_email": ["zhangsan"],

  "constraints": [

    {"type": "loc",
       "value": "Beijing",
       "time": "t+1am",
       "subject": "me"}

  ]

}


<CODE ENDS>

4.3. Natural Language Frontend

The natural frontend renders the IR as unstructured English prose. It is a control baseline and does NOT support decode. Example output: "If not rain at t+1, start hike otherwise start cards at indoor."¶

4.4. NL+JSON Frontend

The nl_json frontend wraps the exact same prose produced by the natural frontend inside a JSON task_description field. It is a control baseline isolating the JSON-container effect and does NOT support decode.¶

<CODE BEGINS> file "nl-json-example"


{"task_description":
 "If not rain at t+1, start hike otherwise start cards at indoor."}


<CODE ENDS>

4.5. LLMLingua-2 Frontend

The llmlingua2 frontend compresses the natural frontend's output using LLMLingua-2 (XLM-RoBERTa-large, rate=0.5) [LLMLingua2]. LLMLingua-2 is the successor to LLMLingua [LLMLingua], which uses perplexity-based compression. It is a lossy compression baseline and does NOT support decode. The compression rate (default: 0.5) is configurable.¶

4.6. Lossless Round-Trip Guarantee

For the code and json frontends, the following invariant MUST hold for all valid IRs:¶

<CODE BEGINS> file "round-trip-invariant"


decode(compile(ir)) is semantically equivalent to ir


<CODE ENDS>

"Semantically equivalent" means the decoded IR preserves intent, entities, constraints, and alternatives. The meta.req_id of the decoded IR is regenerated from the compiled text via SHA-256 hash truncation, so it may differ from the original if the original was not generated by compile. All other fields MUST be preserved.¶

5.1. Error Codes

SILP defines the following payload-decode error codes. These exist ONLY in the payload-decode sub-layer and do NOT replace the outer MCP/A2A JSON-RPC error mechanism.¶

5.2. Session Management

In stateful mode, SILP sessions are identified by 2-character session IDs. The N parameter controls heartbeat renewal frequency: every N turns, the session context is reset. The following N values are defined:¶

• N=1: Stateless (context resets every turn).¶
• N=5: Heartbeat every 5 turns.¶
• N=10: Heartbeat every 10 turns.¶
• N=15: Heartbeat every 15 turns.¶
• N=20: Heartbeat every 20 turns.¶
• N=9999: No heartbeat (maximum context accumulation, stateful throughout).¶

5.3. Frontend Negotiation

SILP supports dynamic frontend negotiation via a //ping probe. A sender sends a //ping message listing its supported frontends. The receiver responds with its supported frontends and a preferred frontend. Both parties then use the highest-priority mutually supported frontend.¶

The negotiation protocol is partially specified. The degradation chain defines a fallback order when a negotiated frontend fails:¶

code -> math -> JSON -> natural language

6.1. Layer 4: Optimization Layer

Layer 4 defines a multi-objective fitness function for frontend selection and IR optimization. The fitness function is:¶

<CODE BEGINS> file "fitness-function"


Fitness = alpha * task_success

        + alpha_prime * cross_model_fidelity

        + beta * compression

        - gamma * human_unreadability

        - delta * PPL

        - epsilon * tokenizer_variance

        - zeta * cross_model_ambiguity


<CODE ENDS>

Constrained by alpha + alpha_prime >= 0.6 and a hard fidelity floor. This layer is design-only and not yet experimentally validated.¶

6.2. Layer 5: Migration Layer

Layer 5 is a proposed migration screening layer intended to test ranking preservation: if small models and API-reported endpoints rank frontends similarly (high Spearman rho), small models could serve as proxies for frontend evaluation. This layer is not yet validated.¶

7.1. AIDIP Integration

The AI Agent Discovery and Invocation Protocol (AIDIP), as discussed in recent IETF work, defines a RESTful interface for agent discovery (POST /agents/search) and invocation (POST /agents/{id}/invoke). AIDIP's invocation interface accepts an inputs field containing the task description. A SILP-encoded string can replace the natural-language inputs content, providing cross-model semantic consistency without modifying AIDIP's discovery or invocation semantics.¶

7.2. MCP Integration

In MCP [MCP], a SILP payload is carried inside the params field of a JSON-RPC request. The SILP-encoded string replaces the natural-language instruction text that would normally appear in params.¶

7.3. A2A Integration

In A2A [A2A], a SILP payload is carried inside task, message, or artifact fields. SILP does not replace A2A's lifecycle management.¶

8.1. Zero-Width and Homoglyph Attacks

SILP payloads are text-based and therefore susceptible to zero-width character injection and homoglyph substitution attacks. Testing across six tokenizers (gpt-4o, gpt-3.5, llama-2, qwen2.5, claude, gemini) confirmed that 4 types of zero-width characters (ZWSP, ZWNJ, ZWJ, BOM) and Latin-to-Cyrillic homoglyph substitutions alter tokenization in all 144 probes conducted (5 probe verbs for zero-width injection, 2 probe verbs for homoglyph substitution, 6 tokenizers).¶

Implementations SHOULD sanitize input by stripping zero-width characters (U+200B, U+200C, U+200D, U+FEFF) and normalizing homoglyphs before processing SILP payloads. However, this does not constitute a complete security guarantee -- visual invisibility, preprocessing normalization, and downstream parser behavior are separate concerns.¶

8.2. Payload Injection

SILP payloads carry task instructions. Implementations MUST NOT allow SILP payloads to carry content that bypasses safety filters. The verb whitelist (see Section 3.8) restricts the action space to legitimate task verbs, reducing (but not eliminating) injection risk.¶

8.3. Request ID Collision

The req_id field uses 4-8 hex characters. With 4 hex characters (16 bits), the birthday-bound collision probability for n=1,000 requests is approximately 99.9%. Implementations MUST use 8 hex characters (32 bits) as the production default to minimize collision risk.¶

8.4. Model Identity

SILP operates through a black-box text interface and does not verify the identity of the receiving model. If a proxy misroutes requests (e.g., serving a different model for one provider), the cross-model comparison would be compromised. This is a known limitation of the black-box approach.¶

8.5. Lossy Compression Risks

The llmlingua2 frontend uses lossy ML-based compression that may remove or obscure negation markers and entity boundaries. Implementations MUST NOT use llmlingua2 for payloads where semantic precision is critical, particularly for negation logic. The code and json frontends are RECOMMENDED for all production use.¶

A.1. Example 1: Negation Logic with Alternative

<CODE BEGINS> file "example1-ir"


{

  "silp": "v1",

  "intent": "!START",

  "entities": [

    {"id": "act", "value": "hike", "action": "!START"}

  ],

  "constraints": [

    {"type": "!rain", "value": "true", "time": "t+1"}

  ],

  "alternatives": [

    {"action": "!START", "target": "cards", "location": "indoor"}

  ],

  "meta": {"req_id": "a1b2c3d4", "out": "code"}

}


<CODE ENDS>

Code frontend output:¶

if !rain(t+1): start(hike) else start(cards@indoor)

JSON frontend output:¶

{"intent":"!START",
 "act":"hike",
 "constraints":[{"type":"!rain","value":"true","time":"t+1"}],
 "alternatives":[{"action":"!START","target":"cards",
  "location":"indoor"}]}

Natural frontend output:¶

If not rain at t+1, start hike otherwise start cards at indoor.

A.2. Example 2: Multi-Constraint with Secondary Action

<CODE BEGINS> file "example2-ir"


{

  "silp": "v1",

  "intent": "!CANCEL",

  "entities": [

    {"id": "act", "value": "flight", "action": "!CANCEL"},

    {"id": "time", "value": "t+1pm", "action": "!CANCEL"},

    {"id": "act", "value": "zhangsan", "action": "!EMAIL"}

  ],

  "constraints": [

    {"type": "loc",
       "value": "Beijing",
       "time": "t+1am",
       "subject": "me"}

  ],

  "alternatives": [],

  "meta": {"req_id": "e5f6g7h8", "out": "code"}

}


<CODE ENDS>

Code frontend output:¶

if loc(me,Beijing,t+1am): cancel(flight,t+1pm); email(zhangsan)

A.3. Example 3: Keyword Arguments (Detail Preservation)

<CODE BEGINS> file "example3-ir"


{

  "silp": "v1",

  "intent": "!TRANSLATE",

  "entities": [

    {"id": "src", "value": "fr_rev_bold", "action": "!TRANSLATE"},

    {"id": "tgt", "value": "shakespeare_en", "action": "!TRANSLATE"},

    {"id": "style", "value": "archaic_heavy", "action": "!TRANSLATE"}

  ],

  "constraints": [],

  "alternatives": [],

  "meta": {"req_id": "1a2b3c4d", "out": "code"}

}


<CODE ENDS>

Code frontend output:¶

translate(src=fr_rev_bold, tgt=shakespeare_en, style=archaic_heavy)

A.4. Example 4: Nested Constraints

if budget<=500 and rating>=4.0: book(hotel,downtown,t+5)

A.5. Example 5: Parallel Actions with Sequencing

fetch(data) -> process -> email(result) with timeout