Where does approval-authority material fit in a model training pipeline?

Delegated approval material can enter a training pipeline at four points, and each needs a different shape of record.

- **Supervised fine-tuning.** Trajectories that show a model reading a request, looking up the policy, resolving who holds the role on the request date, then recording a decision. These are usually JSONL with message turns and tool calls. - **Preference data.** Pairs of decisions on the same request, one valid and one invalid, such as an approval within the delegate's limit against an approval just above it. Each pair carries a reason code. - **Evaluation.** Held-out tasks with fixed end states and graders that compare tables rather than prose. - **Reinforcement environments.** A simulated approval system with tools, a resettable state and a reward computed from checks on the final state and the steps taken.

Across all four, the same identifiers should link the material: `request_id`, `approver_role_id`, `delegation_id` and `policy_version`. If those links are stable, a lab can build trajectories from the event log, derive preference pairs by perturbing an amount or a date, and reuse the same tables for evaluation.

Two points affect planning. Training and evaluation material should be split by organisation or policy variant, not only by row, or the evaluation will reward recall of a rulebook. And because the output is generated, a lab should inspect how closely it matches the behaviour it cares about before mixing it into a larger corpus.