Palette: Training a Small Model to Build Decks in a Design Language

Palette: Training a Small Model to Build Decks in a Design Language

Published November 3, 2026

Asking a frontier model to create a slide deck usually produces a polished result. Asking for ten decks often produces variations on the same visual style: familiar defaults, consistent layouts, and a recognizable AI-generated appearance. That becomes a problem when the deck needs to follow an organization's own template or design language. Confidential content can also make external processing unsuitable.

These constraints suggest using an open-weight model that runs on owned infrastructure and is trained on an organization's design system. However, smaller models that can realistically be self-hosted often struggle with presentation generation. Their output may contain unreadable titles, overflowing text, and overlapping shapes.

Palette explores whether a small open-weight model, trained on synthetic data in a specific design language and supported by an automated checking system, can approach the performance of frontier models while preserving ownership of the output. The system fine-tunes a 20B model to create decks through two roles: a designer that plans the presentation and a coder that draws each slide. Its training data follows the IBM Design Language. On PresentBench, Palette ranks first in two of the three measured domains.

Why decks are difficult for small models

Creating a slide deck requires several capabilities that smaller models often handle poorly.

The model must lay out a slide without seeing it. Palette does not draw slides directly. It writes code that places every element at an x-coordinate, y-coordinate, width, and font size. Determining whether a 75-character title fits across two lines at 56pt requires geometric reasoning, and the model may not discover an error until the code is rendered. This often leads to overlapping elements and text that extends beyond the slide.

The model makes editorial and geometric decisions at the same time. It must decide what each slide should communicate and how to communicate it, such as whether to use a chart or table and what information to omit. It must also position every element accurately. A single process has to make both kinds of decisions across 10 to 20 slides while maintaining consistent colors, typography, and layouts.

Existing data rarely captures how decks are made. Many finished presentations are available, but they usually do not include the reasoning behind design decisions or the code used to create each slide.

A designer and a coder

People generally do not create a deck in one step. They first determine the story, including the number of slides, the purpose of each slide, and whether each topic should use a chart, table, or another format. They then build the slides individually.

Palette follows the same division of work through two roles served by a single LoRA adapter:

• Designer: Reads the plan and produces a structured JSON brief containing the palette, type system, and each slide's layout, exact content, and short design rationale.
• Coder: Reads one slide specification from the brief and writes the pptxgenjs JavaScript that draws the slide, preceded by its reasoning.

This division gives each role a narrower responsibility. The designer handles editorial judgment, while the coder handles geometry. The intermediate brief is readable and editable, allowing a person or agent to change an individual slide without regenerating the entire deck.

Because each slide's context is fixed before code generation begins, coder calls can run in parallel, one per slide. This makes the coding stage approximately 6 to 7 times faster.

Palette uses LoRA rather than full fine-tuning. This teaches a format and skill on top of an existing capable model without altering everything the base model already knows, while keeping experiments relatively inexpensive. One training issue was that coder examples were approximately five times longer than designer examples. A naive mixture therefore undertrained the designer role, so designer examples were oversampled by a factor of five.

Synthesizing decks and reasoning

There is no public corpus containing presentation plans, design decisions, and slide-generation code. Palette therefore generates training data with a large open teacher model.

Each deck begins with a recipe that specifies its genre, length, layouts, and any user directives. This gives control over the coverage of the dataset. Plans range from organized outlines to raw content dumps, teaching the model to select, condense, and structure information. The team generated approximately 1,000 decks covering about 10,000 slides.

Each example also includes reasoning written as a counterfactual. The trace considers an alternative and explains why it was rejected, helping the model learn the principle behind a decision rather than merely copying the decision.

The designer reasons about content and form. For example:

"Revenue for four quarters, with one clear upward trend. I considered a table, but the point of this slide is the trend, not the exact figures, so a bar chart makes it visible at a glance."

The coder reasons about geometry:

"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."

The teacher model alone does not guarantee high-quality data. Every synthesized deck is rendered and checked for overlaps and overflow using the same checker used during inference. Broken slides are repaired, and their reasoning is rewritten as a counterfactual describing what was wrong with the original layout and why the repair works. Errors detected by the checker become additional training examples.

Faithfulness was one of the most difficult problems. A slide containing facts that were not present in the input is a serious failure, and prompt rules alone did not prevent it. For example, if a brief requests a six-by-five table but contains only three bullets, the coder may invent the missing information.

Reference decks proved more effective than additional rules. Correcting a reference deck reliably changed the teacher's output, while adding another instruction often did not. When shown several reference decks in its prompt, the teacher copied them more readily than it followed abstract instructions.

Steering a deck with plain-English directives

Users may want detailed control over individual design decisions, such as requesting a chart instead of a table, specifying a color, or asking for a darker cover. Palette supports this through directives, which are short instructions placed directly in the plan and enclosed in [[ ]]:

## Rollout plan
- March: pilot with two teams
- May: security review complete
- July: rollout to all of engineering
- September: company-wide launch
- November: first adoption review
[[make this a timeline]]

The designer incorporates each directive into the brief, and the coder applies it while drawing the slide. Without the directive, these milestones might reasonably appear as a table. With [[make this a timeline]], the model creates a timeline instead.

The model follows directives because the training data includes them. Data recipes cover 12 directive categories, with each category expressed in several ways so the model learns the intended meaning rather than memorizing a fixed phrase.

A check-and-repair harness

Even a trained model can produce a defective slide, such as a title rendered in the same color as the background or two boxes placed on top of each other. Palette therefore sends every deck through a harness before returning it.

The process is:

1. The designer creates the structured brief.
2. The coder writes each slide's code in parallel.
3. Simple rules correct known problems, such as malformed color codes that could turn every slide black.
4. Each slide is rendered and measured.
5. A geometry checker identifies overlapping, clipped, or overflowing text.
6. Flagged slides are sent to a separate editor model, which rewrites the slide's code.

A rewritten slide is retained only when the checker confirms that it improved. Otherwise, the original remains. This makes the harness safe to run on every deck because a repair can improve a slide but cannot replace it with a measurably worse version.

To measure the effect, the team generated each PresentBench deck once and scored it with and without the harness. Across 131 decks, the harness improved the score by an average of 3.5 points.

Evaluation

Palette was evaluated on PresentBench, which scores generated decks on five criteria: fundamentals, visual design, completeness, correctness, and fidelity.

PresentBench supplies a source document rather than a presentation plan. For these runs, a separate frontier model created a plan from each source document, and Palette built the deck from that plan. The results cover three domains, with baseline numbers taken from the PresentBench paper.

Palette ranks first in Economics and Education, and third in Talk. It ranks second across the three-domain average, scoring 59.7 compared with NotebookLM's 60.8. This places it 1.1 points behind NotebookLM and ahead of the rest of the evaluated systems as a single 20B open-weight model.

The results vary by domain. Palette performs best when structured content and numerical accuracy determine much of the score. Talk decks are more narrative and speech-driven, and two closed systems score higher there.

PresentBench evaluates general deck quality, but not whether a presentation follows a particular design language. No benchmark covering that capability was identified, leaving it as an open evaluation gap.

Next steps

The harness already calculates inexpensive, verifiable signals, including whether a slide renders, whether elements overlap or overflow, and whether every fact can be traced back to the brief. These checks currently repair output after generation.

The next step is to use the same checks as rewards for reinforcement learning, allowing the model to avoid these mistakes during generation. Since the coder works on one slide at a time, each slide is a short, independently verifiable rollout that is well suited to GRPO-style training.

The team also plans to improve figure-heavy decks by extracting figures from source documents, potentially with Docling, and placing them through the harness. Another area under investigation is a lighter way to apply existing templates by re-skinning output from one or two .pptx files without retraining the model.

Lessons from Palette

Palette suggests several techniques that may apply to other tasks whose outputs can be checked in code, including charts, diagrams, and user-interface layouts:

1. Include reasoning in the data. Training on why a decision was made, including which alternatives were rejected, teaches more than training on the final decision alone.
2. Correct examples before adding rules. Adding another prompt rule rarely fixed teacher-model errors. Correcting the reference examples had a stronger effect because the teacher copied them more reliably than it followed additional instructions.
3. Make repairs safe by default. A repair that is retained only when it produces a measurable improvement can be applied to every output.
4. Build the checker first. The checker makes the training data more trustworthy and helps ensure that generated outputs are safe to use.