IBM's Palette: a 20B model that builds slide decks in your design language
IBM Research's Palette splits deck-building into a designer and a coder, then checks every slide — and nearly matches NotebookLM.
Ask a frontier model for a slide deck and you will usually get a good one. Ask for ten and they start to look alike: the same tasteful defaults, the same house style, the same faint "AI made this" look. IBM Research's answer, published November 3, 2026, is Palette: a 20B open-weight model trained to build decks in a specific design language, instead of drifting back to a frontier model's house style. Its training data follows the IBM Design Language, and its trick is not a bigger model. It is a split job plus a checker.
Why decks break small models
A slide looks simple, but making one asks a model to do three things at once. First, it lays out the slide without seeing it: it writes code that places every element at a position and font size, and only learns it was wrong after the code renders. A title that is slightly too long runs into the chart below it. Second, it makes two kinds of decisions in one pass: what each slide should say, and how to show it. Third, there is almost no public data showing how decks get made. Finished decks exist everywhere, but not the reasoning behind the design choices or the code that produced them.
That is why small self-hosted models produce broken decks. Palette attacks all three problems.
A designer and a coder, not one pass
Palette splits the work the way a person would, into two roles served by a single LoRA adapter:
- The designer reads the plan and writes a structured JSON brief: the color 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
pptxgenjsJavaScript that draws it, with its reasoning written out first.
Each role now makes one kind of decision. The brief between them is readable and editable, so a person can change one slide's layout without regenerating the whole 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 to 7 times faster, according to IBM.
Training used LoRA rather than full fine-tuning: it teaches a format and a skill on top of a capable base model without disturbing what the base already knows, and it made each experiment cheap. The training data was synthesized, not scraped: around 1,000 decks covering roughly 10,000 slides, generated with a large open teacher. Every example also carries the reasoning behind it, written as a counterfactual — what alternative was considered and why it was rejected — so the model learns the rule behind a choice, not just the choice.
You can also steer a deck in plain English with directives written in the plan, such as [[make this a timeline]]. IBM trained on 12 directive categories, each phrased several ways, so the model learns the intent rather than a fixed phrase.
The harness is the real idea
Even a well-trained model sometimes produces a broken slide. So Palette does not return the model's output directly. Every deck goes through a check-and-repair harness 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. Across 131 decks, IBM reports the harness adds 3.5 points on average to the deck score.
This is the part that transfers beyond decks. Any output whose quality can be checked in code — charts, diagrams, user-interface layouts — can use the same pattern: generate, render, measure, repair only when the measurement improves. IBM's own lessons say the same: put the reasoning in the data, fix the examples before adding rules, make repairs safe by default, and build the checker first.
How it scored
IBM evaluated Palette on PresentBench, which scores generated decks on five criteria: fundamentals, visual design, completeness, correctness, and fidelity. Palette ranks first on Economics and Education, third on Talk, and second on the three-domain mean at 59.7, behind NotebookLM at 60.8 — a gap of 1.1 points. It does best where structured content and numeric accuracy decide the score; on Talk, where decks are narrative and speech-driven, two closed systems score higher.
Two cautions belong with those numbers. First, they are IBM's own evaluation, not an independent replication. Second, PresentBench measures whether a deck is good, not whether it follows a specific design language — IBM says it is not aware of a benchmark that does, and calls that a gap it hopes to help close. The headline claim about staying on-brand is therefore the least tested part of the story. Also note how the evaluation was run: PresentBench provides a source document rather than a plan, so a separate frontier model drafted each plan from its document, and Palette built the deck from that plan.
What this changes for you
For local runners, the honest position is this. Palette is a 20B model, a size class that home setups already run in quantized form, and its whole point is ownership: your template, your machine, content that never has to leave your systems. That is a real difference from a frontier deck tool when the content is confidential or the brand rules are strict. But treat the announcement for what it is: a research post describing a method. The post I read does not link a downloadable weights repository or state a license, so do not plan an install around Palette until IBM publishes the model itself with those details. What you can use today is the method: split the roles, keep an editable brief between them, and never ship a generated artifact without a checker that can prove the repair helped.
IBM's next steps point the same way: using the harness checks as rewards for reinforcement learning, extracting figures from source documents, and re-skinning output from one or two of your existing presentation files without retraining. That last one is the feature to watch. If a small model can learn your template from a couple of example decks, the deck starts looking like yours.
The takeaway
Palette's score is good, but its score is not the point. The point is that a 20B open-weight model, split into a designer and a coder and wrapped in a checker that only keeps improvements, can nearly match a frontier system at a job small models used to fail. Watch for the weights and license before you try to run it. Steal the pattern — plan first, code second, check everything — for any structured output you generate locally.