How to validate a PPTX without pretending it is PowerPoint

You can validate important properties of a PPTX without installing PowerPoint, but you cannot reproduce every PowerPoint acceptance or rendering decision. A defensible pipeline checks the ZIP package, content types and relationships, XML and schema constraints, document semantics, and a rendered preview, then labels those results as structural evidence. Real PowerPoint testing remains a separate oracle for workflows that require it.

What can be validated without PowerPoint?

A .pptx is an Open Packaging Conventions package: a ZIP archive of typed parts, XML markup, binary assets and relationships. Microsoft’s Open XML SDK overview describes the package structure and the SDK’s schema validation.

That structure gives a server-side validator useful work to do without launching a desktop application:

• confirm the artifact is a readable ZIP rather than renamed bytes;
• require [Content_Types].xml and the expected root relationships;
• resolve internal relationship targets and reject missing parts;
• parse XML securely;
• check selected Open XML schema constraints;
• enforce uniqueness and range rules that matter to the generator;
• inspect required slides, notes, text, charts, tables, and media;
• render or export through a named non-PowerPoint engine for visual review.

None of those steps proves that a named version of PowerPoint will open the file without repair, render it identically, or preserve every editable behavior. The result label must say what ran.

Layer 1: package integrity

Start before XML parsing. A validator should impose compressed and expanded-size limits, entry-count limits, path normalization, and timeouts. It should reject traversal paths, duplicate entries where the ZIP library creates ambiguity, encrypted entries when unsupported, and decompression ratios outside policy.

Then check the package roots:

[Content_Types].xml
_rels/.rels
ppt/presentation.xml
ppt/_rels/presentation.xml.rels

The exact required graph depends on the document. Do not require optional parts merely because one healthy fixture contains them. Conversely, a ZIP that opens is not necessarily a valid presentation package.

Record the hash of the bytes before validation. Every later result must refer to that same hash so a regenerated artifact cannot inherit an earlier pass.

Layer 2: relationships and content types

Relationships are the graph of an Open XML package. A slide may reference a layout, image, chart, notes slide, or hyperlink through relationship identifiers. Common failures include:

• a relationship target that does not exist;
• a target that resolves outside the package when only internal content is allowed;
• duplicate or missing relationship identifiers;
• a content type that disagrees with the part;
• a presentation list that points to a missing slide;
• an orphaned part that indicates incomplete cleanup.

Not every orphan is fatal, and not every external relationship is malicious. The validator needs a declared policy. A public-web hyperlink may be allowed while an unexpected local file reference is rejected or routed for review.

Runstamp’s repair-dialog fixture work uses broken relationships as known-bad controls because they are deterministic and reviewable. A negative control is crucial: if the validator unexpectedly accepts the deliberately broken package, positive passes from that run are not trustworthy.

Layer 3: XML and schema validation

Parse XML with external entity resolution disabled and bounded resource use. Schema-aware tools can then detect invalid elements, attributes, ordering, and values for the selected Open XML format version.

Schema validation is useful, but it is not a complete compatibility oracle. Office applications contain behavior beyond what a schema expresses. Transitional documents may use legacy features. Extensions can be legal but unsupported by a particular consumer. Some package-level relationships and cross-part semantic rules are not captured by validating each XML part in isolation.

Report the exact validator, version, conformance mode, and error set. “Open XML valid” without that context is too broad.

Layer 4: semantic assertions

The generator knows what it intended to create. Use that knowledge.

If the request required twelve slides, a native chart with three series, speaker notes on slide two, and an editable table, verify those properties in the output. A generic schema validator cannot know that the chart was required or that a screenshot is an unacceptable substitute.

Useful assertions include:

• expected slide count and order;
• required text values and hyperlinks;
• stable semantic locators for named elements;
• chart series names and exact source values;
• native table or chart parts rather than raster fallbacks;
• required notes and document properties;
• no undeclared loss entries.

These checks turn validation from “is this some PPTX?” into “does this artifact satisfy this operation contract?”

Layer 5: rendering and visual comparison

A rendered preview can reveal overlap, clipping, missing fonts, wrong colors, chart-label collisions, and image-scaling mistakes that package checks miss. Pin the rendering engine, operating system, fonts, locale, and export settings. Store the preview hash and, when useful, a perceptual diff against a reviewed baseline.

Rendering is still viewer-specific. A LibreOffice export is evidence about that LibreOffice environment, not proof about PowerPoint. A headless renderer may normalize the file or omit features. Label the oracle honestly.

Visual thresholds also need negative controls. A very loose threshold can make every test pass. A very strict pixel comparison can fail on harmless antialiasing. Use region-aware review and preserve the diff artifacts rather than publishing one unexplained score.

Layer 6: real PowerPoint acceptance

When “opens in PowerPoint without repair” is a release requirement, test the exact artifact in a named PowerPoint environment. Capture whether the application opened the file, displayed a repair or content-warning dialog, saved a recovered copy, or failed to export.

Automating this oracle is harder than calling a library. Desktop dialogs, protected view, stale files, user profiles, add-ins, fonts, updates, and process crashes can all produce false observations. Qualify the harness with known-bad controls and prove that the worker opened the intended hash.

Do not let a PowerPoint pass erase structural diagnostics. The application may recover from a malformed package. “PowerPoint opened it” and “the original bytes satisfy the declared structure” are different statements.

A useful validation report

Return each layer independently:

The overall release decision follows policy. It should not overwrite the component results.

Build a fixture set that can prove failure

A reliable validator needs more than a folder of presentations that already pass. Create small fixtures for each layer and keep the intended fault unambiguous. One file can contain a broken ZIP entry; another can reference a missing slide relationship; another can violate a known Open XML constraint; another can be structurally valid but omit a required title; and another can render with an intentional overlap. Keep a matching known-good control beside each fault so the harness demonstrates both sensitivity and specificity.

Bind every result to the fixture hash and validator version. If a fixture is repaired or regenerated, its previous result should no longer apply. Store the exact command, resource limits, parser or renderer version, exit status, findings, and generated preview identity. This lets reviewers distinguish a product change from a toolchain change.

For visual checks, define the comparison contract before choosing a threshold. State the slide size, renderer, font set, reference image, ignored regions, and permitted pixel difference. A screenshot comparison can detect movement, clipping, or missing objects, but it cannot establish that PowerPoint will edit animations, charts, or embedded media correctly. Label those application behaviors as unverified until the real application test runs.

The final release rule can then be explicit. For example, require package integrity, relationship checks, semantic assertions, and bounded rendering for every candidate; require a PowerPoint acceptance pass only for workflows that promise PowerPoint-specific behavior. This avoids blocking simple generation on an irrelevant oracle while preventing a structural pass from being marketed as full PowerPoint fidelity.

CI implementation checklist

• Hash the input artifact before every oracle.
• Run package checks in an isolated, resource-bounded process.
• Disable unsafe XML resolution and validate relationship targets.
• Pin validator and renderer versions.
• Check semantic requirements from the original request.
• Store previews and diffs next to machine-readable results.
• Include known-good and known-bad controls.
• Mark PowerPoint acceptance as not_run unless it actually ran.
• Invalidate approvals whenever the artifact hash changes.

The Runstamp validation model separates structural checks from application and destination acceptance. The PowerPoint repair taxonomy documents fixture-bounded failure classes, while the evidence index explains why bytes, structure, appearance, and acceptance need separate evidence lines.