Can a 20B model build slide decks that match your design language?

Why small models break decks

A slide deck looks simple. Making one asks a model to do three things small models are bad at.

A model lays out the slide without seeing it. It writes code that places every element at an x, y, width and font size. Whether a 75-character title fits on two lines at 56pt is arithmetic the model does in its head. It only finds out it was wrong after the code renders. Small models get this wrong often. Overlapping shapes and text running off the slide come from this.

Two kinds of decisions happen at once. Deciding what each slide says and how to show it is editorial judgment. Placing it precisely is geometry. A single pass has to do both across 10–20 slides while keeping palette, type, and layout consistent.

Nothing shows how decks get made. Plenty of finished decks exist. The rationale behind design choices and the code that produced them does not.

Splitting the work like a human

Nobody makes a deck in one pass. You decide the story first. Only then build each slide. Palette splits the work the same way into two roles served by a single LoRA adapter.

The designer reads the plan and writes a structured JSON brief. The brief contains the palette, the type system, and for each slide its layout, exact content, plus a short design rationale. The coder takes one slide's spec from the brief and writes the pptxgenjs JavaScript that draws it. Each role now makes one kind of decision. The designer handles editorial judgment. The coder handles geometry.

The brief between them is readable and editable. A person or an agent can change one slide's layout without regenerating the deck. Because every slide's context is fixed before any code is written, the coder calls run in parallel. One per slide. That makes the coding stage about 6–7× faster.

Training used LoRA rather than full fine-tuning. It teaches a format and a skill on top of a capable base without disturbing what the base already knows. Each experiment stayed cheap. One lesson: coder examples are about 5× longer than designer examples. A naive mix undertrained the designer until the team oversampled its examples 5×.

Synthetic data and a repair harness

No public corpus of plans, design decisions, and slide code exists. The team generated one with a large open teacher. Each deck starts from a recipe that sets genre, length, layouts and user directives. Plans range from tidy outlines to raw content dumps. The model learns to cut and condense.

The team generated around 1000 decks covering roughly 10,000 slides. Every example carries reasoning written as a counterfactual. The trace weighs an alternative and says why it was rejected. The model learns the rule behind a choice, not just the choice.

Content and form are the designer's concern. Geometry is the coder's domain. The teacher alone doesn't make the data good. The loop around it does. Every synthesized deck is rendered and checked for overlaps and overflow by the same checker the harness uses at inference. Broken slides are repaired. Their reasoning is rewritten as the same kind of counterfactual covering what the original layout got wrong and why the fix works. Each mistake the checker catches becomes a better training example.

Faithfulness was the hardest problem. The worst failure is a slide with facts that weren't in the input. A prompt rule can't prevent it. If a brief asks for a six-by-five table but carries only three bullets, the coder has to invent the rest. What fixed it was reference decks, not rules. Fixing a reference reliably changed the teacher's output. Adding a rule rarely did. The teacher sees a few reference decks in its prompt and copies them far more than it follows instructions.

Steering with plain English directives

Users want finer-grained control over specific design choices. A chart instead of a table. A particular color. A darker cover. Palette lets them ask for these with directives. Short instructions written directly in the plan and wrapped in [[ ]].

Directives get built into the brief by the designer. The coder follows them when drawing the slide. Without the directive the model would reasonably show milestones as a table. With it the model draws a timeline instead. The model follows directives because it was trained to. The data recipes include directives from 12 categories. Each phrased several different ways so the model learns the intent rather than a fixed phrase.

The check-and-repair harness

Even a well-trained model sometimes produces a broken slide. A title in the same color as the background. Two boxes stacked on top of each other. Palette doesn't return the model's output directly. Every deck goes through a harness first.

Simple rules fix known mistakes. A malformed color code that would otherwise turn every slide black. Then each slide is rendered and measured. A geometry checker flags text that overlaps, gets clipped or runs off the slide. Flagged slides go to a separate editor model which rewrites that slide's code. The key rule: a rewrite is kept only if the checker confirms the slide improved. Otherwise the original stays. That makes the harness safe to run on every deck. It can fix a slide. It can't make one worse.

To measure its effect the team generated each PresentBench deck once and scored it with and without the harness. Across 131 decks the harness adds 3.5 points on average.

Evaluation on PresentBench

Generated decks are scored on five criteria: Fundamentals, Visual design, Completeness, Correctness, and Fidelity. PresentBench provides a source document rather than a plan. For these runs a separate frontier model drafted each plan from its document. Palette built the deck from that plan.

Palette ranks first on Economics and Education. Third on Talk. Second on the three-domain mean. Palette does best where structured content and numeric accuracy decide the score. On Talk where decks are narrative and speech-driven two closed systems score higher. Across the three domains Palette places second, 1.1 points behind NotebookLM (59.7 vs 60.8) and ahead of the rest of the field as a single 20B open-weight model.

The benchmark measures whether a deck is good. Not whether it follows a specific design language. The team is not aware of a benchmark that does. That gap remains.

What comes next

The harness already computes cheap verifiable signals. Does the slide render. Does anything overlap or overflow. Does every fact trace back to the brief. Today they repair output after generation. Next they want to use the same checks as rewards for reinforcement learning. So the model stops making these mistakes in the first place. Because the coder works one slide at a time each slide is a short independently checkable rollout. A natural fit for GRPO-style training.

They also want to close the gap on figure-heavy decks by extracting figures from source documents with Docling and placing them with the harness. And they're exploring a lighter way to bring your own templates. Re-skinning output from one or two of your existing .pptx files without retraining.

What the project taught them

Building Palette taught a few effective methods that extend to other tasks whose output has a structure you can check in code. Charts. Diagrams. UI layouts.

Put the reasoning in the data. Training on why a choice was made including what was rejected teaches more than the choice alone. Fix the examples before adding a rule. When the teacher got something wrong the first instinct was to add a rule to its prompt. That rarely helped. The teacher copied its reference decks far more than it followed instructions. Fixing the reference was what actually changed its output. Make repairs safe by default. A fix kept only when it measurably helps can run on every output. Build the checker first. It's what makes the data trustworthy and the outputs safe to ship.