SFT annotation guidelines: how to brief demonstration writers

Why demonstration guidelines decide what your model learns

Supervised fine-tuning copies the style of its demonstrations, so inconsistencies in the writing brief become inconsistencies in model behavior. InstructGPT began with GPT-3 fine-tuned on labeler-written demonstrations before any reinforcement learning, and the labelers worked from written instructions [1]. LIMA showed that 1,000 carefully curated prompt-response pairs could produce a strong assistant from a 65B LLaMA base, while noting that this curation is labor-intensive [2]. AlpaGasus reached a similar conclusion from the other direction: filtering a large, noisy instruction set down to a smaller high-quality subset trained a better model [3].

The practical consequence is that your guideline is a training hyperparameter. If half your writers open with "Great question" and half do not, the model learns a coin flip. If some writers hedge every medical answer and others do not, you have trained inconsistent risk behavior that no later preference stage fully removes.

Guidelines are separate from the question of where demonstrations come from. For sourcing models, vendor structures and expert pools, see expert demonstration data for SFT and how to source supervised fine-tuning data. This page covers the document writers actually read.

The six sections every SFT writing guideline needs

A complete guideline has six rule sections: task scope, voice and tone, length, format, safety and citations. Each rule should be testable by a reviewer reading one response, not a matter of taste.

1. Task scope. List the prompt categories in scope (for example: customer-support resolution, SQL generation, contract clause summarization) and the ones that are explicitly out. State the persona the model plays and what it can assume about the user. Say what to do with an ambiguous prompt: ask one clarifying question, or answer the most likely reading and state the assumption.

2. Voice and tone. Specify person (second person to the user), register, and banned patterns such as sycophantic openers, apologies without cause, restating the question, and closing offers of further help. Give the rule for uncertainty: name what is unknown once, in the sentence where it matters.

3. Length. Set targets by prompt type rather than one global range. A factual lookup might get one to three sentences; a debugging walkthrough might run several hundred words. Tell writers that padding is a defect, because models trained on padded answers learn verbosity.

4. Format. Define when to use Markdown headings, bullets, tables and fenced code blocks, and when plain prose is required. If outputs will be parsed, specify the exact schema and see structured-output fine-tuning data for JSON field-extraction pairs.

5. Safety behavior. Define refuse, partially comply and comply-with-care, with the policy categories that trigger each. Bianchi et al. found that adding a modest number of safety demonstrations improved safety, while too many produced exaggerated refusals of benign prompts [4]. Your guideline therefore needs examples of borderline prompts that should be answered, not only of prompts that should be refused.

6. Citations and grounding. For retrieval-augmented tasks, state whether claims must cite a provided passage, how to mark the citation, and what to do when the passage does not contain the answer. Forbid fabricated URLs, case names and statistics, and tell writers to say "the provided documents do not cover this" rather than fill gaps from memory.

Paired good and bad examples for each rule

Every rule should carry at least one paired example: the same prompt answered correctly and incorrectly, with a one-line reason. Writers tend to generalize from examples more reliably than from prose rules, and the bad example names the failure mode reviewers will flag.

Illustrative example: invented to show structure; it does not describe an available dataset.

Keep the rule IDs stable across versions. Reviewers then tag defects by ID ("T-02, L-01"), which turns review comments into countable data about which rules are failing.

Format and record schema: what writers deliver

Writers should deliver records in the exact role-tagged structure your trainer consumes, with metadata fields that make every example auditable. Managed tuning services such as Vertex AI take JSONL files where each line holds a conversation of role-tagged turns [5], and function-calling formats add a tools field plus structured tool calls in assistant turns [6]. Training libraries also expect the record to match the model's chat template, whether you store instruction-input-output (Alpaca-style) or role-based messages [7].

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "id": "sft-000418",
  "guideline_version": "2.3.0",
  "task_category": "support_resolution",
  "writer_id": "w-117",
  "reviewer_id": "r-009",
  "review_status": "accepted",
  "rule_flags": [],
  "source_ref": "ticket-redacted-88213",
  "messages": [
    {"role": "system", "content": "You are a support assistant for a billing product."},
    {"role": "user", "content": "I was charged twice for March. How do I get one refunded?"},
    {"role": "assistant", "content": "A duplicate March charge usually means..."}
  ],
  "created_at": "2026-10-02T14:11:00Z"
}

The guideline_version, rule_flags and source_ref fields are the ones teams most often omit and most often need later. Without them you cannot retrain on only post-fix data, exclude a batch written under a superseded safety rule, or trace a prompt back to its origin. Prompts drawn from real records follow the conventions in turning business records into instruction-response pairs.

Calibration rounds before production

Run at least two calibration rounds in which every writer answers the same small prompt set and reviewers score the results against the rubric before any production batch starts. Calibration finds ambiguous rules while they are cheap to fix.

A workable pattern: give 20 to 40 shared prompts that cover every rule section and every task category. Have two or more reviewers score each response on a rubric with discrete levels per dimension (correctness, instruction following, tone, length, format, safety, grounding). Measure reviewer agreement with a chance-corrected statistic such as Cohen's kappa for two raters or Krippendorff's alpha for several raters and ordinal scales [8].

Low agreement on a dimension usually means the rule is underspecified, not that reviewers are careless. Rewrite the rule, add a paired example, bump the guideline version and rerun the affected prompts. Writers who pass calibration go to production; those who do not get targeted feedback on the rule IDs they missed.

Illustrative example: invented to show structure; it does not describe an available dataset.

Calibration and production checklist

• Shared calibration set covers every task category and all six rule sections
• Rubric has discrete levels and an anchor example for each level
• Agreement computed per dimension, not only overall
• Every low-agreement dimension traced to a specific rule ID and rewritten
• Guideline version bumped and change log entry written for each rewrite
• Gold set of pre-scored responses seeded into production queues for drift checks
• Reviewer second-pass rate and defect rate by rule ID tracked weekly
• Spot audit of accepted records by someone outside the writing team

For acceptance testing once data arrives, the methods in auditing annotation quality before you accept it apply directly to SFT batches.

Versioning guidelines and handling change

Treat the guideline like code: semantic version numbers, a change log and the version stamped on every record. Guidelines always change once real prompts arrive, and unversioned changes silently mix two behaviors in one training set.

Use a major version for changes that alter correct behavior (a new refusal policy, a different citation format), a minor version for new rules or examples, and a patch for wording fixes. When a major change lands, decide explicitly whether older records are rewritten, relabeled or excluded, and record that decision. Datasheets for Datasets recommends documenting how labeling was done and what the data is intended for [9]; ship the guideline version history and the rubric with the dataset so a later team can interpret it. ISO/IEC 5259-1 gives shared terminology for describing data quality across the life cycle if your organization reports against it [10].

Common failure modes in SFT writing programs

Most SFT quality problems trace to a short list of guideline gaps. The ones post-training teams hit repeatedly are:

• Template collapse. Writers converge on one skeleton (summary, bullets, closing line) for every prompt, and the model loses range. Fix with format rules tied to prompt type and paired examples of prose answers.
• Model-assisted drafting without disclosure. Writers paste model output and edit lightly, which imports the source model's style and errors. State whether assistance is allowed, require disclosure in a record field and check for it in review. See reasoning trace datasets for the human-written versus model-generated trade-off.
• Over-refusal drift. Cautious writers refuse borderline prompts, and the model learns exaggerated safety [4]. Seed borderline prompts with gold answers.
• Length inflation. Reviewers reward thoroughness, so answers grow every week. Track median length per task category against the guideline target.
• Ungrounded specifics. Writers add plausible statistics or citations from memory. Make "no unsupported specifics" a blocking rule with its own ID.
• Privacy leakage from real prompts. When prompts come from tickets or emails, names, account numbers and phone numbers flow into responses. Require de-identified source text and a rule against copying identifiers.

Where licensed operational data fits

Guidelines govern how responses are written, but the prompts and reference material often need to come from real work to make demonstrations representative. Support and sales histories, engineering records, documents, and finance and legal workflows are common sources of realistic prompts and grounding passages.

SourceX sources operational datasets of these kinds from US companies on request and manages the licensing process; nothing is held in stock, and a request does not guarantee a match. Each dataset is rights-reviewed for ownership and consents, personal details such as names, emails, phones and account numbers are removed or replaced before delivery with the method recorded and a sample checked, and no method is perfect. You can describe the source data your writers need at SourceX for AI data buyers. For budgeting the writing work itself, see what drives the cost of human preference and SFT data, and for the wider category map, the fine-tuning and post-training data hub. The general term is defined in the data annotation glossary entry.

Source data for SFT demonstration programs

SourceX sources operational datasets from US companies, such as support histories, engineering records and documents, on request, and manages licensing from assessment through agreement and ongoing purchases. Every release is approved by the supplying company and delivered under a license that defines records, uses, term and delivery. Describe the data your demonstration writers need at SourceX for AI data buyers.