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.

Why decks are hard for small models

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.

There's no data showing how decks get made. Plenty of finished decks exist, but not the rationale behind the design choices or the code that produced them.

Build it like a human: a designer and a coder

Nobody makes a deck in one pass. You decide the story first (how many slides, what each one says, which gets a chart and which gets a table) and only then build each slide. Palette splits the work the same way, into two roles served by a single LoRA adapter:

• The designer reads the plan and writes a structured JSON brief: the palette, the type system, and for each slide its layout, its exact content and a short design rationale.
• The coder takes one slide's spec from the brief and writes the pptxgenjs JavaScript that draws it, preceded by its reasoning.

Each role now makes one kind of decision: the designer handles the editorial judgment, and the coder handles the geometry. The brief between them is readable and editable, so a person or an agent can change one slide's layout without regenerating the deck. And because every slide's context is fixed before any code is written, the coder calls run in parallel, one per slide, which makes the coding stage about 6–7× faster.

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×.

Synthesizing decks and their reasoning

There's no public corpus of plans, design decisions and slide code, so we generated one with a large open teacher. Each deck starts from a recipe that sets its genre, length, layouts and any user directives, so we control what the data covers. Plans range from tidy outlines to raw content dumps, so the model learns to cut and condense. We generated around 1000 decks covering roughly 10,000 slides.

Every example also carries the reasoning behind it, written as a counterfactual: the trace weighs an alternative and says why it was rejected, so the model learns the rule behind a choice, not just the choice. The designer reasons about content and form. For example:

"Revenue for four quarters, with one clear upward trend. I considered a table, but the point of this slide is the trend, not the exact figures, so a bar chart makes it visible at a glance."

The coder reasons about geometry:

"The title is 62 characters. At 44pt it would wrap to three lines and run into the chart below, so I set it at 36pt, which fits on two lines and leaves room above the chart."

The teacher alone doesn't make the data good; the loop around it does. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker the harness uses at inference. Broken slides are repaired, and their reasoning is rewritten as the same kind of counterfactual, covering what the original layout got wrong and why the fix works. Each mistake the checker catches becomes a better training example.

The hardest problem was faithfulness. The worst failure is a slide with facts that weren't in the input, and we found that a prompt rule can't prevent it. If a brief asks for a six-by-five table but carries only three bullets, the coder has to invent the rest.

What fixed it was reference decks, not the rules: fixing a reference reliably changed the teacher's output, while adding a rule rarely did. The teacher sees a few reference decks in its prompt and copies them far more than it follows instructions.

Steering a deck in plain English

Users often want finer-grained control over specific design choices: a chart instead of a table, a particular color, a darker cover. Palette lets them ask for these with directives, short instructions written directly in the plan and wrapped in [[ ]]:

## Rollout plan
- March: pilot with two teams
- May: security review complete
- July: rollout to all of engineering
- September: company-wide launch
- November: first adoption review
[[make this a timeline]]

The designer builds each directive into the brief, and the coder follows it when drawing the slide. Without the directive, the model would reasonably show these milestones as a table; with it, the model draws a timeline instead.

The model follows directives because it was trained to. The data recipes include directives from 12 categories, a few of which are shown below, each phrased several different ways, so the model learns the intent rather than a fixed phrase.

Category	Example directive
Layout	[[make this a timeline]]
Tone	[[be candid, no spin]]
Audience	[[this is for the board]]
Order	[[lead with the ask]]
Leaving out	[[no pricing]]
Emphasis	[[highlight the headline number]]

Figure 1. An illustration of the same plan without (left) and with (right) the [[make this a timeline]] directive.

Building a check-and-repair harness

Even a well-trained model sometimes produces a broken slide: a title in the same color as the background, or two boxes stacked on top of each other. So Palette doesn't return the model's output directly; every deck goes through a harness first.

Figure 2. The designer drafts the brief, the coder writes each slide's code in parallel, and the harness checks and repairs every slide before the deck is returned.

First, simple rules fix known mistakes, such as a malformed color code that would otherwise turn every slide black. Then each slide is rendered and measured: a geometry checker flags text that overlaps, gets clipped or runs off the slide. Flagged slides go to a separate editor model, which rewrites that slide's code.

The key rule is that a rewrite is kept only if the checker confirms the slide improved; otherwise the original stays. That makes the harness safe to run on every deck. It can fix a slide, but it can't make one worse.

Figure 3. An illustration of a repair. As generated (left), each card's title is stacked on top of its description; the harness detects the overlaps and reflows the cards into a 2×2 grid (right).

To measure its effect, we generated each PresentBench deck once and scored it with and without the harness. Across 131 decks, the harness adds 3.5 points on average.

Evaluation

We evaluate on PresentBench, which scores generated decks on five criteria: fundamentals, visual design, completeness, correctness and fidelity. PresentBench provides a source document rather than a plan, so for these runs a separate frontier model drafted each plan from its document, and Palette built the deck from that plan. We report three domains; baseline numbers are from the PresentBench paper.

Figure 4. PresentBench scores by domain. Palette (blue) against NotebookLM, Manus 1.6 and five other systems (gray). Palette ranks first on Economics and Education, third on Talk, and second on the three-domain mean.

Palette does best where structured content and numeric accuracy decide the score, ranking first on Economics and Education. On Talk, where decks are narrative and speech-driven, two closed systems score higher and Palette places third. Across the three domains it places second, 1.1 points behind NotebookLM (59.7 vs 60.8) and ahead of the rest of the field, as a single 20B open-weight model.

PresentBench measures whether a deck is good, but not whether it follows a specific design language. We're not aware of a benchmark that does, and it's a gap we hope to help close.

What's next

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 also want to close the gap on figure-heavy decks by extracting figures from source documents (e.g. with Docling) and placing them with the harness. And we're exploring a lighter way to bring your own templates: re-skinning output from one or two of your existing .pptx files, without retraining.

What we learned

Building Palette taught us a few effective methods that extend naturally to other tasks whose output has a structure you can check in code, from charts and diagrams to UI layouts:

1. Put the reasoning in the data. Training on why a choice was made, including what was rejected, teaches more than the choice alone.
2. Fix the examples before adding a rule. When the teacher got something wrong, our first instinct was to add a rule to its prompt, and that rarely helped. The teacher copied its reference decks far more than it followed instructions, so fixing the reference was what actually changed its output.
3. Make repairs safe by default. A fix that's kept only when it measurably helps can run on every output.
4. Build the checker first. It's what makes the data trustworthy and the outputs safe to ship.