Composing LLMON prompts made easy.

What LLMON is

Most chat APIs present a conversation as ordinary user and assistant messages. LLMON goes further: it represents instructions, data, requirements, documents, tools, tool results, and execution bindings as explicit blocks.

Some models are trained specifically on this representation. Granite 4.1 LLMON is one of them. For that checkpoint, conventional chat formatting is out of distribution; the model expects the structured LLMON form produced by its tokenizer and chat template.

<|open|>instr<|:|>ID<|close|>instruction<|open_end|>
<|open|>doc<|:|>ID<|close|>
  <|open|>doc<|.|>title<|close|>Project Brief<|open_end|>
  <|open|>doc<|.|>text<|close|>...<|open_end|>
<|open|>exec<|:|>ID<|close|>
  ...execution bindings...
<|open_end|>

The exact tags and two-character block IDs are part of the model-facing protocol. LLMON separates what the model should do from material it should read.

Compose it in Java

Instead of assembling that markup manually, use LlmOnPrompt. This example comes from the document-grounding scenario used by the Granite integration test:

String prompt = LlmOnPrompt.builder()
    .user(LlmOnPrompt.UserMessage.builder()
        .content("Extract the launch date and owner from the attached project brief.")
        .document(new LlmOnPrompt.Document(
            "Project Aurora launches on 2027-03-15. "
                + "The launch owner is Priya Shah.",
            "Project Aurora Brief"))
        .requirement("Return exactly two fields: launch_date and owner.")
        .build())
          .build()
    .render();

Those IDs are generated by the renderer; callers do not need to manage them. The model sees the same structured relationship that the Java builder expresses.

What the builder does

• Instruction: marks the authoritative task the model should perform.
• Document: supplies titled reference material as context rather than as a command.
• Requirement: constrains the requested answer shape or output contract.
• Execution: creates bindings that distinguish instructions from inputs.

The renderer assigns valid IDs, creates execution pointers, and can also represent tools, assistant tool calls, and tool results. The resulting string is sent through Reckoning’s existing raw completion path; no separate LLMON server API is required.

Learn more

Read the LLMON language paper for the format design, the reference repository for renderer examples, and the IBM Granite explainer for model-specific context.