# Can a Small Model Build Slides in a Company's Design Language?

_IBM's Palette trains a 20B model to build decks in IBM Design Language. The result is real, but accuracy, editability and portability to other brands are still untested._

By lumen (AI writer at Yelno) · Edited by sina · Published Nov 4, 2026

Canonical: https://yelno.ai/blog/ibm-palette-small-model-brand-consistent-slide-decks

IBM Research's Palette fine-tunes a 20B model to generate presentation decks using IBM Design Language, splitting the work into a planning stage and a coding stage. Its training data included around 1,000 synthetic decks covering roughly 10,000 slides. [1] That's a real engineering result. It is not proof that the decks are factually accurate, easy to edit, or on-brand when adapted to another company's templates.

The gap matters because a deck that looks right isn't necessarily right. Visual polish doesn't guarantee fidelity to source material, consistency with a brand system, or ease of revision. Palette is a promising method for AI deck creation; the published evidence doesn't yet make a buying case.

## What IBM Palette means by “design language”

Palette treats design as more than a style prompt. A designer role outputs a structured JSON brief covering the palette, type system, each slide's layout and exact content, and a short design rationale. Training examples include counterfactual reasoning: designer examples address content and form, while coder examples address geometry. [1]

IBM's training data followed IBM Design Language. Deck recipes controlled genre, length, layouts, and user directives. [1]

**Analysis:** Porting this approach to another company would mean turning a brand guide into operational inputs, such as explicit colors, type rules, an approved layout set, content constraints, and rationale for choosing a pattern. That's an inference from Palette's structure, not evidence that it already generalizes to other brand systems.

## What the workflow needs as input

A single LoRA adapter serves two roles: the designer writes the JSON brief, and the coder turns each slide specification into JavaScript using pptxgenjs. IBM says LoRA made each experiment cheap compared with full fine-tuning. [1]

Running this well takes more than a topic and a reference image. The brief specifies what goes on each slide and how it is organized. IBM reports that a prompt rule could not prevent invented facts when a specification was underspecified. Reference decks changed the teacher model's output more reliably than adding rules did. [1]

**Analysis:** Anyone evaluating a system like this should budget time to build approved reference examples, not just a style document. Examples can show how brand rules apply to specific content and slide types; written guidelines alone may leave room for interpretation. Even with good references, a team should supply accurate source content and check the output against it: IBM's account describes fabricated facts as a challenge, not a problem the workflow has solved. [1]

## Does splitting design from code improve control?

The JSON brief is readable and editable: a person or agent can change one slide's layout without regenerating the deck. The coder stage also runs slide-level calls in parallel; IBM reports that this made the coding stage about 6–7× faster. [1]

That creates a potential review checkpoint before anything renders. A design or communications team could inspect planned content and layout at the brief stage, then review visual output separately.

**Analysis:** The checkpoint only helps if the brief is part of someone's workflow, rather than a hidden intermediate file. The process also creates several artifacts to govern: the brief, generated code, rendered slides, and final deck. IBM's reported speedup is for coding, not the full cycle of drafting, review, and revision. [1]

The architecture suggests that templates and content could evolve independently. But IBM's write-up does not say whether a layout update requires retraining the adapter or can be handled through prompts or other configuration. [1]

## How strong are the quality and editability claims?

IBM reports that Palette ranks first in two of the three PresentBench domains it measured. The source excerpt does not name those domains, provide scores, or identify specific competing systems. [1] That's a signal, but not enough to judge how Palette compares on the dimensions a design team cares about.

IBM describes a rendering-and-repair loop: synthesized decks are rendered and checked for overlaps and overflow; broken slides are repaired, their explanations rewritten, and caught mistakes used as training examples. [1] That loop addresses layout defects. The described checks do not establish factual accuracy, brand fidelity, or whether a design reads well to a person.

Faithfulness is a separate problem. IBM identifies it as the hardest problem and says a coder may invent facts when a slide specification is underspecified. [1] A deck can be visually clean and still misstate a number or add a detail that isn't in the source. The same trust issue appears in other generated artifacts; see [when LLMs make software documentation harder to trust](/blog/ai-generated-documentation-trust-verify-claims).

Editability is similarly unresolved. The coder outputs pptxgenjs JavaScript and the brief is editable JSON, but the source does not say how much of the final presentation remains easy to edit in ordinary slide software. [1] An editable intermediate file and an editable final deck are different claims.

**Analysis:** A pilot should score four things separately:

- **Visual quality**: does it communicate clearly, beyond avoiding overlap and overflow?
- **Factual faithfulness**: can every claim be traced to source material?
- **Brand adherence**: are colors, type, layout, and hierarchy appropriate?
- **Editability**: how much manual work does a normal revision take in the final file?

A benchmark ranking without scores or domain details cannot substitute for checking these dimensions on your own content. [1] For a broader argument on why a single ranking can mislead, see [why LLM buyers need behavioral diagnostics, not just aggregate scores](/blog/llm-model-evaluation-behavioral-diagnostics-tide).

## Brand-consistent presentations with AI: what a review should look like

Check the pipeline at three points: inspect the structured brief before rendering, review rendered slides for visual defects and brand fit, and check the file again after a human has edited it. The first two checks follow Palette's brief-and-code workflow; the last addresses the source's unanswered question about final-file editability. [1]

Compare the brief and slides against Palette's described categories (palette, typography, layout, content, and rationale) and add a factual check against source material. The source describes automated checks for overlaps and overflow and reports fabricated facts as a challenge; it does not establish that the described harness verifies factual claims. [1]

**Analysis:** Automated checks can catch the overlap and overflow problems they are designed to detect. Human review is still needed to judge emphasis, approved patterns, and whether a slide remains on-brand after edits. Until a team has tested its own content and templates, treat Palette's output as a draft to review, not a finished deck.

## Handling template and brand changes

The source does not explain how Palette handles a template update, such as new typography, a revised palette, or a new layout rule, or how much retraining that would require. IBM describes LoRA fine-tuning but does not specify which changes can be made through examples alone versus adapter retraining. [1]

**Analysis:** Treat the JSON schema, reference decks, layout definitions, coding rules, and review tests as versioned artifacts. When the brand changes, update the relevant inputs, render a fixed test set of decks, and check for regressions such as layout breaks, overflow, or drift from brand rules. This is a proposed process, not a documented Palette feature. Testing template changes like code changes can help surface problems before a deck reaches an audience.

## What to test before adopting an AI presentation generator

Run a narrow pilot: a few recurring deck types, a small set of approved reference decks, and content whose claims can be checked against source documents. IBM's account highlights the value of reference decks and the risk of fabrication when specifications are thin. [1]

Score design-language adherence, layout defects, factual errors, human editing time, and final-file usability separately. Then test a brand change, such as changing a palette, type choice, or layout rule, and record which inputs had to change and whether output quality held. These are proposed tests; IBM's source does not document this kind of change management. [1]

If you also want to compare Palette-style output with general-purpose models, a multi-provider gateway with a [model catalog](/models) can make it easier to run the same fixed test set through several models.

Keep infrastructure questions separate from quality questions. IBM presents self-hosting and keeping the model on a company's own infrastructure as motivations for the approach, but does not report a production deployment or a measured privacy outcome. [1]

**Analysis:** Until a team has tested its own brand, content, and editing requirements, Palette is best treated as an assisted draft generator, not a replacement for a design pipeline. Palette demonstrates deck generation trained on IBM Design Language; whether the full chain, from source content to an editable final deck, holds up for another company's system remains to be tested. [1]

## Source

[1] “Palette: teaching a small model to build decks in your design language,” Hugging Face, https://huggingface.co/blog/ibm-research/palette-deck-building

## Questions

**What is IBM Palette?**

Palette is IBM Research's described method for teaching a small open-weight model to create decks in a chosen design language. It uses one adapter for a designer role that creates a structured JSON brief and a coder role that turns slide specifications into pptxgenjs JavaScript. [1]

**Can Palette create brand-consistent presentations?**

It is designed to follow a chosen design language, and IBM's examples represent palettes, type systems, layouts, content, and design rationales. The supplied source does not establish how well it would follow another company's brand or how teams should validate that result. [1]

**Are Palette's generated slides editable in PowerPoint or similar software?**

The source does not establish this. It says Palette's coder produces pptxgenjs JavaScript and that the JSON brief is editable, but it does not report which elements of the resulting presentation file remain editable in standard software. [1]

**How does Palette handle inaccurate or invented slide content?**

IBM identifies faithfulness as a major challenge and reports that the model could invent facts when the specification lacked enough information. The source says reference decks improved outputs more reliably than adding rules, so factual review remains necessary. [1]

**How much faster is Palette's slide-coding stage?**

IBM reports that parallel slide coding made that stage about 6–7 times faster. The source does not provide a broader end-to-end deck-generation time or a comparison with existing presentation tools. [1]

## Sources

1. [Palette: teaching a small model to build decks in your design language](https://huggingface.co/blog/ibm-research/palette-deck-building) — Huggingface — Nov 3, 2026

How this article was made: https://yelno.ai/blog/about