Palette: teaching a small model to build decks in your design language
Palette is an IBM Research fine-tune of a 20B open-weight model that builds slide decks in the IBM Design Language. A designer role writes a JSON brief and a coder role writes pptxgenjs code per slide, both served by one LoRA adapter. Training used about 1000 synthetic decks (roughly 10,000 slides) with counterfactual reasoning traces. A render-and-repair harness adds 3.5 points on PresentBench. Palette ranks first on Economics and Education and second on the three-domain mean (59.7 vs NotebookLM 60.8).
What it claims
Palette is a LoRA adapter on a 20B open-weight model. On PresentBench it scores 59.7 averaged over three domains, against NotebookLM's 60.8. It ranks first on Economics and Education and third on Talk. The authors' case is that a small self-hosted model, trained on synthetic data in one design language (IBM's) and wrapped in a check-and-repair harness, can compete with frontier systems. Self-hosting addresses two problems they name: frontier models drift back to their own house style, and confidential content cannot leave your systems.
How it works
One adapter serves two roles. The designer turns a plan into a JSON brief: palette, type system, and for each slide its layout, exact content and a short rationale. The coder takes one slide's spec and writes pptxgenjs JavaScript, with its reasoning first. Each slide's context is fixed before any code is written, so the coder calls run in parallel. This makes the coding stage about 6 to 7 times faster. Because the brief is editable, a person or agent can change one slide without regenerating the deck.
Coder examples are about 5 times longer than designer examples. A naive data mix undertrained the designer until its examples were oversampled 5 times.
Training data came from an unnamed large open teacher. Recipes set the genre, length, layouts and directives for each deck. Every example carries a counterfactual trace that names a rejected alternative and gives the reason. Each synthesized deck was rendered and checked for overlap and overflow. Broken slides were repaired, and their traces were rewritten to explain the fix. The authors call faithfulness the hardest problem: a brief that asks for a six-by-five table but carries three bullets forces the coder to invent facts. Prompt rules rarely fixed this. Fixing the teacher's few-shot reference decks did, because the teacher copied references far more than it followed instructions.
Users steer individual slides with inline directives in the plan, such as [[make this a timeline]]. The training data covers 12 directive categories, each phrased several ways.
The harness first applies rule fixes, such as repairing a malformed color code that would turn every slide black. It then renders each slide and measures the geometry. Flagged slides go to a separate editor model.
flowchart TD
A[Coder output per slide] --> B[Rule fixes]
B --> C[Render + geometry check]
C -->|clean| F[Return slide]
C -->|overlap / clip / overflow| D[Editor model rewrites]
D --> E{Checker confirms improvement?}
E -->|yes| F2[Keep rewrite]
E -->|no| G[Keep original]Because a rewrite is kept only when the checker confirms an improvement, the harness can run on every deck without making a slide worse.
Evidence
PresentBench scores five criteria: fundamentals, visual design, completeness, correctness and fidelity. Baseline numbers come from the PresentBench paper. The comparison set includes NotebookLM, Manus 1.6 and five other systems. Across 131 decks, each generated once and scored with and without the harness, the harness adds 3.5 points on average. On Talk, where decks are narrative and speech-driven, two closed systems score higher than Palette.
Limits
- PresentBench supplies a source document, not a plan. For these runs, a separate frontier model drafted each plan and Palette built the deck from it. The score therefore reflects a frontier-plus-Palette pipeline, not Palette alone.
- No benchmark measures adherence to a specific design language, so the main selling point is untested.
- Figure-heavy decks are a known gap. Figure extraction (for example with Docling) is listed as future work.
- Adopting your own template currently means retraining. Re-skinning output from one or two existing .pptx files is only being explored.
- The post does not name the base model or the teacher, and does not give weights availability, a licence or run instructions.
- Planned work includes using the harness checks as GRPO-style RL rewards, with each slide as one rollout.
Organisations named here
- IBM Research
- IBM
- Hugging Face
Technologies named here
- NotebookLM
- Palette
- pptxgenjs
- PresentBench
Techniques named here
- LoRA
- Render-and-repair harness
- Synthetic data generation
Concepts named here
- Counterfactual reasoning traces
- Designer and coder roles
- IBM Design Language
Related in training



