
Palette: Teaching a Small Model to Build Decks in Your Design Language

Palette is a system for building slide decks with a small open-weight model trained on your own design language. The motivation is that frontier models produce good decks but drift back to their own generic house style, and confidential content may not be allowed to leave your systems. Palette therefore uses a 20B model fine-tuned with LoRA on synthetic data in the IBM Design Language, so the model can run on your own infrastructure. On PresentBench, it ranks first on Economics and Education, third on Talk, and second on the three-domain mean, scoring 59.7 against NotebookLM‘s 60.8.
Decks are hard for small models because the model writes code that positions every element at x, y, width and font size without seeing the rendered slide, so overflow and overlap appear only after rendering. The model also has to make editorial and geometric decisions at once across 10-20 slides while keeping layout consistent, and there is no public data showing the reasoning or code behind finished decks. Palette splits the task like a human workflow: a designer role converts a plan into a structured JSON brief (palette, type system, per-slide layout, content, design rationale), and a coder role writes pptxgenjs JavaScript for each slide from that brief, prefixed by its reasoning. The brief is editable, so one slide can be changed without regenerating the deck, and since each slide’s context is fixed, coder calls run in parallel, making the coding stage about 6-7x faster.
Training data was synthesized with a large open teacher: about 1,000 decks covering roughly 10,000 slides, generated from recipes that control genre, length, layouts and directives. Every example includes counterfactual reasoning that states an alternative and why it was rejected, so the model learns the rule behind a choice. Synthesized decks are rendered and checked with the same geometry checker used at inference; broken slides are repaired, and their reasoning is rewritten as counterfactuals. The hardest problem was faithfulness: adding rules to the teacher’s prompt rarely changed its output, but including reference decks in the prompt did, because the teacher copied references far more reliably than it followed instructions.
Users can steer design choices with directives, short instructions in [[ ]] placed directly in the plan, for instance [[make this a timeline]]. The designer builds the directive into the brief and the coder follows it. The training recipes include directives from 12 categories, each phrased in several ways, so the model learns intent rather than a fixed phrase.
At inference, Palette does not return raw model output. A harness applies simple rules for known mistakes, then renders and measures every slide, flagging overlaps, clipping, and text that runs off the slide. A separate editor model rewrites flagged slides, and the rewrite is kept only if the checker confirms it improved; otherwise the original remains, so the harness can fix a slide but never make it worse. Across 131 PresentBench decks, the harness added 3.5 points on average.
The evaluation uses PresentBench, which scores fundamentals, visual design, completeness, correctness, and fidelity. Because PresentBench provides a source document rather than a plan, a separate frontier model drafted plans from documents, and Palette built decks from those plans. Palette does best on Economics and Education, where structured content and numeric accuracy matter; on Talk, two closed systems score higher and Palette is third. PresentBench does not measure adherence to a design language, which the post identifies as a gap. Next steps include using the harness’s cheap signals as rewards for reinforcement learning, so the model avoids mistakes in the first place; extracting figures from source documents with Docling for figure-heavy decks; and exploring re-skinning output from existing .pptx files to support custom templates without retraining.
The post closes with lessons for other checkable-output tasks: put the reasoning in the data, fix examples before adding rules, make repairs safe by default, and build the checker first.


