Palette Turns Slide Generation Into a Verifiable Pipeline

Generating a presentation is a useful test of whether a model can produce more than plausible text. A deck must preserve facts, organize a narrative, follow a visual system, and place every element within fixed geometry. A single weak decision can remain hidden until the file is rendered. IBM Research’s Palette approaches that challenge as a pipeline whose intermediate products can be inspected and whose final output can be checked.

The project fine-tunes a 20B open-weight model with LoRA and separates deck planning from slide coding. Its synthetic corpus contains about 1,000 decks and roughly 10,000 slides. A post-generation harness then detects layout faults and accepts a repair only when an automated check shows improvement. On 131 PresentBench decks, IBM reports that this harness raised the average score by 3.5 points. Those figures describe the published experiment, not a guarantee for another template, model, or workload.

Decompose the task before scaling the model

Palette’s most transferable idea is the interface between two roles. A designer stage produces a structured brief covering the deck’s visual system and the content and rationale for each slide. A coder stage converts one slide specification at a time into presentation code. This division reduces the number of decisions each generation must make simultaneously. It also creates a useful checkpoint: an editor can inspect the story and exact content before layout code exists.

That boundary changes the economics of correction. If the requested message is wrong, the brief can be edited without rebuilding the planning logic. If the message is right but a card overlaps a chart, only the affected slide needs another coding pass. Independent slide specifications also allow slide generation to run concurrently; the authors report a roughly six-to-sevenfold speedup for that stage.

A team adapting this pattern should make the intermediate schema explicit. Each slide record might require a purpose, source-backed claims, content blocks, layout family, visual priority, and forbidden additions. Validation should reject missing claims or unsupported table cells before any geometry is generated. The schema is not administrative overhead: it is the contract that prevents an underspecified plan from turning into invented content.

Treat synthetic data as a tested artifact

Presentation training data rarely includes the hidden reasoning or source code behind a finished slide. Palette therefore uses a larger teacher model to synthesize plans, rationales, and code under varied recipes. The important detail is that generation is followed by rendering and checking. Failed examples are repaired, and the corrected rationale becomes part of the training material.

This suggests a practical data loop for other structured-output tasks. First, vary inputs deliberately rather than sampling whatever is convenient. Second, render or execute every candidate. Third, label failures with machine-observable categories such as clipping, collision, invalid color, or ungrounded content. Finally, retain the repair only when the same check that found the defect confirms that it is gone.

Dataset balance matters as well. IBM found that coder examples were about five times longer than designer examples, so a naive token mix undertrained the designer role; the shorter examples were oversampled. For any multitask adapter, teams should inspect token exposure as well as example counts. Ten thousand short planning records do not exert the same training pressure as ten thousand long code records.

Make repair monotonic and limited

An automated editor introduces its own risk: it may fix an overlap while changing content, hierarchy, or style. Palette uses a conservative acceptance rule. A rewritten slide replaces the original only if the checker measures an improvement; otherwise the original remains. This is a form of monotonic repair, where the system refuses a proposed change that does not advance a defined condition.

The strength of this design depends on the checker. Geometry rules can reliably catch overflow and collision, but they cannot fully judge whether a narrative is persuasive or a visual metaphor is appropriate. Even factual traceability becomes difficult when a claim is implied across several source passages. The safest deployment therefore separates hard gates from advisory scores. Rendering success, file validity, and boundary violations can block output. Aesthetic quality and narrative coherence should be surfaced for review rather than treated as settled facts.

Teams should also preserve the before-and-after artifacts, the violated rule, and the checker result. That audit trail makes regressions diagnosable and creates targeted material for later training. A repair loop without provenance may improve an aggregate score while hiding repeated failure modes.

Read benchmark results in context

IBM reports that Palette ranked first on the Economics and Education portions of PresentBench, third on Talk, and second on the mean across those domains, scoring 59.7 against NotebookLM’s 60.8. The evaluation used a separate frontier model to turn each benchmark source document into a plan before Palette built the deck. That upstream dependency matters: the reported result evaluates a combined planning-and-generation workflow, not an isolated end-to-end 20B model reading raw documents.

PresentBench also does not test adherence to a particular organization’s design language. A serious adoption evaluation should add template-specific checks: approved colors and fonts, required margins, logo handling, component reuse, accessibility, and fidelity to supplied facts. Human reviewers should compare blinded outputs across representative deck types, especially narrative and figure-heavy presentations where the published results identify room for improvement.

Palette is best understood not as evidence that slide generation is solved, but as a blueprint for controllable generation. Structure the work, expose an editable intermediate representation, validate executable output, and accept automated repairs only with evidence. Those principles apply equally to diagrams, reports, interfaces, and other artifacts where correctness becomes visible only after rendering.