Start with the same business problem
A customer needs 40 units by Friday, while only 25 are available. There is an alternative product, but company policy requires approval before substitution. This fictional example can support several different deliverables.
The dataset captures the evidence
A prepared dataset might contain the order, catalog, inventory snapshot, policy and historical resolution. Documentation explains how the records connect and which information was available before the decision.
The license defines whether those records may be used for retrieval, evaluation, training or another purpose. Format does not establish permission.
The evaluation defines a test
An evaluation adds a task and grading logic. Success could require an approved fulfillment plan, a correct inventory reservation and no unauthorized edits.
The grader should check the relevant outcome. A fluent message saying “the order is resolved” does not establish that the system changed. Several different solutions may be acceptable.
The environment responds to actions
An interactive environment implements tools and state. The agent can inspect stock, request approval and submit an allocation. The system returns observations and changes according to defined rules.
For RL, that loop also supplies a reward used by a training process. Reliable rewards require checks for ambiguity, answer leakage, manipulation and unintended shortcuts. Historical records alone do not specify every alternative action’s consequences.
Validation is a separate deliverable
A working interface does not prove a model will improve. Evaluate the environment’s solvability, resets, cost and scoring, then assess any training claim on held-out tasks with a documented agent setup.
Existing interfaces can simplify integration, while the workflow’s rules and validation remain project-specific. Our public demo illustrates the interaction loop with deterministic rules; it does not run or train a model.