# Support-to-training-data playbook

**FusionCX Library** · Playbook · Last reviewed 3 September 2026  
How to design consent language, schema and review so support output is usable for training. Pair with `fusioncx-evaluation-record-schema.json` and `fusioncx-rlhf-record-schema.json`.

The loop: ticket → evaluation record → preference pair → starter kit → regression scenario → fewer tickets. Evaluation records from day 10. RLHF records from week 3, once selection criteria and rubric are agreed.

---

## 1. Decide what “usable” means

A support transcript is not a training record. A usable record has:

1. The customer's original prompt and stated objective.
2. The failing platform output or automated diagnosis.
3. The engineer's diagnosis, remediation and working result.
4. A preference or quality rating against your rubric.
5. Where a corrected output exists, a rejected / preferred pair.
6. Redaction complete under your guidelines.
7. Consent for this use, with opt-outs excluded.
8. A second-annotator sample and an acceptance decision.

If any of 6–8 fail, the ticket can still close. It must not enter the training store.

---

## 2. Consent language (your terms, not ours)

You are responsible for the lawful basis. We are responsible for applying your rules.

**Design checks**

- [ ] Training use is described in language a customer can find (terms, in-product notice, or both).
- [ ] The use is specific: model evaluation, fine-tuning, safety testing — not “improve our services”.
- [ ] Opt-out is possible without losing support.
- [ ] Support tooling can flag consent and opt-out on the ticket before close.
- [ ] Tickets without consent, or with opt-out, are excluded from RLHF selection automatically.
- [ ] Enterprise contracts that forbid training use are mapped to a hard exclude.

**Copy you can adapt (counsel must review)**

> We may use prompts, product outputs and the resolution of your support requests to evaluate and improve the models that generate those outputs. We remove personal data, credentials and identifiers first. You can opt out of this use without affecting the support you receive. We do not use this material to train models for other customers.

Do not put FusionCX in the customer terms. Ownership vests in you on creation; we never train our own systems on it.

---

## 3. Schema

Start from the evaluation schema (every ticket, included with Support) and the RLHF schema (designated tickets, per accepted record).

**Evaluation (at ticket close)**

- diagnosis_class: confirmed | partially_correct | incorrect
- reason_code + correct_diagnosis when not confirmed
- output_met_objective and objective_scale (1–5)
- capabilities_used, attempts
- customer_verbatim + verbatim_taxonomy
- defect_repro_steps when a defect was observed
- consent_for_evaluation

**RLHF (within 2 business days of closure)**

- prompt, stated_objective
- rejected_output, preferred_output
- rubric scores and preference
- engineer_remediation
- redaction checklist + span count
- second_annotator + acceptance

Schema changes: 15 days' notice. Formats: JSONL, CSV, or direct submission to your evaluation tooling.

**Selection criteria (you set these)**

| Include when | Default starting point |
|---|---|
| Diagnosis not confirmed | Yes — highest training value |
| Recurring error-register pattern | Yes, once frequency ≥ [n] / 90 days |
| P1 / security | Separate safety pipeline; not the general RLHF store |
| Customer opted out | Never |
| No corrected output | Evaluation only; no pair |

---

## 4. Rubric

Without a rubric the pair is an anecdote. Score both outputs on the same scale.

| Score | Meaning (adapt) |
|---|---|
| 1 | Does not address the objective; unsafe or destructive |
| 2 | Partial diagnosis or instructions that would not have worked |
| 3 | Plausible and incomplete; engineer still required |
| 4 | Would have worked with a small correction |
| 5 | Meets the objective; verified in tooling |

Pass the same labelled sample to FusionCX annotators and to your team. Inter-annotator agreement target: 0.8 κ (set in the SOW). Monthly calibration.

---

## 5. Redaction

Apply before the record leaves the helpdesk boundary.

| Remove or pseudonymise | Example |
|---|---|
| Personal data | Names, emails, phones |
| Credentials | Passwords, session tokens |
| API keys and secrets | Tokens, connection strings, private keys |
| End-user data | Your customer's users |
| Customer identifiers | Domains, project ids, workspace slugs |

Acceptance requires the checklist all true. Second annotator reviews at least 20% of records. You reject non-conforming records; we rework at no charge within 3 business days. First-pass acceptance target: 90% (set in the SOW).

---

## 6. Review and delivery

| Step | Who | When |
|---|---|---|
| Evaluation fields at close | Support engineer | Ticket close |
| RLHF pair + redaction | Data squad | 2 business days |
| Second-annotator sample | Second annotator | Same window |
| Reject / accept | You | Per batch |
| Rework | Data squad | 3 business days, no charge |
| Calibration | Your ML team + ours | Monthly |
| Schema change | You | 15 days' notice |

Tooling: only AI tools you approve in writing touch customer data, code or prompts. Jurisdictions disclosed; none added without 30 days' notice and approval.

---

## 7. What you need in place

Most clients have three of the four on day one.

| Prerequisite | Notes |
|---|---|
| Rating rubric and schema | We can draft both under 06 Enablement |
| Consent language in customer terms | Covering training use |
| Repository or evaluation tooling | To receive the records |
| Test environment | Required if regression scenarios are in scope |

---

## 8. First 30 days

1. Week 0 — Rubric, schema, consent flags in the helpdesk, exclude list for enterprise.
2. Day 10 — Evaluation records flowing on every ticket.
3. Week 3 — First RLHF batch against selection criteria; you reject against the rubric.
4. Month 1 — Measure share of tickets eligible after consent and redaction; set the monthly minimum against forecast.
5. Month 2 — Recurring fixes become kits; designated patterns become regression scenarios.

The support fee is paid either way. The data, kits and scenarios are the return on it.
