Launch Claim Brief¶
This page translates the current proof files into copy that is safe to use in README text, launch posts, comparison pages, and migration docs.
Current Position¶
WolfXL should be described as Rust-backed, openpyxl-compatible Excel automation for the tracked supported openpyxl API surface. The measured supported-scope SOTA gate is currently green for the current measured clean-source lanes. Benchmark source relevance: current. No weak speed or memory rows under the configured gates. Memory pass/fail applies the configured absolute RSS noise tolerance. Raw cross-surface Rust rows remain disclosed outside the selected gates. The current clean-wheel benchmark rerun passed its configured gates, while the registered cross-platform artifact matrix and broader all-future-surface SOTA claim remain gated.
The broader all-future-surface SOTA claim is still not ready. That means launch copy should not imply that every possible workbook, Excel feature, click path, rendering variant, or future OOXML surface has been exhausted.
The five broad claim boundaries are:
| Boundary | Still-unproven examples |
|---|---|
| Registered release-artifact lanes are proven, but not every future package route or installer. | future wheel lanes, installer/resolver contexts, alternate distribution channels, and workflow trigger paths. |
| Openpyxl still has ecosystem maturity and long-tail workflow history. | Unsupported openpyxl APIs, unvalidated business templates, OLAP/external pivot caches or pivot visuals, adjacent spreadsheet surfaces, and organizational dependency familiarity. |
| High-risk render variant space remains open-ended. | Unseen feature-edit combinations, template-specific visual acceptance, and Excel renderer version variants. |
| Click-level Excel interaction variant space remains open-ended. | Slicer/timeline/control variants, prompt/dialog variants, and destructive-axis external-tool boundaries. |
| Future or unseen real-world Excel surfaces cannot be fully exhausted. | Unseen OOXML part families, unseen relationship/content types, and future Excel feature extensions. |
Safe Claim¶
Use this as the default public claim:
WolfXL is Rust-backed, openpyxl-compatible Excel automation for teams that need workbook-preserving modify mode. Current compatibility and fidelity evidence cover the tracked supported workflow surface. The dated 2026-07-30 clean-source benchmarks passed the configured bounded OpenPyXL and selected-surface Rust speed and memory gates. Benchmark source relevance: current. The dated clean-wheel benchmark rerun also passed its configured gates. Raw cross-surface weak rows remain disclosed, and broader all-future-surface SOTA wording stays gated.
Plain English: this says WolfXL is a strong replacement path for the supported openpyxl-style workflows we have actually tested. It does not say nobody will ever need openpyxl again.
What Is Proven Today¶
| Area | What the current evidence supports |
|---|---|
| Supported openpyxl-style API | The tracked workbook, worksheet, cell, style, chart, image, structural-operation, and pivot construction surfaces are covered by the current compatibility and fidelity evidence. |
| OpenPyXL performance | The dated 2026-07-30 clean-source benchmark passed the configured bounded OpenPyXL speed and memory gates with no selected weak rows. Benchmark source relevance: current. |
| Rust and Rust-backed competitors | The dated 2026-07-30 required competitor snapshot covers rust_xlsxwriter 0.96.0, crates.io package xlsxwriter 0.6.1 with repo alias xlsxwriter-rs and not the separate crates.io xlsxwriter-rs package at 0.1.0, calamine 0.36.1, umya-spreadsheet 3.0.1, office_oxide 0.1.8, fastexcel 0.20.2, and python-calamine 0.8.2. Direct Rust API lanes cover rust_xlsxwriter, xlsxwriter, calamine, umya-spreadsheet, and office_oxide; Python binding API lanes cover fastexcel and python-calamine. The selected-surface speed and memory gates passed, while raw cross-surface weak rows remain disclosed and do not support an every-API-surface claim. Benchmark source relevance: current. |
| Modify-mode preservation | WolfXL preserves untouched workbook package parts during targeted edits, with current limitations documented in docs/trust/limitations.md. |
| Release artifact | The dated 2026-07-30 macOS arm64 CPython 3.13 clean-wheel benchmark rerun passed its configured bounded OpenPyXL and selected-surface Rust speed and memory gates. Benchmark source relevance: current. Raw cross-surface weak rows remain visible as non-gating boundary evidence. Thirteen of 21 registered release-artifact lanes are current: Linux aarch64 and Linux x86_64 CPython 3.10 through 3.13, macOS arm64 CPython 3.10 through 3.13, and the source distribution. The other eight require refreshed macOS x86_64 and Windows x86_64 proof. Broader release quality claims remain bounded to registered lanes and do not cover future package routes, installers, or distribution channels. |
When To Keep Openpyxl Alongside¶
Keep openpyxl in the stack when one of these is true:
- You rely on an openpyxl API that is not listed as supported in the compatibility matrix.
- You have a business-critical template whose Excel visual output has not been checked against your own acceptance files.
- You have a pivot-table workflow that needs OLAP or external caches, or visual styling beyond the current PivotArea and pivot-CF support; keep Excel or your template-authoring workflow in the loop for that case.
- You need adjacent spreadsheet surfaces outside tracked openpyxl parity, such as OpenDocument authoring.
- Your team values openpyxl's older ecosystem, staff familiarity, existing integrations, or dependency approval history more than WolfXL's measured advantages for this workflow.
Plain English: use WolfXL first for the supported workflows where speed and workbook preservation matter, but do not remove openpyxl from a production pipeline until those workflow-specific checks are green.
What Not To Say Yet¶
Do not use these as headline claims:
| Avoid | Why |
|---|---|
| Avoid: "There is no reason to keep using openpyxl." | The all-future-surface claim is still not ready. |
| Avoid: "WolfXL is better in every dimension." | The public dimensions audit still keeps open-ended future/render/click spaces out of the proven bucket. |
| Avoid: "WolfXL is a universal openpyxl replacement." | The migration promise is for the tracked supported openpyxl API surface outside documented caveats. |
| Avoid: "WolfXL is fastest for all Excel automation." | Speed evidence is workload-specific and should stay tied to measured lanes. |
Migration Framing¶
For migration copy, lead with this:
Start by moving one openpyxl workflow to WolfXL. For the tracked supported openpyxl API surface outside documented caveats, the code shape is intended to stay familiar while reads, writes, and targeted modify-mode saves move through the Rust backend.
Keep the docs/migration/openpyxl-migration.md caveats nearby. The right
message is not "delete openpyxl everywhere today"; it is "use WolfXL first for
the supported workflows where speed and workbook preservation matter."
Evidence Links¶
| Proof file | Use it for |
|---|---|
docs/trust/public-evidence.md |
What can be repeated publicly today. |
docs/trust/final-sota-blockers.md |
Why the universal claim is still gated and cross-platform release coverage remains open. |
docs/trust/public-claim-dimensions-audit.md |
Which dimensions are proven today and which remain known limitations. |
docs/trust/release-artifact-benchmark-rerun.md |
OpenPyXL and Rust/Rust-backed benchmark evidence from the release artifact. |
docs/trust/limitations.md |
Caveats that should stay visible during migration. |