Palette: teaching a small model to build decks in your design language

Ask a frontier model for a slide deck and you'll get a good one. Ask for ten and they start to look alike: the same tasteful defaults, the same house style, a faint "AI-generated deck" look. That's fine until you want the deck to look like your template. Frontier models have their own house style, and no amount of prompting stops them drifting back to it. And sometimes the content is confidential and can't leave your systems at all.

Both of those point to a model you own: open weights, running on your own infrastructure, trained on your own design language. The catch is that small open models, the kind you'd actually self-host, are bad at this. Their decks come out broken: titles that vanish into the background, text running off the slide, shapes stacked on top of each other.

Palette tests one bet: that a small open-weight model, trained on synthetic data in your design language and checked by a harness, can compete with frontier systems while you keep ownership of the result. We fine-tuned a 20B model to build decks the way people do: a designer plans the deck and a coder draws each slide. Its training data follows the IBM Design Language , and on PresentBench it ranks first on two of the three domains we measured. This post covers how we synthesized the data, trained the model and built a harness around it.

The harness already computes cheap, verifiable signals: does the slide render, does anything overlap or overflow, does every fact trace back to the brief. Today we use them to repair output after generation. Next, we want to use the same checks as rewards for reinforcement learning, so the model stops making these mistakes in the first place. Because the coder works one slide at a time, each slide is a short, independently checkable rollout, a natural fit for GRPO-style training.

We trained the adapter with LoRA rather than full fine-tuning: it teaches a format and a skill on top of a capable base without disturbing what the base already knows, and it made each experiment cheap. One lesson: coder examples are about 5× longer than designer examples, so a naive mix undertrained the designer until we oversampled its examples 5×.

A slide deck looks simple, but making one asks a model to do three things small models are bad at.

It lays out the slide without seeing it. The model doesn't draw slides; it writes code that places every element at an x, y, width and font size. Whether a 75-character title fits on two lines at 56pt is arithmetic the model does in its head, and it only finds out it was wrong after the code renders. Small models get this wrong often, which is where overlapping shapes and text running off the slide come from.

It makes two kinds of decisions at once. Deciding what each slide says and how to show it (a chart or a table? what to cut?) is editorial judgment. Placing it precisely is geometry. A single pass has to do both across 10–20 slides, while keeping the palette, type and layout consistent.