Fill in the SFT JSONL: the three required fields of a typical chat example.

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