I would start with the source of each example, not its fluency. A response can be beautifully written and still contain private customer text, code we cannot use for this purpose, or a wrong resolution that the student will learn. The teacher's output does not automatically erase the rights or restrictions on the prompt, retrieved passages, tool results, or reference answer it was given. If the team cannot say where a row came from and what uses are permitted, it belongs outside the training set until that is resolved. This is a product and legal contract to verify with the data owner, not something a model can infer from the fact that it generated the final words.

I would keep a manifest at example and source-family level: source IDs and revisions, permission and retention scope, tenant boundary, teacher and prompt versions, tools and retrieved evidence used, generation time, filtering decisions, and the training split. Then deduplicate against the intended evaluation material and against near-identical generations. Split evaluation by original source family or customer, not random rows, because a thousand paraphrases of one ticket can land on both sides and make generalization look better than it is.

The next gate is truth. For code examples, can we compile or test the claimed behavior against the repository revision the teacher saw? For support answers, can a reviewer or a trusted system of record verify the policy, account state, and final resolution? Reject fabricated citations, unsupported steps and answers that promise an external effect the teacher did not perform. Keep some hard negatives as labeled bad examples if the training objective explicitly uses them. Do not mix them into positive demonstrations. Sampling only fluent examples selects for confidence, not correctness.

The million rows are probably not a million independent lessons. Group by seed case, topic, customer, generation prompt and teacher failure mode. Cap dominant families and measure quality on rare but important slices. A teacher that consistently invents an exception in one policy can produce ten thousand mutually consistent wrong answers. Research on recursively generated training data shows a risk when generated material replaces real data over generations. It does not prove that this particular curated mixture will collapse. Our own ablations must answer whether the synthetic rows improve the target tasks and whether they harm factual grounding or minority cases.

I would train a small controlled run with and without the new corpus, holding model, compute and data budget comparable. Evaluate on independently sourced real tasks, plus adversarial cases near the teacher's known errors, and review actual production slices after a guarded rollout. If only 20,000 verified examples survive, that can be a good result. If the interviewer says the teacher is much stronger than the student, that makes generation useful, but it does not make every label true or every source permissible. The training data license expires tomorrow. Can the model stay online? asks what happens when a licensed corpus expires. This question asks whether generated training examples inherited restrictions and correlated mistakes before they ever enter the run.