Training Qwen3-0.6B Before Our Public-Sector RFP Experiment

Public-sector RFPs look like a promising reinforcement-learning problem. A response team receives a dense package of instructions, contracts, exhibits, forms, schedules, and amendments. Before anyone can write a proposal, that package has to become a reliable plan: what must be submitted, who owns each response, which facts still need confirmation, and where every requirement came from.

General models can produce plausible summaries of these packages. Plausibility is not enough. A missed amendment, an invented deadline, or a requirement without evidence can make the plan actively harmful. That gives us a useful training target: produce a structured proposal workplan whose requirements, citations, dependencies, and missing information can be checked.

Our larger experiment asks whether an 8B model can learn this narrow job well enough to beat a much larger general model on both accepted workplan quality and cost. Before paying for that run, we wanted proof that the complete OpenPond training path worked on a small model. We used Qwen3-0.6B as that systems test.

This was not the final RFP model and it did not use the frozen evaluation. It was a deliberately bounded GRPO run with four rollouts, one optimizer step, and a LoRA adapter at the end.

Where the RFP data came from

We started with public procurement packages rather than synthetic prompts. The development example is the National Park Service concession solicitation for food, retail, and related services at the Statue of Liberty and Ellis Island. It is a good demonstration package because the response has to reconcile operating requirements, financial information, property exhibits, construction obligations, forms, and amendments across many documents.

The diagnostic corpus uses six separate National Park Service concession packages. Together they contain 122 files and 1,644 pages. We reviewed each file before use, accepted 114 native-text files, and excluded eight files with protected marks or third-party material. Four complete packages belong to training, one to validation, and one to diagnostic holdout. The Statue of Liberty package remains a development example, so it cannot leak into the held-out comparison.

Each package stays intact. Pages, amendments, extracted text, and labels from one procurement never cross into another split. The target is one canonical proposal-workplan.json containing the document inventory, requirements, response tasks, dependencies, citations, conflicts, clarification items, and missing information. Spreadsheets and other views are generated from that file after validation instead of asking the model to author several versions of the same answer.

Building the Taskset

We turned the research contract into an OpenPond Taskset. Each attempt receives a complete package inside Work, reads the source files, creates the workplan, and submits it to a private grader. The grader checks the schema, source boundaries, exact facts, citations, amendment handling, and serious failure cases. Gold answers and verifier internals stay outside the model-visible environment.

That design turns document work into a training signal. A valid but incomplete plan can receive partial credit, while fabricated evidence, ignored amendments, or malformed output can fail hard. GRPO becomes useful only if repeated attempts produce a stable but varied reward distribution, so we test the Taskset and grader before committing to a larger run.

Starting the run

The 0.6B run used a compact acceptance Taskset rather than the procurement corpus. That kept the first paid test focused on infrastructure: could OpenPond start the managed trainer, execute a complete rollout group, record the reward signal, commit an optimizer update, preserve the resulting adapter, and show the run correctly in the desktop app?

We selected Qwen3-0.6B with a LoRA rank of 16, a learning rate of 1e-5, four rollouts per update, and one optimizer step.

The model page keeps the resulting version and complete run history together.

OpenPond executed the Taskset, collected the graded trajectories, and passed the group to GRPO. The four rewards were different enough to provide a real optimization signal rather than four copies of the same score.

The result

The run completed in 20 minutes and 18 seconds on one NVIDIA A40. It used four rollouts, committed one optimizer update, and produced a LoRA adapter as Version 1. The final recorded reward was 0.9326 and the run cost was $0.1480.

The completed run shows the reward signal, learning rate, recipe, resource usage, cost, and output.

One update cannot establish meaningful model improvement, and we do not present it as one. It proves the expensive parts of the loop before the RFP pilot: executable Tasksets can produce graded trajectories, GRPO can consume them, the managed trainer can save a usable adapter, and the desktop can retain the recipe, metrics, cost, and output together.

The next stage is to run the RFP diagnostic Taskset against an exact 8B base model and a strong general model under the same Work environment. We will proceed to bounded training only if the grader remains stable, the rollout groups contain meaningful reward variation, and the task appears economically worth specializing. A negative result is still useful. The point is to measure whether this narrow model should exist, not to assume the answer before training it.