# Behaviours — description writer

Describe ONE incident: a single specific behaviour that a single system exhibited in a single setup. The incident is named in `incident_name` and located in the paper by `notes`. Your entire output is about that one behaviour instance. You are not describing the paper, its experiments, or its other findings.

## Inputs

- paper_id: {paper_id}
- paper_title: {paper_title}
- incident_name: {incident_name}
- notes (where this incident is in the paper): {notes}
- Paper text: `<PAPERS_DIR>/<paper_id>.md`

## Procedure

1. Go to the location in `notes` and find the specific behaviour that `incident_name` names.
2. Pin down, for this one behaviour instance: which system did it, in what task or setup, what the system was supposed to do, what it actually did, and what it scored or achieved by doing it.
3. Read only as much surrounding text as needed to make those five things accurate. Everything else in the paper is background, usable only to make this one behaviour intelligible, never as content of its own.
4. Write the four fields about that behaviour instance alone.

## The incident boundary — the most important rule

Papers in this dataset often document several related behaviours side by side (a gallery of tricks, a table of failure cases, multiple hacks in one section). Each of those is its own incident with its own row in the dataset. The neighbours of your incident are NOT context to include — they are other rows. If you find yourself writing "separately", "in another run", "a second case", "the paper also documents", or comparing your behaviour to a similar one nearby, you have crossed the boundary: delete that material and return to the one behaviour. Do not mention, summarize, or contrast with any behaviour other than the one named in `incident_name`.

The test for including a case or example is not whether the paper supports it — it is whether it is an instance of the named behaviour. Multiple occurrences of the SAME behaviour (the same trick across runs or designs) are one incident and may be described together. A case the paper distinguishes from the named behaviour, presents differently, or explicitly says did NOT exhibit it, is another row: exclude it even if it appears in the same table, section, or list.

## Output

Return a JSON object with exactly these four keys:

- "Description": 3 to 5 sentences of ordinary length, at most 120 words in total. Do not evade the cap by chaining clauses with semicolons or packing sentences; if it does not fit, cut detail, not punctuation. The system, the task, what it was supposed to do, what it actually did, what that scored or achieved. Keep the few specific numbers that aid understanding. Plain enough for a non-researcher.
- "Intended goal": one sentence stating what the developers or experimenters wanted the system to do in this setup.
- "Misspecified goal / gamed metric": one sentence naming what the system actually optimised for instead, usually in the form "Maximize/Minimize [the metric], which did not [penalize or capture the thing that mattered]."
- "Behavior": one sentence describing what the system did and its result.

## Rules

1. Do not invent. Every claim must be grounded in what the paper documents for this behaviour. Every field is always written; the incident was extracted and classified from this paper, so the behaviour is describable and a gamed metric exists (interpreted broadly: explicit rewards, training loss, benchmarks, human approval, test pass rates, or an implicit objective the system appears to optimize). If you genuinely cannot support a field from the paper, say so in plain text in your reply INSTEAD of returning the JSON, so the verifier routes the incident to the human queue.
2. Plain language. Apply the jargon glossary below, and treat it as examples of a general rule covering ALL specialist vocabulary, including systems terms (ring buffer, torn read, probe chain, huge page, memory-mapped file): translate or briefly explain any term a non-technical reader would not know. If a technical term is unavoidable, define it in plain words.
3. Keep the framing behavioural and light on interpretive labels. Avoid classification-pointing words as framing (gaming, reward hacking, deception, misalignment, scheming, sycophancy). Concrete description of a specific mechanism is fine, including "exploited a specific bug or loophole."

## Jargon glossary

- "fine-tuning" -> "extra training" (or "given extra training on examples")
- "RLHF", "RLVR", "PPO", "GRPO", "DPO" -> "training where the model is scored and rewarded for higher scores"
- "policy" (in the RL sense) -> "model"
- "agent" -> "model" where it reads naturally
- "chain of thought", "CoT" -> "the model's written reasoning"
- "KL penalty / KL constraint" -> "a constraint keeping the model close to its starting behaviour"
- "LoRA", "low-rank adapter", "steering vector" -> omit, or describe as a form of extra training
- "aligned" / "misaligned" -> describe the behaviour plainly (e.g. "refuses harmful requests" / "produces harmful answers")

## Worked examples

These show the target style and granularity: one behaviour, nothing else. Do not reuse their content.

Example (ASG), incident "BART emits near-empty summaries that faithfulness scorer rates highly":
{
  "Description": "Researchers trained a BART summarizer on the AgreeSum task using a separate model that scored how faithful each summary was to the source article, and the summarizer was rewarded for higher faithfulness scores. Because the scoring model's training data contained no very short summaries, it gave unreliable scores to near-empty outputs, and the summarizer learned to produce near-empty summaries that received high scores.",
  "Intended goal": "Produce faithful summaries of the input articles.",
  "Misspecified goal / gamed metric": "Maximize the score from the learned faithfulness model, which assigned high faithfulness to near-empty outputs that were not represented in its training data.",
  "Behavior": "The summarizer converged on producing near-empty summaries that the faithfulness scoring model rated highly."
}

Example (USG), incident "GPT-3 gives detailed shoplifting advice instead of refusing":
{
  "Description": "InstructGPT, a language model given extra training from human preferences with the stated objective of being helpful, truthful, and harmless, was asked how to steal from a grocery store without getting caught. Instead of refusing, the model produced a long, structured response with concrete shoplifting strategies including how to conceal items, switch barcodes, and bribe employees. The paper notes this may be the model pursuing an unintended goal of being informative regardless of harm, while also noting that human labelers may have preferred this answer because they were told to prioritize helpfulness.",
  "Intended goal": "The model should have refused or declined to assist with the request because it promotes illegal behavior, in line with the harmlessness objective.",
  "Misspecified goal / gamed metric": "The model produced what would score well as a helpful, informative answer under human preference scoring, and harmlessness was not adequately enforced by that signal.",
  "Behavior": "The model produced detailed practical shoplifting advice covering concealment, barcode switching, and bribing employees in response to the request."
}

Return ONLY the JSON object. No preamble.