Palette: teaching AI your slide style takes more than a prompt

You can ask an AI to make a presentation, but getting ten slides that look as if your team made them is a different job. The colours may be close while the typography wanders, a title clips the edge, or a chart lands on top of its caption. IBM Research's Palette is an interesting attempt to treat that as an engineering problem: teach a smaller model a design language, give it a plan, then check what it actually renders.

This is research, not a slide-making product you can download and put to work today. Still, the workflow offers useful ideas for anyone building branded reports, charts or document tools.

Separate the story from the drawing

Palette uses one fine-tuned 20-billion-parameter model in two roles. First, a “designer” turns the request into a structured JSON brief: palette, type choices, slide-by-slide content, layout and a short reason for each choice. Then a “coder” takes each slide specification and writes PptxGenJS code to draw it.

That split matters. Deciding whether a trend deserves a chart is not the same problem as calculating whether a 60-character title fits above it. The brief is also editable: change one slide's direction without asking the model to rethink the whole deck. Once the plan is fixed, the slides can be coded in parallel. IBM reports that this made its coding stage about six to seven times faster; that's a claim about that stage of its workflow, not the time to make a finished presentation from scratch.

The training set was synthetic: about 1,000 decks and 10,000 slides, built around the IBM Design Language. Examples included not only choices but explanations of why an alternative was rejected. IBM used LoRA fine-tuning rather than retraining the whole model. It also found a practical data-balancing problem: the code examples were much longer than the design examples, so it oversampled the latter to keep the planning role from being neglected.

Let the rendered slide argue back

A model can produce perfectly plausible code for a visibly broken slide. Palette therefore renders every slide and checks geometry: overlaps, clipping and overflow. Simple faults get rule-based fixes; flagged slides go to an editor model. A rewritten slide is kept only if the checker measures an improvement. Otherwise, the original stays.

On 131 PresentBench decks, IBM says that repair harness added an average 3.5 points. The useful lesson is not that a checker can judge every design choice. It is that measurable defects should be measured after rendering, and repairs should earn their place. A page that compiles is not necessarily a page someone can read.

Facts need a separate check. IBM describes a failure where a requested table had more cells than the source material supplied, so the model invented entries. Reference examples helped more than another rule in the prompt. Even then, a neat deck is no guarantee that every statement traces to the input.

What the benchmark does — and doesn't — show

IBM reports Palette ranked first in PresentBench's Economics and Education domains, third in Talk, and second across the three-domain mean. Its reported mean was 59.7, behind NotebookLM's 60.8. Those are the researchers' results, not an independent reproduction here.

There is an important catch in the setup: for the benchmark, a separate frontier model prepared the plans from source documents. Palette then built the decks. That does not prove a fully local, end-to-end workflow. PresentBench also scores deck quality, not whether a deck faithfully follows a particular company's visual identity. IBM says a benchmark for that last question is still missing.

What developers can borrow now

If you build a report generator, start with a structured brief that separates content decisions from layout instructions. Make it easy to inspect and edit before rendering. Then add checks that your software can actually verify: text within bounds, elements not colliding, charts tied to supplied data, and output that opens correctly. Keep a repair only when it improves those checks. Finally, have a person review factual accuracy and the less measurable parts of design.

The skills worth exploring are ordinary but powerful together: document schemas, programmatic slide or chart generation, rendering tests, evaluation datasets and, if the use case justifies it, small-model adaptation with LoRA. Palette's bigger point is that consistent output comes from a pipeline with explicit handoffs and feedback, not a magic “use our brand style” sentence at the end of a prompt.