Why AI-generated PPTX triggers the repair dialog

If Microsoft's own OpenXML SDK — a purpose-built library maintained by the Office team — has produced files that trigger PowerPoint's repair dialog (issue #1226, issue #1955), an LLM generating raw OOXML has zero chance of doing better. This article explains the seven technical causes of PPTX corruption, why sequential token generation is architecturally incompatible with OOXML's constraints, and the pattern that eliminates the problem entirely.

What is inside a PPTX file?

A PPTX file is not a single document — it is a ZIP archive containing 15–40 interconnected files. Unzip any .pptx and you will find a structure like this:

presentation.pptx/
├── [Content_Types].xml          ← declares every part's MIME type
├── _rels/
│   └── .rels                    ← root relationships
├── ppt/
│   ├── presentation.xml         ← slide list, size, settings
│   ├── _rels/
│   │   └── presentation.xml.rels ← maps rId → slide/master parts
│   ├── slides/
│   │   ├── slide1.xml           ← shapes, text, references
│   │   └── _rels/
│   │       └── slide1.xml.rels  ← slide → layout, images, charts
│   ├── slideLayouts/
│   │   └── slideLayout1.xml
│   ├── slideMasters/
│   │   └── slideMaster1.xml
│   ├── theme/
│   │   └── theme1.xml
│   └── charts/                  ← each chart embeds an Excel workbook
│       ├── chart1.xml
│       └── _rels/
│           └── chart1.xml.rels  ← references embedded .xlsx
├── ppt/embeddings/
│   └── Microsoft_Excel_Worksheet1.xlsx  ← chart data source
└── docProps/
    ├── app.xml
    └── core.xml

Every .rels file maps relationship IDs (rId1, rId2, ...) to target parts. The [Content_Types].xml file declares the MIME type of every part in the archive. The presentation.xml file references slides by relationship ID, and each slide references its layout, master, images, and charts by relationship ID.

PowerPoint validates this entire graph on open. If any reference is broken — an rId pointing to a part that does not exist, a part not declared in [Content_Types].xml, or XML elements in the wrong order — PowerPoint shows the repair dialog.

Seven causes of the repair dialog

1. Element ordering violations

OOXML's XSD schema specifies that child elements must appear in a particular order within their parent. This is the most common and most subtle cause of corruption.

<!-- CORRECT: sldLayoutIdLst before AlternateContent -->
<p:slideMaster>
  <p:cSld>...</p:cSld>
  <p:sldLayoutIdLst>...</p:sldLayoutIdLst>
  <mc:AlternateContent>...</mc:AlternateContent>
</p:slideMaster>

<!-- WRONG: reversed order → repair dialog -->
<p:slideMaster>
  <p:cSld>...</p:cSld>
  <mc:AlternateContent>...</mc:AlternateContent>
  <p:sldLayoutIdLst>...</p:sldLayoutIdLst>
</p:slideMaster>

According to OpenXML SDK issue #1226, this exact element ordering reversal happened in Microsoft's own SDK between versions 2.11 and 2.18. The AlternateContent and sldLayoutIdLst elements were swapped, causing repair dialogs for every generated file. If the official SDK maintained by the Office team gets element ordering wrong, the complexity of this constraint should be clear.

2. Orphaned relationship IDs

Every reference between parts uses a relationship ID. A slide references its layout as rId1 in slide1.xml.rels. If the slide XML contains r:id="rId3" but slide1.xml.rels has no entry for rId3, PowerPoint cannot resolve the reference and triggers repair.

3. Missing content type declarations

The [Content_Types].xml file at the root of the ZIP must declare every part. Add a chart to ppt/charts/chart1.xml without adding <Override PartName="/ppt/charts/chart1.xml" ContentType="application/vnd.openxmlformats-officedocument.drawingml.chart+xml"/> to the content types file, and PowerPoint rejects the file.

4. Chart workbook mismatches

PPTX charts embed a complete Excel workbook (.xlsx) as their data source. According to OpenXML SDK issue #240, streaming data to the embedded package part — even using the official SDK — corrupts the PowerPoint file. The chart XML (chart1.xml) references cells by range, and those ranges must match the structure of the embedded workbook exactly. Any mismatch produces a repair dialog.

5. Invalid namespace prefixes

OOXML uses multiple XML namespaces (a: for Drawing, p: for Presentation, r: for Relationships, mc: for Markup Compatibility). If a namespace prefix is used without declaration, or the wrong namespace URI is bound to a prefix, the file is invalid XML before PowerPoint even attempts to parse it.

6. Duplicate IDs

Slide IDs in presentation.xml, shape IDs in each slide's shape tree, and relationship IDs in each .rels file must be unique within their scope. Generating two slides with the same id="256" or two shapes with the same id="2" triggers validation failures.

7. Malformed ZIP structure

OOXML files use ZIP as the container format. The ZIP archive must use the correct compression method (Deflate), must not include extraneous entries, and must end with a valid Central Directory record. Generating the ZIP incorrectly — wrong compression ratio, missing entries, or incorrect byte offsets — produces a file that PowerPoint cannot parse at all.

Does even the official SDK get it wrong?

The most compelling evidence that raw OOXML generation is fragile: Microsoft's own OpenXML SDK has a history of producing files that trigger the repair dialog.

• Issue #1226 (Nov 2022): Element ordering regression — AlternateContent and sldLayoutIdLst reversed in versions 2.11–2.18. Every file generated with the affected versions triggered repair. The fix was a single-line element reorder.
• Issue #1571 (Nov 2023): A developer creating a PPTX with tables using the SDK received the repair dialog, and after repair the presentation was empty — all content destroyed.
• Issue #1955 (Aug 2025): Creating a "simple blank pptx" with the SDK triggered the repair dialog. A blank file. With the official SDK.
• Issue #1948 (Jun 2025): Adding a video element via the SDK corrupted the file. The video appeared after repair but the repair dialog triggered on every open.
• Issue #240 (Aug 2017): Streaming chart data to an embedded package part corrupted the PowerPoint file.

These are bugs in a purpose-built SDK maintained by the team that designed the OOXML specification. The SDK has full access to the XSD schemas, comprehensive test suites, and years of production hardening. It still gets element ordering, relationship management, and embedded data wrong. A general-purpose LLM generating raw XML tokens has none of these safeguards.

Why can't LLMs solve this?

LLMs generate tokens sequentially — each token is predicted based on the tokens that came before it. OOXML requires global consistency across 15–40 files in a ZIP archive. These are fundamentally incompatible requirements.

Consider what an LLM would need to do to generate a valid PPTX with one chart:

• Generate [Content_Types].xml declaring all parts that will exist — but it hasn't generated those parts yet
• Generate presentation.xml.rels with relationship IDs that will match references in slides not yet generated
• Generate slide1.xml with a chart reference (r:id="rId2") that matches an entry in slide1.xml.rels not yet generated
• Generate chart1.xml with cell references (Sheet1!$A$1:$B$4) that match the structure of an embedded workbook not yet generated
• Generate the embedded .xlsx workbook (itself a ZIP archive of XML files) with data that matches the chart's references
• Assemble everything into a ZIP archive with correct byte offsets

Every step requires information from future steps. The content types file must know about parts that do not yet exist. The relationship files must know about targets that have not been generated. The chart XML must reference cells in a workbook that has not been created. This is a forward-reference problem that sequential token generation cannot solve.

This is not a model quality issue. GPT-6 and Claude 5 will have the same architectural limitation. Better models will produce more plausible XML — but "more plausible" is not "valid." A file that is 99.9% correct OOXML but has one misordered element still triggers the repair dialog.

The architectural solution

The solution is a structured JSON layer: separate content (what the AI decides) from format compliance (what a rendering engine guarantees). The quick start shows the boundary in code.

The AI produces JSON — slide count, text, chart data, table rows — and the rendering engine handles everything that requires global consistency: element ordering (XSD-compliant), relationship ID assignment (unique and cross-referenced), content type declarations (complete), embedded workbook creation (synchronized with chart XML), namespace declarations (correct URIs), and ZIP assembly (valid Deflate compression with correct Central Directory).

If the JSON is structurally valid (correct types, required fields present), the output file is guaranteed to open without the repair dialog. The engine's test suite runs against every PowerPoint version and the OOXML Validator extension. For working code, see the JSON-to-PPTX quickstart or the MCP server guide.

For the broader architecture, read the PPTX package guide and MCP server guide.