Build Instruction and Demonstration Data

Polished answers are not learning records

MD-10 produced reproducible synthetic partitions. It did not produce text that should be fed directly to a trainer. Chapter 6 opens MD-11 by converting train-eligible episodes into instruction and demonstration records whose behavioral purpose, evidence, rendering, and review are inspectable.

The managed baseline remains evaluation-only. The conditional open-weight candidate remains blocked on template and padding compatibility from Chapter 2. No trainer runs in this chapter. Rendering a record proves only that the data interface is internally consistent under a synthetic template fixture.

The goal is not to collect beautiful responses. It is to encode a diagnosed distinction: given an authorized task, structured input, and evidence state, which typed proposal or terminal state should the model be trained to produce, and which tokens should contribute to the supervised loss?

Map every example to a behavior clause

Instruction examples must map to target behavior clauses, errors, and segments rather than convenience prompts. [CLM-016] The claim is a task-specific synthesis from instruction-tuning and multilingual post-training evidence. Coverage improves the basis for an experiment; examples do not guarantee generalization or dependable behavior.

Mosaic uses four primary record objectives:

1. positive mapping: expand an approved shorthand into the correct typed field when authorized evidence supports it;
2. negative distinction: avoid a tempting but wrong mapping between similar appliance codes;
3. abstention: emit the explicit abstention state when required evidence is missing or stale;
4. escalation: preserve conflict and authority boundaries when sources disagree or a decision exceeds the proposal scope.

Each objective is crossed with Gujarati, English, and Gujarati-English slices; appliance families; short and long structured inputs; citation states; and the target/error taxonomy. The recipe never asks a language model to learn current policy facts that belong in retrieval.

LLME-CASE-007 makes multilingual coverage an explicit data and evaluation decision in one research project. It does not establish Mosaic’s language adequacy, translate regional authority, or justify aggregate-only reporting. LLME-CASE-008 shows a documented staged post-training process under its own models and data. Mosaic imports neither outcome.

Build a record with separable truth surfaces

The structured record contains:

• record, recipe, curation, split, family, and parent IDs;
• target behavior clause and diagnosed error category;
• trusted instruction and allowed operation;
• untrusted input fields and language/script metadata;
• authorized context envelopes with source IDs, revisions, spans, state, and permission;
• desired typed proposal or terminal state;
• claim-to-evidence links for every target assertion;
• prohibited effects and escalation rule;
• source origin, synthetic generation batch, transforms, author, and reviewer;
• slice tags and coverage contribution;
• tokenizer, template, render, and loss-mask identities;
• status, rejection reasons, and known limitations.

Keep desired output and evidence links separate. A target can be schema-valid yet unsupported. A source can be cited yet stale, unauthorized, or irrelevant. Deterministic validators should check structural and referential conditions before a domain reviewer judges correctness.

Long description

A crisp realistic three-dimensional record unfolds into layered cards: trusted instruction, untrusted input, authorized context, typed target, a highlighted assistant-only loss band, and provenance metadata. Evidence cords connect each target claim to a context span.

Validate targets against evidence, not fluency

The failure injection includes a synthetic answer that confidently adds a warranty duration absent from its authorized context. It is grammatically polished, typed correctly, and cites a real source ID. The claim-to-span validator finds no supporting span and returns reject-unsupported-synthetic-target.

Use layered checks:

1. parse and schema validation;
2. allowed terminal state and authority validation;
3. source existence, permission, revision, and state validation;
4. claim-to-source and claim-to-span referential validation;
5. deterministic field consistency and prohibited-effect checks;
6. author review against the task clause;
7. independent domain review of correctness and consequence;
8. privacy/legal review where the source or target requires it;
9. language review for meaning, not only surface fluency;
10. final acceptance with reason and version.

A validator can show that the target’s appliance_code matches an evidence field. It cannot decide whether the code implies a warranty decision or whether the underlying policy is legitimate. Those are domain and authority questions.

Synthetic origin remains visible after review. Acceptance means a named process found the example adequate for this recipe version. It does not convert generated text into human-origin evidence or population truth.

Render through the exact training template

Structured records must be rendered by the same compatible chat-template family expected by training and serving. Bind tokenizer revision, template digest, special-token map, role order, generation-prompt rule, truncation policy, and render-library version. Store a golden token-ID fixture for each record shape.

Chat template and loss masking determine which tokens contribute to SFT learning. [CLM-017] The Hugging Face chat-template and TRL trainer documentation describe current library surfaces. They are volatile and model-specific; they do not establish that a particular template, packing mode, or mask is correct for Mosaic.

For a conversational supervised record, inspect:

• beginning/end and role tokens;
• system/task text and untrusted-data delimiters;
• authorized context serialization;
• assistant prefix and target;
• padding and attention masks;
• label mask or ignored-token sentinel;
• truncation and packing boundaries;
• tool/schema tokens where allowed;
• decode round-trip and target extraction.

Mosaic’s intended fixture masks every instruction, input, and context token from the supervised target and exposes only the assistant proposal tokens to loss. That choice is not universal. Some training objectives include more tokens. The required point is to state and test the objective rather than inherit a trainer default.

Calculate and store mask statistics per rendered record: total tokens, supervised tokens, ignored tokens, target start/end, truncation state, and any padding. Reject an example with zero supervised tokens, a target clipped before its terminal marker, or supervised tokens outside the declared assistant region. Compare the extracted supervised token sequence with the structured target after decoding under the exact tokenizer.

Packing adds another boundary. If multiple records share one sequence, retain record offsets, end markers, attention behavior, and loss spans. Test that no target token from record A is interpreted as input for record B and that a long record cannot silently truncate the next target. If the training library cannot express the required boundary, disable packing or change the experiment; do not modify the contract to fit a throughput feature.

Failure injection: training and serving disagree

The first render uses template-family-a for training but the Chapter 2 serving candidate still names template-from-family-b. Even if both produce readable transcripts, special-token and role sequences differ. The rendering gate returns block-training-serving-template-mismatch.

The second render accidentally includes the assistant’s target within an input demonstration and also exposes those tokens to loss. The validator detects duplicate target placement. The third packs two examples without an end boundary, allowing one target to flow into the next prompt. The pack test fails.

Do not fix these failures by manually editing token arrays. Correct the structured template configuration, create a new digest, rerender the entire dataset, and rerun compatibility, evidence, and split checks. A render change creates a new instruction-dataset identity.

The compatibility blocker also protects the future adapter/base relationship. A dataset serialized for the wrong template could produce a valid checkpoint that only appears to work under the same accidental renderer. That would couple training and evaluation to a bug. Chapter 2’s tuple must clear before Chapter 9 can interpret any optimization.

Teach explicit non-answer behavior

Negative, abstention, and boundary cases are needed when the contract requires non-answer behavior. [CLM-018] NIST risk guidance and staged post-training practice support documenting risks, provenance, and evaluation, but they do not prove that a particular example set makes a model safe or controllable.

Mosaic includes:

• missing evidence leading to abstain;
• stale evidence leading to abstain or a bounded stale-state proposal according to the contract;
• conflicting authorized sources leading to escalate;
• unauthorized evidence excluded before rendering;
• a requested warranty approval leading to escalate-authority;
• malformed language codes rejected upstream rather than taught as model errors;
• valid shorthand near misses producing the correct alternative field or abstention;
• unsupported synthetic assertions rejected, not softened.

Avoid one negative template repeated hundreds of times. It can teach a superficial refusal phrase instead of the underlying boundary. Vary the relevant input while freezing the terminal-state semantics, then evaluate held-out families.

Build a coverage quilt, not a single count

Report coverage across behavior clause, error category, terminal state, language/script, appliance family, evidence state, consequence, input-length band, origin, and review status. Show unique families and effective examples after duplication controls, not only rows.

The quilt distinguishes:

• planned and accepted;
• planned but missing;
• accepted but concentrated in one family;
• synthetic-only;
• awaiting domain or language review;
• excluded from train but present in retention/control;
• prohibited or unavailable.

A gap remains a gap. Do not generate until every cell is colorful. Some cells may be impossible, unnecessary, unsafe, or outside scope. Product and domain owners decide which missing distinctions are valuable; data/privacy/legal authorities decide which can be constructed; the engineer reports the experimental consequence.

Coverage must also retain the curation denominator. If twenty rendered records descend from two source families, report both numbers. If reviewer rejection removes most Gujarati conflict cases, show the post-review gap rather than the recipe allocation. If one author supplies all negative examples, expose author concentration as a possible style shortcut.

Before freezing a dataset version, sample records from every populated high-consequence cell and every rejection class. Review the structured form, evidence, rendered tokens, mask, and lineage together. Aggregate coverage cannot reveal a target pasted into the wrong role or a citation pointing to the wrong revision.

Long description

A colorful tactile three-dimensional quilt has rows for behavior clauses and errors and columns for positive, negative, abstention, and multilingual families. Some patches contain reviewed record bundles; transparent outlined patches labeled gap remain empty.

Separate author, reviewer, and authority

The author constructs a target from the task clause and authorized evidence. An independent reviewer checks schema, provenance, and evidence links. A qualified domain reviewer judges correctness where required. A language reviewer checks preserved meaning. Privacy/legal and data owners decide allowable use and retention. Security reviews data handling and untrusted-content boundaries.

No reviewer should approve their own generated batch alone. Record disagreements rather than forcing consensus into one clean label. A rejected target retains a reason and permissible audit metadata but cannot reappear through regeneration without a new parent link and review.

The LLM engineer owns record schema, renderer, validators, sampling mechanics, version identity, and measured later behavior. They do not become the source owner, domain authority, privacy officer, legal counsel, or release approver.

Open MD-11 without training

mosaic-instruction-data.json contains four accepted synthetic demonstration types, one unsupported-target rejection, template and mask fixtures, author/reviewer provenance, and the first coverage report. It reads only train-eligible MD-10 family IDs. Evaluation, retention, and control target contents remain outside the authoring path.

The artifact status is md11-instruction-data-specified-render-blocked. The data semantics and evidence checks pass for accepted examples, but the training/serving template mismatch inherited from Chapter 2 blocks readiness. No adapter, checkpoint, optimizer, or quality outcome exists.

Keep the managed baseline outside the authoring loop

The managed baseline may later evaluate the frozen task contract under its exposed interface. It does not consume Mosaic’s training records, and its responses do not become automatic targets. If an authorized managed generator proposes synthetic candidates, Chapter 4’s source record and independent review apply. This avoids turning provider agreement into a circular correctness test.

The open-weight path carries the additional tokenizer, template, loss-mask, training, adapter, and serving obligations described here. Both paths still share the same proposal-only authority, authorized evidence, terminal states, protected evaluation, and release gates.

Chapters 7 and 8 will decide whether preference data are justified and build the full retention suite. They inherit the same source, split, template, evidence, author/reviewer, and authority boundaries. Preference pairs cannot repair unsupported targets, and retention examples cannot be copied into training merely because a target slice is sparse.

Practice: audit what the model would learn

Using the Chapter 6 companion:

1. trace every record to an MD-10 train family and behavior clause;
2. validate every target claim against an authorized source span;
3. reject the polished unsupported warranty assertion;
4. render accepted records with the declared tokenizer and template fixture;
5. inspect role tokens, target location, masks, boundaries, and truncation;
6. block the training/serving template mismatch;
7. reconcile accepted/rejected records with the coverage quilt;
8. name all domain, language, data, privacy/legal, security, and experimental handoffs.

Pass when targets are evidence-supported, non-answer behaviors are explicit, template rendering and loss regions reproduce, source/split lineage stays intact, and missing coverage remains visible. Fail when generated prose grades itself, citation presence substitutes for support, holdouts enter authoring, masked tokens are assumed from defaults, or a rendered dataset is described as a training outcome.