A kitchen drawing goes in. A built Mozaik room comes out.

pywinauto 0.6.9 walks Mozaik's entire UI Automation tree on every element lookup. Measured on the shop machine, setting the room name took 94.1 seconds and the wall height 91.3 seconds, so filling five form fields took seven to eight minutes. Connecting alone took 19 seconds.

The fix was to stop asking Windows to find controls. Connect through win32gui, cache tab handles once, click by cached screen position and type with SendKeys. Connect dropped to effectively zero, tab switches to a few hundred milliseconds, and typing averaged 763 ms per input across 20 inputs.

The chart shows the hybrid experiment's measured numbers. The Fast Win32 Driver that followed it the same day is documented as faster still, but its per-action timings are asserted in code comments rather than logged, so they are not plotted.

Type "Change all base cabinets to cherry wood with soft-close hinges" and about three and a half seconds later a small JSON block comes back: what changed, the Mozaik steps to make it happen, and a one-line explanation. Ask it about the weather and it declines and points back to cabinets.

It is a fine-tune of Qwen2.5-Coder-7B-Instruct using 4-bit QLoRA, trained in under eleven hours on the single consumer GPU in the Windows machine that also runs Mozaik, and served locally through Ollama. The adapter is 40 MB against an 8.1 GB quantised model.

// response contract every trained model must emit
{
  "spec_delta":  { "cabinets[type=base].finish": "cherry",
                   "hardware.hinges": "soft-close" },
  "actions":     [ { "type": "open_sidepanel", "path": "Materials" }, … ],
  "explanation": "Base cabinets set to cherry; soft-close hinges applied."
}
// off-topic requests
{ "error": "I only help with Mozaik cabinet design..." }

Two ideas hold the pipeline honest. Before Mozaik is touched, validate_extraction() must return zero warnings: every cabinet has a wall, every position ratio is between 0 and 1, no refrigerator or dishwasher is coded as a cabinet, and the parsed counts equal the cabinet list. Otherwise the job is marked build_failed with the warning count and the reason is posted to the phone.

After the build, the 3D screenshot is analysed and compare_extraction_to_analysis() emits named pass or fail checks. Expected counts come from the extraction file; actuals come from the 3D observation. There is no rubric to argue with and no checklist to rubber-stamp: one mismatch and the verdict is FAIL. The designer can overrule it with Approve, or re-run it with Force 3D Comparison.