AI Slide Deck Generation: How Palette Builds Better Decks

The model has to reason about geometry without seeing the result

Palette generates JavaScript for pptxgenjs, which is used to create PowerPoint files. The model outputs positions, dimensions, and font sizes. If a title is too long for its area, it can wrap into whatever comes next. If a shape lands a few points too low, it can overlap something else.

That's not really a "write better prompts" problem. The model has to translate code into a rendered layout and think through what its choices will do. Smaller models are more likely to stumble here, even when the code runs successfully and the slide ends up looking broken.

Editorial decisions and layout decisions compete

A good deck needs editorial judgment: what goes on each slide, what gets cut, and whether the story is clearer as a chart than a table. It also needs solid implementation. Asking one model to do both editorial decisions and exact layout in one pass forces it to keep too many things consistent at once.

There's also a data mismatch. Completed presentations are easy to find, but they usually don't include the underlying rationale for each layout choice - or the code that produced it. A model can learn the "surface" patterns of decks without learning why a designer placed things the way they did.

The practical takeaway is that slide generation should be treated like a workflow, not a one-shot prompt. Palette is built around that: separate decisions, make them explicit, and check what the rendered result actually looks like.

The designer creates an editable brief

The designer reads the input plan and produces a structured JSON brief. It includes the palette and typography, then describes each slide's content, layout, and design rationale. That matters because the key decisions show up before any slide code is written.

This brief isn't just a technical step. It gives you a place to make targeted edits. If one slide should be a timeline instead of a table, you can change the layout through the brief rather than forcing the model to regenerate the whole deck. The trade-off is extra work: another stage, and something that needs validation. But the benefit is real - changes are easier to isolate and understand.

The coder handles one slide at a time

The coder takes a slide specification and writes the corresponding pptxgenjs code, after reasoning about the implementation. Because the brief locks in the slide context first, each slide can be coded independently - and in parallel.

IBM Research reports this split speeds up the coding stage by about 6-7× compared with doing it sequentially. The split also narrows what each part can get wrong. The designer handles content and intent; the coder handles geometry. Errors still happen, but it's easier to pinpoint whether something went off because the brief was wrong or because the slide code placed elements incorrectly.

Directives provide a lightweight control surface

Users can add short instructions inside the plan, using double brackets. For example, [[make this a timeline]] nudges the rollout milestones toward a timeline instead of a table. Palette's training recipes include directives across 12 categories - things like layout, tone, audience, order, omission, and emphasis.

It's a control mechanism, not a promise. The system still has to interpret the directive in context, preserve the underlying facts, and only change the presentation. The value is that you can request a specific preference without rewriting the entire prompt or rebuilding templates.

Training examples include reasons, not just answers

Each synthetic example includes reasoning written as a counterfactual - what alternative was considered and why it was rejected. A designer might explain that a bar chart was chosen because the point is the quarterly trend, not the exact numbers. A coder might explain that a title was reduced in size because a larger font would wrap and collide with content below.

The goal is to teach a decision rule alongside the result. That's useful beyond slide decks: if a model only sees final outputs, it can imitate patterns without learning when they apply. Explanations add context for trade-offs, but they still need checking - especially if you're relying on them to justify correctness.

Synthetic data needs a quality-control loop

A teacher model doesn't automatically produce good training data. Palette renders each deck it generates and checks for issues like overlap and overflow. When slides are broken, they get repaired, and their reasoning is rewritten to explain what failed and why the fix works. The same checker-and-repair process is used both during training-data generation and during later generation runs.

IBM Research also found that prompt rules alone were weak at preventing unsupported facts. Using a reference deck improved the teacher's reliability more than adding another instruction. The lesson is pretty direct: improve the examples the model will imitate before you start piling on more rules.

Palette fine-tunes the model with LoRA rather than updating every weight. LoRA keeps the training cheaper by adding a small set of trainable parameters on top of a base model, which helps preserve what the base model already knows. One practical adjustment was needed: coder examples were about five times longer than designer examples. Without oversampling, a simple mix would underrepresent the designer task, so designer examples were oversampled fivefold.

Deterministic checks catch visible defects

The harness starts with known, predictable errors. For instance, a malformed color code could cause slides to appear black. After that, slides are rendered and inspected for text that overlaps, gets clipped, or ends up outside the slide boundaries.

These checks don't tell you whether a deck is persuasive, factually complete, or appropriate for its audience. They focus on a narrower category of problems - ones with signals the system can verify. That boundary is important. A deck can pass geometry checks and still make a weak argument.

Repairs are accepted only when they improve the result

When a slide is flagged, a separate editor model rewrites its code. The harness then checks the revised slide. The system keeps the repair only if the checker confirms an improvement; otherwise, it leaves the original output in place.

That acceptance rule makes automatic repair safer to run repeatedly. Without it, a repair model might fix one overlap and introduce another. With the gate, repairs only replace output when they pass a measurable improvement criterion. The limitation is obvious too: the gate is only as good as the checks it uses, so it can't prevent every kind of visual or semantic regression - but it does reduce the risk of making known geometry problems worse.

Across 131 PresentBench decks, IBM Research reports the harness improved scores by an average of 3.5 points. That supports having a check-and-repair stage, but it's not a universal guarantee. Those gains come from a specific set of decks and a particular evaluation setup.

The broader engineering lesson is straightforward: build the checker early. It helps improve training examples, track recurring model failures, and make repairs safer to accept. Without it, teams have less confidence both in the training data and in what they plan to ship.

Open weights can change the deployment trade-off

For organizations, the value of a 20B open-weight model isn't just benchmark placement. If you run it on infrastructure you control, it's easier to enforce company-specific design rules and keep sensitive source materials inside your environment. That can matter for internal strategy decks, client work, or regulated information.

But self-hosting isn't automatically a privacy policy. You still have to manage access controls, logging, storage, model updates, and the upstream systems that feed content into the model. And training the model on a design language doesn't guarantee brand compliance by itself. You'll still need review processes and clear rules for what the model can generate and distribute without human approval.

Benchmark scores leave important questions open

PresentBench measures deck quality, but the Palette authors note it doesn't measure whether a deck follows a specific design language. It's possible to score well on general presentation criteria and still miss a company's typography, tone, or visual conventions.

It also doesn't answer whether Palette handles every source document well, or how well it behaves in different deployment environments. The project's next steps point to a better feedback loop: the harness already checks whether slides render, whether elements overlap or overflow, and whether facts trace back to the brief. The team wants to use these signals as rewards during reinforcement learning, so the model learns to avoid errors rather than relying on fixes afterward.

They're also exploring figure extraction from source documents and adapting output to match existing PowerPoint templates without retraining.

Key takeaways for teams evaluating AI deck generation:

• Treat deck creation as a pipeline with separate content, design, and rendering stages.
• Use an editable intermediate brief so people can change individual slides.
• Generate synthetic examples with rationale, then render and validate them before training.
• Automate checks for measurable defects, and accept repairs only when they pass those checks.
• Evaluate brand fit and factual fidelity separately from general visual quality.