Decks as data
Asking a model to produce a PowerPoint file gives you something hard to edit and impossible to govern. I built a deck generator that treats a presentation as structured data first. Sixteen components, twenty tests, and one rule that settled every argument.
Corporate presentations are a perfect enterprise AI use case on paper. Everyone makes them, they follow a house style, and most of the effort is formatting. In practice, asking a model to “make a PowerPoint” goes badly. The file looks fine until someone tries to edit it, and the company style drifts a little more with every deck.
So I built it the other way round. The model never writes a file. It writes data, and code turns the data into slides.
Figure 1. Two inputs: an existing deck, from which the style is extracted, and a chat request, from which an LLM drafts the content model. Sixteen components render that model to HTML for review, and to PowerPoint or PDF only when someone downloads.
The engine
The engine, corp-present, is open source under Apache-2.0.
| Part | What it is |
|---|---|
| Content model | A YAML or JSON description of every slide: type, text, data, chart values |
| Components | 16 slide types, each with a paired HTML renderer and PowerPoint renderer |
| Charts | Hand-authored SVG, so they render the same everywhere |
| PowerPoint output | A pure-Python emitter. No headless browser, no screenshots |
| Style extraction | Reads a PDF or PPTX and pulls out layout, colours and type into a profile |
| Tests | 20, all passing |
The product on top
Corpy wraps the engine in a web app with two modes, picked from a dropdown in the chat box itself.
| Mode | Who can use it | What it does |
|---|---|---|
| Extract | Admins only, in an enterprise deployment | Upload a reference deck, save the company style |
| Create | Everyone | Describe the deck in chat, review it in HTML, download PPTX or PDF |
The rule that settled every argument
Whenever visual ambition and editability conflicted, editability won. A slide that looks stunning but arrives in PowerPoint as a flattened picture is worthless to the person who has to change one number before the meeting. So every component has to produce native, editable PowerPoint objects.
Why this is the right pattern beyond decks
| Generate files | Generate data, render files |
|---|---|
| Hard to edit after generation | Edit the data, re-render |
| Style drifts with every output | Style is enforced by code |
| Hard to review or diff | The content model can be reviewed and versioned |
| Model has to be good at the file format | Model only has to be good at content |
The same applies to reports, specifications, dashboards and engineering documents. Let the model produce structure. Let deterministic code produce the artefact. It is cheaper, more governable and far easier to trust.