Palette: a 20B open-weight model builds slide decks in a design language

Frontier models make good slide decks, the post argues, but ask for ten and they start to look alike: the same tasteful defaults, a faint "AI-generated deck" look that prompting does not remove. Sometimes the content is also confidential and cannot leave a company's systems. Small open models that could be self-hosted are bad at the job: titles vanish into the background, text runs off the slide, shapes stack on top of each other. Palette is the authors' test of one bet: that a small open-weight model, trained on synthetic data in your design language and checked by a harness, can compete with frontier systems while you keep ownership of the result.

The team fine-tuned a 20B model to work the way people do. A designer role plans the deck and writes a structured JSON brief: the palette, the type system, and for each slide its layout, exact content and a short design rationale. A coder role takes one slide's spec from the brief and writes the pptxgenjs JavaScript that draws it, preceded by its reasoning. Both roles are served by a single LoRA adapter. The split matters because the post says a small model otherwise has to do two things at once across 10 to 20 slides: editorial judgment (chart or table, what to cut) and geometry (placing every element at an x, y, width and font size, such as working out in its head whether a 75-character title fits on two lines at 56pt). 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 before any code is written, coder calls run in parallel, one per slide, which makes the coding stage about 6 to 7 times faster. The authors chose LoRA over full fine-tuning because it teaches a format and a skill without disturbing what the base model knows, and it made experiments cheap. One lesson: coder examples are about 5 times longer than designer examples, so a naive mix undertrained the designer until its examples were oversampled 5 times.

No public corpus of plans, design decisions and slide code exists, so the team generated one with a large open teacher: around 1000 decks, roughly 10,000 slides, each started from a recipe that sets genre, length, layouts and user directives. The training data follows the IBM Design Language. Every example carries its reasoning written as a counterfactual that weighs an alternative and says why it was rejected. A designer trace might say a bar chart beats a table because the point is the trend, not exact figures; a coder trace might say a 62-character title at 44pt would wrap to three lines and hit the chart, so it is set at 36pt. Each synthesized deck is rendered and checked for overlaps and overflow by the same checker the harness uses at inference; broken slides are repaired and their reasoning is rewritten as a counterfactual about what the original got wrong.

Faithfulness, meaning slides that contain facts not in the input, was the hardest problem. A prompt rule could not 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 worked was fixing reference decks. The teacher copies the references in its prompt far more than it follows instructions, so fixing a reference reliably changed its output while adding a rule rarely did.

Users can steer a deck with directives: short instructions written in the plan and wrapped in [[ ]], such as [[make this a timeline]] under a list of rollout milestones that the model would otherwise show as a table. The data recipes include directives from 12 categories, each phrased several ways so the model learns intent rather than a fixed phrase.

Palette does not return raw model output. Every deck passes through a check-and-repair harness. Simple rules first fix known mistakes, such as a malformed color code that would turn every slide black. Then each slide is rendered and a geometry checker flags text that overlaps, is clipped or runs off the slide. Flagged slides go to a separate editor model that rewrites the slide's code. The key rule is that a rewrite is kept only if the checker confirms the slide improved; otherwise the original stays, so the harness can fix a slide but cannot make one worse. Across 131 PresentBench decks, each generated once and scored with and without the harness, it adds 3.5 points on average.

For evaluation the team used PresentBench, which scores decks on five criteria: fundamentals, visual design, completeness, correctness and fidelity. PresentBench supplies a source document rather than a plan, so a separate frontier model drafted each plan and Palette built the deck from it. Baseline numbers come from the PresentBench paper. Palette ranks first on Economics and Education, third on Talk (where two closed systems score higher) and second on the three-domain mean: 59.7 against 60.8 for NotebookLM, 1.1 points behind, ahead of the rest of the field including Manus 1.6 and five other systems. The authors say it does best where structured content and numeric accuracy decide the score. PresentBench measures whether a deck is good, not whether it follows a specific design language, and the authors are not aware of a benchmark that does.

Next, the team wants to use the harness checks (does the slide render, does anything overlap, does every fact trace back to the brief) as rewards for reinforcement learning, a natural fit for GRPO-style training since each slide is a short, independently checkable rollout. They also want to close the gap on figure-heavy decks by extracting figures from source documents (for example with Docling), and are exploring re-skinning output from one or two existing .pptx files without retraining. Their stated lessons: put the reasoning in the data, fix the examples before adding a rule, make repairs safe by default, and build the checker first.

Key facts

• Palette is a 20B open-weight model fine-tuned with a single LoRA adapter that serves two roles: a designer that writes a JSON brief and a coder that writes pptxgenjs code for each slide.
• Training data was synthetic: around 1000 decks and roughly 10,000 slides generated by a large open teacher, following the IBM Design Language, with counterfactual reasoning traces attached.
• A check-and-repair harness keeps an editor rewrite only if the geometry checker confirms the slide improved; across 131 decks it adds 3.5 points on average on PresentBench.
• On PresentBench Palette ranks first on Economics and Education, third on Talk, and second on the three-domain mean: 59.7 against NotebookLM's 60.8.
• Parallel per-slide coder calls make the coding stage about 6 to 7 times faster; the authors plan to use the harness checks as reinforcement learning rewards next.

Why it matters

The post makes a case for owning the deck-building model: frontier systems drift back to their own house style whatever the prompt says, and confidential content may not be allowed to leave a company's systems. Palette's claim is that a single 20B open-weight model, trained on synthetic data in a specific design language, can land within 1.1 points of the best system on a public benchmark. The method also carries a wider idea the authors name: where output has a structure you can check in code, such as charts, diagrams or UI layouts, a checker can both clean up training data and make outputs safe to ship.

Who it affects

Teams that want slides in their own template and cannot or do not want to send content to a frontier provider, and anyone building generation systems for structured, checkable output. The authors also point to charts, diagrams and UI layouts as places where the same approach could extend.

How to use it

The post is a description of the approach, not a release notice. It mentions no release of weights, code, dataset or harness, and no license or availability date. What a reader can take from it is the recipe: split the work into a designer and a coder, store a readable brief between them, train on reasoning that includes rejected alternatives, and run a render-and-measure check with rewrites kept only on improvement. For steering, Palette accepts directives in the plan wrapped in [[ ]], for example [[make this a timeline]], phrased in many ways across 12 directive categories.

How solid is it

These are first-party results from the authors. Baseline numbers are taken from the PresentBench paper, and the plans used for the benchmark runs were drafted by a separate frontier model, with Palette building the deck from each plan. The 3.5 point harness gain is an average over 131 decks, each generated once; no variance or per-domain breakdown is given. Per-domain scores are not given in the text, only the three-domain means (59.7 and 60.8). The post names no individual authors, and does not name the base model or the teacher model.

Risks and caveats

PresentBench measures whether a deck is good, not whether it follows a specific design language, so the benchmark does not test the headline promise of matching your template; no human evaluation or comparison against decks in the IBM template is reported. Palette is first on two domains but third on Talk, where decks are narrative and speech-driven, and second overall behind NotebookLM. The authors say faithfulness, meaning slides containing facts not in the input, was the hardest problem and that a prompt rule could not prevent it. The 6 to 7 times speed-up covers the coding stage only. Figure-heavy decks remain a gap the authors say they want to close.

“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.”

— Illustrative coder reasoning trace from Palette's training data, as shown in the post