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

Frontier models generate decent slide decks until you ask for ten, at which point they all look the same. That uniformity is acceptable until you need a deck matching your specific template or require confidential content to stay within your own systems. The solution lies in a model you own: open weights, running on your infrastructure, and trained on your specific design language.

The problem with small open models is that their output often breaks. Titles vanish into the background, text runs off the slide, and shapes stack on top of one another. Palette tests the hypothesis that a small open-weight model, trained on synthetic data matching your design language and checked by a harness, can compete with larger systems while you retain ownership.

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. On PresentBench it ranks first on two of the three domains measured.

Why decks are hard for small models

A slide deck appears simple, yet making one requires a model to perform three tasks that small models struggle with.

First, the model lays out the slide without seeing it. It does not 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 performs in its head. It only discovers the error after the code renders. Small models get this wrong often, which is where overlapping shapes and text running off the slide come from.

Second, the model makes two kinds of decisions at once. Deciding what each slide says and how to show it, such as choosing between a chart or a table, 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.

Third, there is 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 is 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 does not 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 were not in the input, and we found that a prompt rule cannot 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.

[[make this a timeline]]

[[be candid, no spin]]

[[this is for the board]]

[[lead with the ask]]

[[no pricing]]

[[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 does not 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 cannot 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 are not aware of a benchmark that does, and it is 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