Textual Large Language Models (LLMs) provide a simple and familiar interface: a string of text is used for both input and output. However, the information conveyed to an LLM often has a richer structure and semantics, which is not conveyed in a string. For example, most prompts contain both instructions ("Summarize this paper into a paragraph") and data (the paper to summarize), but these are usually not distinguished when passed to the model. This can lead to model confusion and security risks, such as prompt injection attacks. This work addresses this shortcoming by introducing an LLM-native mark-up language, LLMON (LLM Object Notation, pronounced "Lemon"), that enables the structure and semantic metadata of the text to be communicated in a natural way to an LLM. This information can then be used during model training, model prompting, and inference implementation, leading to improvements in model accuracy, safety, and security. This is analogous to how programming language types can be used for many purposes, such as static checking, code generation, dynamic checking, and IDE highlighting. We discuss the general design requirements of an LLM-native markup language, introduce the LLMON markup language and show how it meets these design requirements, describe how the information contained in a LLMON artifact can benefit model training and inference implementation, and provide some preliminary empirical evidence of its value for both of these use cases. We also discuss broader issues and research opportunities that are enabled with an LLM-native approach.
Figures & tables
Attribute
LLMs
Programmed Systems
Instruction/Data Separation
No
Yes, supported by high-level languages and operating systems
Referential Structure
No
Yes, parameters, variables, etc.
Execution Control
No
Yes, semantics of execution are well defined
Program Portability
No
Yes, via compilers or lang VMs
Deterministic Execution
No
Yes, in most cases
Nonlinear data flow
No
Yes, intermediate assignments to unrelated variables are independent
Table 1: Comparison Between Programming via Prompts with LLMs and Traditional Programming
Design Requirement
LLMON Approach
1. User-defined Tags
supported with \tagname\text /tagname/
2. Anchors for Instances
supported with “:” special token
3. Explicit Nesting Names
supported with “.” special token
4. Prefix
uses prefix-style tags
5. Convertibility
have converters between JSON and LLMON
6. No Escaping
LLMON does not use any escaping
Table 2: LLMON Design Decisions
LLMON:
LLMON_ITEM LLMON_LIST
LLMON_LIST:
LLMON_ITEM LLMON_LIST
| ϵ
LLMON_ITEM:
USER_TYPE | | OBJECT | LIST
| integer | float | string
Figure 5: LLMON Grammar. terms in UPPER_CASE are nonterminals. terms in single quotes or lowercase are terminals. The table provides current values for the nonquoted terminals. “ user_tag_text ” represents a typical identifier extended to include “ : ” and “ . ” as illustrated in examples in Section 3.1 . “ object ”, “ item ”, and “ list ” are exactly those strings.
LLMON Special Tokens
<|open|>
<|open_end|>
<|close|>
<|self_close|>
<|.|>
<|:|>
Table 3: LLMON Special Tokens and Syntax Mapping from Shorthand
Terminal
String
start_user_tag
<|open|> user_tag_text <|close|>
end_user_tag
<|open_end|> user_tag_text <|close|>
self_close_user_tag
<|open|> user_tag_text <|self_close|>
start_object_tag
<|open|>object<|close|>
end_object_tag
<|open_end|>object<|close|>
start_object_item_tag
<|open|>item<|close|>
Figure 6: Current values for the nonquoted terminals from Figure 5 expressed in LLMON. “ user_tag_text ” is the same as in Figure 5 . It can be any identifier and can include “ : ” and “ . ” as illustrated in examples in Section 3.1 . “ object ”, “ item ”, and “ list ” are exactly those strings.
Figure 9: Workflow from Shorthand syntax to the token sequence used during model post-training and inference. A structured artifact written in Shorthand syntax is converted into LLMON, where structural delimiters are represented using special tokens (shown in red). The tokenizer then maps the sequence into token identifiers, preserving structural boundaries in the token stream. Blue and black tokens represent ordinary text tokens produced by the tokenizer; alternating colors are used only to visually distinguish adjacent tokens and illustrate token boundaries as seen by the tokenizer. This tokenized representation can be used directly for model post-training and inference procedures.
Model
Tokens
MMLU
GSM8K
IFEval
Distractor
Base (no post-training)
Granite-4.0-Micro-Base
–
61.52
0.00
38.78
4.40
Qwen-2.5-3B
–
65.09
0.15
27.13
27.80
Full fine-tuning baseline (post-training with chat-template data)
Granite-4.0-Micro-Base
2.9B
39.95
0.61
72.07
0.00
Qwen-2.5-3B
2.9B
48.51
1.13
74.05
0.40
Table 4: Comparison of base models, conventional post-training baselines (chat-template instruction tuning), and LLMON-structured post-training. MMLU, GSM8K, and IFEval are reported in zero-shot accuracy, and “Distractor” denotes accuracy on our structured multi-instruction Distractor benchmark. Token counts indicate the amount of post-training data used.
Model
Method
Distractor
Qwen2.5-3B-Instruct
baseline
43.20
constraint mask with LLMON
69.00
Granite-3.3-8B-Instruct
baseline
41.60
constraint mask with LLMON
72.00
Granite-4.0-Micro
baseline
40.80
constraint mask with LLMON
72.40
Table 5: Comparison of models applying constraint masking with LLMON at inference on multi-instruction Distractor benchmark.
Structured prompting organizes instructions, context, reasoning steps, or output schemas to make language-model behavior more reliable and controllable.
Autonomous systems increasingly rely on Large Language Models (LLMs) yet the safety infrastructure surrounding these models introduces latency and compute overhead. This limits utility in resource-constrained, time-critical deployments. Existing external guardrail models remain blind to the model's internal workings, creating a fundamental assurance gap. We ask: does the model already know when the content is harmful? We extract activations from LLaMA-3.1-8B and train lightweight MLP classifier probes (12.6M parameters) to detect harmful prompts. Evaluated on WildJailbreak, Beavertails, and AEGIS 2.0, our probes achieve F1 scores of 99%, 83%, and 84%, respectively competitive with 1000x larger guard models while cutting latency and compute costs.
As large language models (LLMs) transition from research prototypes to real-world systems, customization has emerged as a central bottleneck. While text prompts can already customize LLM behavior, we argue that text-only prompting does not constitute a suitable control interface for scalable, stable, and inference-only customization. This position paper argues that model providers should expose vector prompt inputs as part of the public interface for customizing LLMs. We support this position with diagnostic evidence showing that vector prompt tuning continues to improve with increasing supervision whereas text-based prompt optimization saturates early, and that vector prompts exhibit dense, global attention patterns indicative of a distinct control mechanism. We further discuss why inference-only customization is increasingly important under realistic deployment constraints, and why exposing vector prompts need not fundamentally increase model leakage risk under a standard black-box threat model. We conclude with a call to action for the community to rethink prompt interfaces as a core component of LLM customization.
Liangwei Yang, Shiyu Wang, Haolin Chen +12
Salesforce AI Research, Palo Alto, CA, United States.
Large language models (LLMs) receive each user message as plain text, even when it combines text from different sources. For example, a user may paste text into a prompt and keep typing a comment directly below it. We study absorption: a phenomenon where the model treats a trailing user comment as part of the pasted text, returning it inside the edited text. This happens even though the user did not intend the comment to become part of that text. Existing instruction-data separation benchmarks tell the model which text is instruction and which is data, then test whether it obeys that separation. They do not test harmless user speech following an unmarked paste. We introduce SEAM, a controlled benchmark of 300 editing examples. Each example is tested under six matched conditions that vary how the boundary between pasted text and later user speech is expressed. Across 20 models, absorption at a bare newline ranges from 7.7% to 66.7%. Adding a blank line does not significantly reduce absorption in any model, while boundary markers reduce it in 19 of 20 models. Comments that fit the pasted text, such as a code comment typed after code, are absorbed significantly more often in 17 of 20 models. Models often fail to separate pasted material from later user speech, and explicit boundaries reduce but do not remove this failure.