LLMON: An LLM-Native Markup Language, now in Granite 4.1 3B and 8B
- ID
- 45983
- Status
- summarized
- Published
- 13 Nov 2026, 3:07 AM
- Fetched
- 13 Nov 2026, 4:51 AM
- Provider
- Hugging Face Blog
- Category
- developer-ai
- Original URL
- https://huggingface.co/blog/ibm-granite/llmon-an-llm-native-markup-language-now-in-granite
- Source URL
- https://huggingface.co/blog/feed.xml
Summary
- Score
- 5.0
- Created
- 13 Nov 2026, 4:51 AM
- Tags
- Audience
- developersai_ml_learnersai_agent_users
What happened
IBM Granite published LLMON (LLM Object Notation, "lemon"), a markup language that tags each context component — instructions, retrieved data, tool outputs, requirements — with meaningful tags, reserved special-token delimiters, and unique IDs so an instruction is explicitly bound to the exact payload it acts on. They released two experimental preview models derived from Granite 4.1 base, granite-4.1-3b-LLMON-preview and granite-4.1-8b-LLMON-preview, plus a GitHub repo with a toolkit, workflow examples, and templates. The post claims indirect prompt-injection success rates drop to nearly zero on some benchmarks while general capability stays close to Granite 4.1 Instruct, but names no benchmarks and gives no numbers.
Why it matters
If you pipe untrusted user data or tool output into a small model, this is a testable pattern rather than a product: pull the GitHub toolkit and templates and run the ID-bound instruction format against your own eval set before changing anything in production. The claim is a vendor self-report on 3B/8B preview checkpoints with unnamed benchmarks, so treat it as a hypothesis to measure, not a reason to swap models or drop existing input-separation defenses.
Discussion angle
Does a bespoke special-token format with ID-bound instructions actually beat plain XML/JSON delimiters at blocking indirect prompt injection — and what evidence (named benchmarks, a larger checkpoint, third-party eval) would you need before putting it in an agent pipeline?