A typical SFT chat example in a JSONL file is one JSON object per line with a single key called , whose value is an array of objects. Each object in that array has exactly two fields: (one of system / user / assistant) and (the actual text content of that turn).
**The standard SFT chat JSONL** is a small, well-defined shape that has become the default across the modern ecosystem. Each line of the file is one JSON object. That object has a single top-level key called `messages`. The value of `messages` is an array of message objects.
Each message object has exactly two fields:
- `role`: one of `system`, `user`, or `assistant` (with optional `tool` for tool-calling templates).
- `content`: the actual text of that turn.
A single training example might look like:
```
{"messages": [
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "What is the capital of France?"},
{"role": "assistant", "content": "Paris."}
]}
```
The JSONL file is just many such lines concatenated, one example per line.
The trainer reads this shape directly. It uses the `role` field to know which tokens belong to which speaker, applies the model's chat template to insert the right role markers, and masks the loss so only assistant tokens contribute. There is no need for a separate `prompt` / `completion` split; the role tags carry all the structure the trainer needs.
**The standard SFT chat JSONL** uses three field names: `messages` (the array), `role` (the speaker), and `content` (the text). One JSON object per line. The shape is borrowed directly from the OpenAI chat-completions API and has been adopted by essentially every modern training stack: TRL's `SFTTrainer`, Axolotl, LLaMA-Factory, Mistral's fine-tuning endpoint, OpenAI's, Anthropic's.
**The structure of a single line:**
```
{"messages": [
{"role": "system", "content": "You are a helpful coding assistant."},
{"role": "user", "content": "Write a Python function to reverse a list."},
{"role": "assistant", "content": "def reverse_list(lst):\n return lst[::-1]"}
]}
```
**Three things to note:**
1. `messages` is an array because a conversation is a sequence of turns; even single-turn examples wrap their two messages in this list.
2. `role` values are `system`, `user`, or `assistant` (plus `tool` if the template supports tool calls). The trainer uses these to apply the chat template and compute prompt loss masking.
3. `content` is plain text by default. Some templates support multimodal content (images, code blocks with metadata) by allowing `content` to be a list of structured blocks instead of a string.
**No separate prompt/completion split needed.** The role tags tell the trainer which tokens are assistant tokens (and therefore contribute to the loss) and which are user or system tokens (conditioned on but masked). This is cleaner than the old GPT-3-style `{prompt, completion}` format because it naturally extends to multi-turn conversations and tool calls without adding new top-level fields.
**Loaders auto-detect the shape.** TRL's `SFTTrainer` with `dataset_text_field=None` will look for the `messages` key by default. Axolotl's `chat_template` config triggers the same. The shape is the lingua franca; once your data is in this form it slots into any modern stack.
Quick reference
TL;DR
Top-level key is `messages` (an array). Each message has `role` (system/user/assistant) and `content` (the text). One JSON object per JSONL line.
Imagine a script for a short scene. Each line of the script names the speaker and then their dialogue. That is exactly what an SFT chat example looks like on disk, a list of small speaker and line entries. The whole list is wrapped under one heading called messages because a conversation is a sequence of messages. Each message inside carries two fields, who is talking (role) and what they are saying (content). The trainer reads through the script and uses the speaker labels to figure out which lines it should grade the model on, the assistant lines, and which lines are just context.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Your trainer expects the legacy GPT-3-style prompt and completion format for backward compatibility Older training stacks (and some fine-tuning APIs) still use the flat prompt and completion shape; check the loader's expected schema before converting.
Your data is single-turn completion with no system message or multi-turn context The chat format works but adds overhead; for pure completion tasks a flat prompt and completion JSONL is simpler to author and read.
Your task is not language-shaped at all (e.g. pure classification with categorical labels) The chat-format shape is built around conversational text; classification tasks usually use a different schema or are forced into chat format awkwardly.
Quick scan · 2–4 min
Everything important, quickly.
5 min: the three fields (messages, role, content) + JSONL one line per example + why no prompt/completion split + role tags drive masking + how loaders consume the shape + Anthropic vs OpenAI variants.
Side-by-side
Field
Position
Purpose
messages
Top-level key
Wraps the array of conversation turns
role
Inside each message
Identifies the speaker (system/user/assistant/tool)
content
Inside each message
The actual text of that turn
Real-world examples
Real products, models, and research that use this idea.
1OpenAI fine-tuning endpoint accepts exactly the `{messages: [{role, content}, ...]}` shape, one example per line in a JSONL file.
2Hugging Face TRL SFTTrainer auto-detects this shape and applies the model's chat template for prompt masking.
3Axolotl's chat_template config option triggers the same JSONL parsing across Llama, Mistral, Qwen, and DeepSeek base models.
4Mistral's fine-tuning API uses this format directly; their docs show the same three-field structure.
5ShareGPT and Alpaca datasets are routinely converted to this format before training; community tooling does the conversion in a few lines.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does the trainer not need a separate prompt and completion split when consuming this format?
Sign in or go Pro to see the approach for this follow-up.
QHow does Anthropic's chat format differ from this OpenAI-compatible shape?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens if a conversation contains a tool call?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Trying to add a separate `prompt` and `completion` split next to the messages array. The trainer derives which spans to grade from the role tags; no extra split is needed.