]> Shanghai Maritime University

1550 Haigang Av. Shanghai 201306 CN huangzhiwen@stu.shmtu.edu.cn https://github.com/Juwan-Hwang

General Independent Submission LLM agent communication protocol interlingua prompt compression MCP A2A This document specifies the Semantic Interlingua Layer Protocol (SILP), a black-box, text-interface payload codec designed for cross-model agent-to-agent communication. SILP defines a coarse-grained action-slot intermediate representation (IR) as the canonical semantic layer and compiles it into multiple pluggable surface frontends -- code-like function-call syntax, pure JSON, natural language, and ML-compressed text. SILP is designed as a payload-layer option within existing agent transport protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol, which define transport envelopes and capability discovery but leave payload encoding unspecified. SILP provides compile/decode round-trip guarantees for lossless frontends, dynamic frontend negotiation via probe messages, session management with heartbeat renewal, and a verb whitelist verified across six production tokenizers for cross-model token-level stability. This document is a product of independent research and is not an IETF standard. It is published as an Informational document to establish a stable reference for implementers.

Introduction The rise of agentic AI systems has created a new communication paradigm: large language models (LLMs) conversing not with humans, but with other LLMs through structured text protocols. Frameworks such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol define transport envelopes and capability discovery, but leave a critical gap: how should the semantic payload itself be encoded? Current practice defaults to uncompressed natural language, which is token-inefficient, tokenizer-dependent, and semantically ambiguous -- particularly for negation logic, multi-step action chains, and conditional branching. SILP addresses this gap by defining a protocol layer that compiles a canonical intermediate representation (IR) into multiple surface encodings, each designed to exploit the shared training priors of contemporary LLMs. The concept of an interlingua -- an intermediate representation that mediates between input and output languages -- has a long history in machine translation; Abstract Meaning Representation (AMR) is a notable graph-semantic example. SILP adapts this concept to the LLM-agent domain: the IR is the interlingua, and frontends are the surface encodings compiled from it. Recent IETF discussions have begun addressing the agent protocol ecosystem at multiple layers. The AI Agent Discovery and Invocation Protocol (AIDIP) defines how agents are discovered and invoked (agent metadata, registration, search, and a RESTful invocation interface). The Agent-to-Agent (A2A) protocol defines task lifecycle, message transport, and artifact exchange between agents. The Model Context Protocol (MCP) defines how agents invoke external tools. However, these protocols all leave the encoding of semantic payload content to the implementer. SILP fills this gap: it is not a competing transport or discovery protocol, but a payload-layer codec that can be embedded within the message fields of A2A, MCP, or AIDIP-based systems to ensure cross-model semantic consistency.

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.

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 when, and only when, they appear in all capitals, as shown here.

IR (Intermediate Representation):

The canonical semantic payload defined in . 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 .

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.

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.

Protocol Architecture SILP is a five-layer protocol stack. Layers 1 and 2 are fully specified in this document. Layer 3 is partially specified. Layers 4 and 5 are design-level and reserved for future work. SILP Five-Layer Stack

Layer	Name	Module	Description	Status
1	Application	silp.ir	Semantic IR (action-slot structure)	Specified
2	Surface	silp.frontend	Pluggable frontends (code, JSON, natural, nl_json, llmlingua2)	Specified
3	Meta-protocol	silp.negotiation	Frontend negotiation, session management, error codes	Partially specified
4	Optimization	silp.bench	Multi-objective fitness function + genetic algorithm	Future work
5	Migration	silp.bench	Small-model screening proxy for frontend evaluation	Future work

Layer 1: Application Layer (Semantic IR) The canonical intermediate representation is a JSON-serialized action-slot structure. It is the single source of semantic truth: all frontends compile from this IR and decode back to it. The IR is defined as a JSON Schema with strict validation at the root level and extensible sub-models.

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

Field	Type	Required	Default	Description
silp	string	No	"v1"	Protocol version. MUST match ^v\d+$.
version	string	No	"ir-v0.1"	IR schema version.
intent	string	Yes	--	Main action code. MUST match ^![A-Z][A-Z_]*$.
entities	array of Entity	No	[]	Argument slots and secondary actions.
constraints	array of Constraint	No	[]	Conditions on the task.
alternatives	array of Alternative	No	[]	Fallback actions (else-branch).
meta	Meta object	Yes	--	Protocol-level metadata.

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. Entity Fields

Field	Type	Required	Default	Description
id	string	Yes	--	Slot identifier. "act" indicates a positional argument.
value	string	Yes	--	The slot value.
action	string (optional)	No	null	Action code if this entity belongs to a secondary action. MUST match ^![A-Z][A-Z_]*$.

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. Constraint Fields

Field	Type	Required	Default	Description
type	string	Yes	--	Constraint type. Prefix ! for negation.
value	string	Yes	--	Constraint value.
time	string (optional)	No	null	Temporal reference, e.g., "t+1", "t+1am".

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

Field	Type	Required	Default	Description
action	string	Yes	--	Action code. MUST match ^![A-Z][A-Z_]*$.
target	string (optional)	No	null	Target entity of the fallback action.
location	string (optional)	No	null	Location qualifier for the fallback.

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. Meta Fields

Field	Type	Required	Default	Description
req_id	string	Yes	--	Request identifier. MUST match ^[a-f0-9]{4,8}$. Default length: 8 hex chars (32 bits). 4 hex chars permitted only in scope-limited sessions.
session_id	string (optional)	No	null	2-character session identifier for stateful mode.
priority	integer	No	0	Priority level.
confidence	float	No	1.0	Confidence score in range [0.0, 1.0].
seq	array of string	No	[]	Sequence of action codes for multi-step tasks.
out	string	No	"natural"	Output format hint for the receiver.
next_agent	string (optional)	No	null	Routing hint for the next agent.

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%.

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 is: action-code = "!" 1*UPPER-LETTER *( "_" 1*UPPER-LETTER ) UPPER-LETTER = %x41-5A ; A-Z Lowercase function names in the code frontend are derived by removing the ! prefix and converting to lowercase: !CANCEL -> cancel.

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 . Approved Verb Whitelist (13 Verbs, All Single-Token Across 6 Tokenizers)

Action Code	Function Name	Single-Token (all 6)	UNK-Free (all 6)
!CANCEL	cancel	Yes	Yes
!START	start	Yes	Yes
!EMAIL	email	Yes	Yes
!FETCH	fetch	Yes	Yes
!PROCESS	process	Yes	Yes
!TRANSLATE	translate	Yes	Yes
!BOOK	book	Yes	Yes
!ROUTE	route	Yes	Yes
!SEARCH	search	Yes	Yes
!UPDATE	update	Yes	Yes
!SUGGEST	suggest	Yes	Yes
!SWITCH	switch	Yes	Yes
!NOTIFY	notify	Yes	Yes

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

Verb	Token Counts Across 6 Tokenizers	Reason	Suggested Replacement
!SWITCH_TOOL	gpt-4o: 2, gpt-3.5: 2, llama-2: 3, qwen2.5: 2, claude: 3, gemini: 3	Multi-token (2-3 tokens). Never single-token on any tested tokenizer.	!SWITCH
!ESCALATE	gpt-4o: 3, gpt-3.5: 2, llama-2: 3, qwen2.5: 2, claude: 3, gemini: 2	Multi-token (2-3 tokens). Sub-word fragment "ate" has spurious meaning (English verb "ate").	Use a single-token alternative

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. { "$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" } } } } }

Layer 2: Surface Layer (Pluggable Frontends) Five frontends compile IR to surface string. Two frontends (code and json) are lossless codecs satisfying decode(compile(ir)) == ir. Three frontends (natural, nl_json, llmlingua2) are control baselines that do not support decode. Surface Frontends

Frontend	Description	Round-trip
code	Function-call syntax	Yes (lossless)
json	Flat JSON slots	Yes (lossless)
natural	Unstructured prose	No (control)
nl_json	Natural language wrapped in JSON	No (control)
llmlingua2	LLMLingua-2 compressed natural language	No (lossy)

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 is: 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 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)

JSON Frontend The JSON frontend renders the IR as a flat JSON object 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_. { "intent": "!CANCEL", "act": "flight", "action_email": ["zhangsan"], "constraints": [ {"type": "loc", "value": "Beijing", "time": "t+1am", "subject": "me"} ] }

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."

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. {"task_description": "If not rain at t+1, start hike otherwise start cards at indoor."}

LLMLingua-2 Frontend The llmlingua2 frontend compresses the natural frontend's output using LLMLingua-2 (XLM-RoBERTa-large, rate=0.5) . LLMLingua-2 is the successor to 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.

Lossless Round-Trip Guarantee For the code and json frontends, the following invariant MUST hold for all valid IRs: decode(compile(ir)) is semantically equivalent to ir "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.

Layer 3: Meta-Protocol Layer The meta-protocol layer handles dynamic frontend negotiation, session management, error codes, and degradation chains. This section specifies the error code registry and session management parameters. Frontend negotiation via //ping probes is partially specified.

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. SILP Error Codes

Code	Description
invalid_syntax	The payload does not conform to the expected frontend syntax.
unsupported_version	The silp version field indicates a version not supported by the receiver.
unsupported_frontend	The requested frontend is not implemented by the receiver.
decode_failed	The receiver attempted to decode the payload but the decoding process failed.
timeout	The session or request exceeded its time limit.
session_expired	The session ID is no longer valid.

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).

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

Layers 4 and 5: Optimization and Migration (Future Work)

Layer 4: Optimization Layer Layer 4 defines a multi-objective fitness function for frontend selection and IR optimization. The fitness function is: Fitness = alpha * task_success + alpha_prime * cross_model_fidelity + beta * compression - gamma * human_unreadability - delta * PPL - epsilon * tokenizer_variance - zeta * cross_model_ambiguity Constrained by alpha + alpha_prime >= 0.6 and a hard fidelity floor. This layer is design-only and not yet experimentally validated.

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.

Relationship to Existing Agent Protocols SILP is designed as a payload-layer codec that complements existing agent protocols. It does not define its own transport mechanism, discovery protocol, or tool-calling interface. Instead, SILP-encoded strings can be embedded within the payload fields of multiple existing protocols without modifying their semantics. The following table summarizes the relationship: SILP Relationship to Existing Agent Protocols

Protocol	Problem Solved	Relationship to SILP
AIDIP	Agent discovery and invocation (metadata, search, RESTful invoke)	Complementary: SILP can encode the inputs and outputs fields of AIDIP invocations
A2A	Agent-to-agent task lifecycle, message transport, artifact exchange	Complementary: SILP can be embedded in A2A task, message, or artifact fields
MCP	Agent-to-tool invocation protocol	Complementary: SILP can encode the params field of MCP JSON-RPC requests

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.

MCP Integration In 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.

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

Security Considerations

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.

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

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.

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.

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.

IANA Considerations This document has no IANA actions. Future versions of this specification may request registration of:

• A SILP frontend name registry (e.g., code, json, natural, nl_json, llmlingua2).
• A SILP error code registry (see ).
• A SILP verb whitelist registry (see ).

Anthropic Google EMNLP 2023, pages 13358-13376 Proceedings of the 7th Linguistic Annotation Workshop, pages 178-186 Findings of ACL 2024. arXiv:2403.12968 Zenodo. DOI: 10.5281/zenodo.21396849 GitHub repository: Juwan-Hwang/polyglotir

IR Examples This appendix provides examples of SILP IR objects and their compilation under each frontend. All examples are drawn from the 27-case test suite described in the accompanying research paper .

Example 1: Negation Logic with Alternative { "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 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.

Example 2: Multi-Constraint with Secondary Action { "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 frontend output: if loc(me,Beijing,t+1am): cancel(flight,t+1pm); email(zhangsan)

Example 3: Keyword Arguments (Detail Preservation) { "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 frontend output: translate(src=fr_rev_bold, tgt=shakespeare_en, style=archaic_heavy)

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

Example 5: Parallel Actions with Sequencing fetch(data) -> process -> email(result) with timeout

Structural Token Verification The following 12 structural tokens are verified to be single-token on all 6 production tokenizers (gpt-4o, gpt-3.5, llama-2, qwen2.5, claude, gemini) with zero UNK occurrences. The complete census data is available in the reference implementation . Structural Tokens (All Single-Token, Zero UNK, Across 6 Tokenizers)

Token	Category
if	Conditional
else	Conditional
and	Logical
not	Logical
(	Delimiter
)	Delimiter
,	Delimiter
;	Delimiter
:	Delimiter
!	Negation prefix
@	Location qualifier
->	Sequencing

Acknowledgements The SILP protocol design was informed by empirical research documented in the accompanying research paper . The reference implementation is available as open source .