Evidence at a glance
Separate editorial choices from slide layout
IBM Research gives two reasons for building Palette. A frontier model may produce one good deck, but ask for ten and they can start to share the same defaults and house style. The team also wants a model that can follow a user's own design language. Keeping confidential material on internal infrastructure is another motivation. The article presents an open-weight model running on owned infrastructure as one possible approach; it does not report a deployment or validate its security.
Small models face a different problem: they generate code to draw slides rather than arranging elements directly on a canvas. They must estimate positions and sizes before rendering reveals whether text overflows or shapes overlap. At the same time, they must decide what each slide says, whether to use a chart or a table, and what to cut. Palette addresses this by splitting those decisions instead of asking the model to make them all in one pass.
Plan the deck, then code each slide
Palette assigns two roles to a single LoRA adapter. The designer reads the plan and creates a structured JSON brief with the palette, type system, layout and exact content for each slide, plus a short design rationale. The coder then takes one slide's specification and writes the pptxgenjs JavaScript that draws it, preceded by its reasoning.
The brief is readable and editable, so a person or agent can change one slide's layout without regenerating the whole deck. Since each slide's context is set before code is written, coder calls can run in parallel, one per slide. The authors say this makes the code-generation stage about 6–7× faster; that figure is not an end-to-end deck-generation comparison. Coder examples are about 5× longer than designer examples, so the team oversampled designer examples 5× to avoid undertraining that role.
Synthetic examples teach the reasons behind design choices
The authors say they found no public corpus combining deck plans, design decisions and the code that produced the slides. They therefore used a large open teacher model to synthesize about 1,000 decks covering roughly 10,000 slides. The training data follows IBM Design Language. Each deck starts from a recipe specifying its genre, length, layouts and user directives. Plans range from tidy outlines to raw content dumps, giving the model examples of how to select and condense material.
Examples also include counterfactual reasoning: not just the choice made, but an alternative considered and why it was rejected. For a slide showing quarterly revenue trends, for example, the rationale might favor a bar chart over a table because the trend is easier to see at a glance. Coder reasoning handles geometry, such as whether a title at a given font size would wrap to three lines and collide with a chart. Synthetic data from a teacher model is not automatically reliable. The authors found that reference decks steered the teacher more effectively than adding rules alone; the teacher tended to copy the references.
Render, check, and keep only verified repairs
Palette's checking process is used both to improve training data and to repair generated decks. Each synthetic deck is rendered and checked for overlap and overflow. The team repairs broken slides and rewrites the accompanying rationale to explain what was wrong with the original layout and why the fix works. The authors use errors caught by the checker as better training examples.
At generation time, the harness first applies simple rules to known problems, such as malformed color codes. It then renders and measures each slide; a geometry checker flags text that overlaps, is clipped or runs off the slide. A separate editor model rewrites flagged slides, but the change is kept only if the checker confirms an improvement. Otherwise, the original remains. Users can also add short directives in double brackets in the plan—for example, asking for milestones to be shown as a timeline. The authors say the training recipes cover 12 directive categories; the designer incorporates a directive into the brief, and the coder follows it when drawing the slide.
The benchmark does not test design-language fidelity
The authors report that Palette ranks first in Economics and Education on PresentBench and third in Talk. Its average across the three domains is 59.7, 1.1 points below NotebookLM's 60.8. They also report that enabling the check-and-repair harness raises the average by 3.5 points across 131 PresentBench decks. The PresentBench paper describes a benchmark of 238 evaluation instances, with an average of 54.1 checks per instance.
Those results measure deck quality, not whether Palette follows IBM Design Language, so they cannot by themselves establish that the model meets the design goal described in the article. The available material also lacks Palette's per-domain scores, a full experimental setup and statistical significance results. There is a further discrepancy to resolve: the PresentBench website currently lists a NotebookLM overall score of 62.5, while the article compares three-domain averages and reports 60.8. The material does not establish whether the difference is entirely due to the scope of the scores. The base model's name, whether its weights have been released, and results across other companies' design systems are also not reported in the public material.