IBM Research Palette: A 20B Open-Weight Model That Builds Slide Decks in Your Design Language

IBM Research has described Palette, a small open-weight model that builds slide decks in a design language you choose. In a post on Hugging Face dated November 3, 2026, the team says its fine-tuned 20B model ranks second on the three-domain mean of PresentBench, 1.1 points behind Google's NotebookLM (59.7 versus 60.8), and first on two of the three domains.

The result is IBM's own, and the baseline numbers come from the PresentBench paper. We have not run Palette. Still, the method is worth reading, because it solves a problem many teams share: getting a small, self-hosted model to produce output with a structure that code can check.

TL;DR: Palette in a table

Why frontier models are not enough here

IBM's argument starts with a complaint most people who generate decks will recognize. Ask a frontier model for one deck and you get a good one. Ask for ten and they start to look alike, with the same tasteful defaults and "a faint AI-generated deck look". Prompting does not fully stop the drift. And some content is confidential and cannot leave your systems at all.

Both points lead to a model you own, running on your infrastructure and trained on your design language. The catch, IBM says, is that small open models produce broken decks: titles that vanish into the background, text running off the slide, shapes stacked on top of each other.

Why decks are hard for small models

The post names three difficulties:

1. Layout without sight. The model writes code that places every element by x, y, width and font size. Whether a 75-character title fits on two lines at 56pt is arithmetic it must do in its head, and it learns the answer only after rendering.
2. Two kinds of decision at once. What each slide says and how to show it is editorial judgment. Where to put it is geometry. One pass across 10 to 20 slides must do both while keeping palette, type and layout consistent.
3. No data on how decks get made. Finished decks exist in bulk. The rationale behind design choices and the code that produced them do not.

The fix: a designer and a coder

Palette splits the work the way a person would. Both roles are served by one LoRA adapter.

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

Two practical benefits follow. The brief is readable and editable, so a person or agent can change one slide's layout without regenerating the deck. And since every slide's context is fixed before coding, the coder calls run in parallel, which IBM says makes the coding stage about 6 to 7 times faster.

IBM used LoRA instead of full fine-tuning because it teaches a format and skill without disturbing the base model, and it made experiments cheap. One lesson: coder examples were about five times longer than designer examples, so the designer was undertrained until IBM oversampled its examples fivefold.

How the training data was made

With no public corpus, IBM generated one using a large open teacher. Each deck starts from a recipe that sets genre, length, layouts and any user directives. Plans range from tidy outlines to raw content dumps so the model learns to cut and condense.

Each example carries counterfactual reasoning. The designer might say it considered a table but chose a bar chart because the slide's point is a trend. The coder might say a 62-character title would wrap to three lines at 44pt and collide with a chart, so it drops to 36pt.

The loop around the teacher matters as much as the teacher. Every synthesized deck is rendered and checked for overlap and overflow by the same checker used at inference. Broken slides are repaired, and their reasoning is rewritten to explain what the original layout got wrong. Each mistake the checker catches becomes a better training example.

Faithfulness: reference decks beat rules

The worst failure is a slide with facts that were not in the input. If a brief asks for a six-by-five table but carries three bullets, the coder has to invent the rest. IBM found that adding a prompt rule rarely prevented this. What worked was fixing the reference decks shown to the teacher, which it copied far more than it followed instructions.

Steering a deck in plain English

Palette accepts directives, short instructions wrapped in double square brackets inside the plan. The example in the post is a rollout list followed by a "make this a timeline" directive. Without it, the model would likely show the milestones as a table. With it, a timeline is drawn.

The model follows directives because it was trained to. IBM's data recipes cover 12 categories, each phrased several ways:

The check-and-repair harness

Every deck goes through a harness before it is returned. First, simple rules fix known mistakes, such as a malformed color code that would turn every slide black. Then each slide is rendered and measured, and a geometry checker flags overlap, clipping and overflow. Flagged slides go to a separate editor model that 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, because it can fix a slide but cannot make one worse. Across 131 PresentBench decks, IBM measured +3.5 points on average with the harness on.

The idea carries over to other agent work. We saw a similar logic in Sarvam's Prism decision model, where cheap verifiable signals stand in for judgment, and in the local proxy that blocks risky coding-agent tool calls, which also checks output before it acts.

The evaluation, and how to read it

PresentBench scores decks on fundamentals, visual design, completeness, correctness and fidelity. It supplies a source document rather than a plan, so a separate frontier model drafted each plan and Palette built the deck from it. IBM reports three domains.

• Economics and Education: Palette ranks first.
• Talk: two closed systems score higher and Palette places third.
• Mean: second, 59.7 against NotebookLM's 60.8, ahead of the rest, including Manus 1.6 and five others.

Three cautions. First, a frontier model drafted the plans, so the full pipeline is not fully local. Second, PresentBench does not measure whether a deck follows a specific design language, and IBM says it knows of no benchmark that does. The headline claim, "in your design language," is therefore not directly tested by the headline number. Third, IBM ran the evaluation, with baselines taken from the paper. For other deck tools we have covered, see Kimi Slides and Claude Cowork's docs and slides design.

What IBM plans next

IBM wants to use the harness's verifiable signals, such as render success, overlap and fact traceability, as rewards for reinforcement learning, so the model stops making the mistakes at all. Since the coder works one slide at a time, each slide is a short, independently checkable rollout, a natural fit for GRPO-style training. It also plans to extract figures from source documents with Docling and place them via the harness, and to explore re-skinning output from one or two existing .pptx files without retraining.

Four lessons you can reuse

The team lists takeaways that extend to other tasks whose output you can check in code, such as charts, diagrams and 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. The teacher copied references more than it followed instructions.
3. Make repairs safe by default. Keep a fix only when it measurably helps.
4. Build the checker first. It makes the data trustworthy and the outputs safe to ship.

Limits and open questions

• The post is a research description. We did not find a statement on this page about where to download weights, so check IBM's Hugging Face organization before planning a deployment.
• Figure-heavy decks remain a weak spot, per IBM.
• All results are IBM's.
• One synthetic data source, one design language: transfer to your brand is plausible but unproven.

Related reading

• Sarvam Prism: open-weights decision model
• IBM Granite 4.2 open reasoning models
• Kimi Slides and editable PowerPoint
• NotebookLM short video overviews
• Claude Cowork docs and slides design
• Manus 2.0 Studio

Figures reflect IBM Research's November 3, 2026 post and may be revised.