Ask a frontier model for a slide deck and you'll get something polished. Ask for ten and they start looking the same: tasteful defaults, a house style, that faint "AI-generated" sheen. The problem isn't quality—it's ownership. Frontier models have their own aesthetic, and no amount of prompting stops the drift back to it. And if your content is confidential, it can't leave your infrastructure at all.
Both constraints point to the same solution: an open-weight model you control, trained on your design language, running on your hardware. The catch is that small open models—the kind you'd actually self-host—are terrible at this. Their decks come out broken: titles vanishing into backgrounds, text running off slides, shapes stacked on top of each other.
Palette tests whether a 20B model, fine-tuned on synthetic data in your design language and wrapped in a check-and-repair harness, can compete with frontier systems while you keep full ownership. IBM fine-tuned the model to build decks the way people do: a designer plans the structure, a coder draws each slide. The training data follows the IBM Design Language, and on PresentBench it ranks first on two of three measured domains.
Why small models break decks
A slide deck looks simple, but generating one asks a model to do three things small models handle poorly.
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. It only finds out it was wrong after the code renders. Small models get this wrong constantly, which is where overlapping shapes and text overflow come from.
It makes two kinds of decisions simultaneously. Deciding what each slide says and how to show it—chart or table, what to cut—is editorial judgment. Placing elements precisely is geometry. A single pass has to do both across 10–20 slides while keeping palette, type, and layout consistent.
There's no data showing how decks get made. Plenty of finished decks exist, but not the rationale behind design choices or the code that produced them. No corpus of plans, design decisions, and slide code exists publicly.
Two roles, one adapter
Nobody makes a deck in one pass. You decide the story first—how many slides, what each says, which gets a chart—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, exact content, and a short design rationale.
- The coder takes one slide's spec from the brief and writes the
pptxgenjsJavaScript that draws it, preceded by its reasoning.
Each role now makes one kind of decision. The designer handles editorial judgment; the coder handles geometry. The brief between them is readable and editable, so a person or agent can change one slide's layout without regenerating the entire deck.
Because every slide's context is fixed before any code is written, the coder calls run in parallel—one per slide. That makes the coding stage about 6–7× faster.
They trained with LoRA rather than full fine-tuning: it teaches a format and skill on top of a capable base without disturbing what the base already knows. One lesson: coder examples are about 5× longer than designer examples, so a naive mix undertrained the designer until they oversampled its examples 5×.
Synthetic data and counterfactual reasoning
With no public corpus, IBM generated one with a large open teacher. Each deck starts from a recipe that sets genre, length, layouts, and user directives, so they control coverage. Plans range from tidy outlines to raw content dumps, teaching the model to cut and condense. They generated around 1,000 decks covering roughly 10,000 slides.
Every example carries reasoning written as a counterfactual: the trace weighs an alternative and says why it was rejected. The model learns the rule behind a choice, not just the choice.
The designer reasons about content and form:
"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. 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 becomes a better training example.
The faithfulness problem
The worst failure is a slide with facts that weren't in the input. They found that prompt rules 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 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.
Directives: plain-English steering
Users often want finer control: a chart instead of a table, a particular color, a darker cover. Palette lets them specify this with directives—short instructions wrapped in [[ ]] and written directly in the plan:
## Rollout plan
- March: pilot with two teams
- May: security review complete
- July: rollout to all of engineering
[[make this a timeline]]
The designer builds each directive into the brief; 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—layout, tone, audience, order, emphasis, leaving out—each phrased several different ways. The model learns the intent rather than a fixed phrase.
Check-and-repair harness
Even a well-trained model sometimes produces broken slides: a title in the same color as the background, two boxes stacked on top of each other. Palette doesn't return the model's output directly. Every deck goes through a harness first.
Simple rules fix known mistakes—a malformed color code that would turn every slide black, for instance. 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: 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.
To measure its effect, they generated each PresentBench deck once and scored it with and without the harness. Across 131 decks, the harness adds 3.5 points on average.
PresentBench results
They 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, and Palette built the deck from that plan.
Palette ranks first on Economics and Education, where structured content and numeric accuracy decide the score. On Talk—narrative, speech-driven decks—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. That's a gap the team acknowledges and hopes to help close.
What this means
This is the first serious attempt I've seen to encode a design system into a self-hosted model. Not "make it look nice"—that's generic aesthetic polish. But "make it look like this," where "this" is a defined visual language with rules about palette, type, grid, and hierarchy.
The two-role split is elegant. It mirrors how humans work and cuts the context window per operation. More importantly, it makes the intermediate artifact—the brief—readable and editable. You can steer one slide without regenerating the deck. That's the kind of control that makes a tool usable in production.
The counterfactual reasoning in the training data is clever. Instead of showing the model what to do, you show it what not to do and why. That encodes the rules behind the choices, not just the choices themselves. It's a pattern worth stealing for other structured generation tasks.
The harness is table stakes. Small models break in predictable ways. You can detect those breaks geometrically and repair them with a second model call. The discipline of "only keep repairs that the checker confirms improved the slide" is what makes this safe. Otherwise you're stacking error on error.
What's missing from the evaluation is a benchmark that measures adherence to a design language. PresentBench measures quality—good decks vs. bad decks. But a deck can be high-quality and still look nothing like your brand. That's the whole problem Palette is trying to solve. Until there's a benchmark for that, we're evaluating half the question.
Still: a 20B model placing second overall and first on structured domains, running on your hardware, trained on your design system, is a real result. Frontier models are better at narrative decks. But if you need structured content—economics, education, quarterly business reviews—and you need it in your visual language without sending your data to someone else's API, this is the first credible path I've seen.