Where do allocation decisions fit in a model training or evaluation pipeline?

Allocation work can enter a model pipeline at four points, each needing a different record shape.

- **Supervised examples.** A prompt holds the receipt, candidate open items and the policy excerpt. The target is an allocation list with a reason code. - **Preference pairs.** Two candidate allocations for one receipt, with a label for which follows policy and why. - **Environment tasks.** The model acts through tools and the environment state changes after each call. - **Held-out evaluation.** Cases are withheld from training and scored by rule.

A minimal case record in JSONL might carry these fields:

- `case_id` such as `ALLOC-0912` - `receipt` with `receipt_id`, `amount`, `currency`, `value_date`, `payer_reference` - `open_items`, an array with `item_id`, `account_id`, `due_date`, `balance` - `policy_refs`, pointing to rule identifiers - `expected_actions`, an array drawn from `apply`, `split`, `hold`, `query` - `split_tag` marking train, validation or test

Keep the policy text in a separate file keyed by rule identifier so the same rule can be reused across cases and changed in a controlled way. Because the material is generated, a release can also carry a generation manifest stating which fields were produced by rule and which were written as free text, which helps a reviewer judge grounding.

For tool-based use, expose actions such as `list_open_items`, `apply_payment`, `place_in_suspense` and `raise_query`, each returning the updated balances.