Discovery
Each engine inspects its source file and reports the editable structures it finds and the content they currently hold: chart and table cells in the presentation, table cells and text runs in the memo, cell ranges in the workbook.
Technical Article · Wolf Reporting Engines
Teaching agents to update the Office files a business already uses
Recurring reports are existing files, not blank pages. Wolf is a set of command-line engines that apply one approved dataset to the spreadsheet, deck, and memo a team already uses, then prove what happened: editable outputs, refusals before partial publication, and recovery after a process kill at the boundaries the qualification exercises.
SYNTHETIC DEMONSTRATION DATA·FY2026 Q1·MACOS ARM64 + LINUX X86_64·CPYTHON 3.13 ENGINE ENVIRONMENT·RECEIPT-BACKED
The problem: the deliverable is an existing package
Each reporting period, someone opens last quarter's spreadsheet, deck, and memo and types in the new numbers. It is transcription with consequences: one stale cell propagates into the presentation chart and the memo table, and reviewers catch it by luck. Generating a brand-new document is a solved problem; the deliverable is the existing file, with the same template, review steps, and archive slot as last quarter.
Editing OOXML in place is where trust in automation breaks. A generic file writer can silently restyle a template, detach a chart from its data, or overwrite the prior period, and an editor that dies halfway leaves a folder in an unknown state: is this deck from this run or the last one? The missing piece is not better writing but an artifact layer built to be audited, interrupted safely, and willing to refuse.
The workflow: one approved dataset, three files
A Wolf reporting job starts from approved values, not a prompt. In the qualified demonstration, the requester supplies one reporting period, FY2026 Q1, and three values in USD millions: revenue 125.13, costs 75.12, and total 200.25, the stated sum of the first two.1 The business meaning of those numbers belongs to the requester; the engines carry them as data and check nothing about finance. The run has fixed steps.
Target binding
An edit names its target by restating that current content, and the presentation and memo requests also carry the digest of the exact source file. If a reviewer already changed the file, the job is a mismatch, not a surprise overwrite. Values bind to targets by name, so one dataset drives all three files.
Execution
A control plane runs the three engines as separate command-line processes into a new output bundle. Inputs are never modified; every operation's policy is stop on failure, clean up staging, require verification.
Independent verification
Reader libraries that are not the engines reopen the saved workbook, deck, and memo, assert the intended values landed and an untouched reference cell survived, and compare the untouched parts of the presentation and memo packages member by member, byte for byte.
The independent readers are openpyxl, python-docx, and python-pptx, distinct from the editing engines.2
Editable outputs, not exports
Editing the real file only helps if the result stays editable. The deck's chart is not swapped for an image: the engine rewrites the chart's embedded worksheet, so a reviewer opening the output in PowerPoint can still adjust the series or copy the chart, exactly as with a hand-built one. The workbook and memo stay ordinary .xlsx and .docx files.
The figures below are retained renders of the example presentation from the original qualified run.3 The deck is deliberately minimal, one chart, one table, one narrative line, one untouched slide, built to exercise editable native structures rather than imitate customer styling. The exact input and output files from that run are downloadable from this page below the figures.
Inputs to the run
Observed outputs of the original run
The example inputs are synthetic, generated by the demonstration script from the bundled fixture-authoring dependencies and the approved-values record. These downloads retain the exact bytes of the inputs and observed outputs of the original qualified run; a new run regenerates equivalent inputs, and archive byte identities may differ.
Refusal and recovery
Two behaviors matter more than the happy path.
Refusal. The example deliberately submits a memo edit whose expected prior text no longer matches; the job fails before any bundle is published, so there is nothing half-new to mistake for a deliverable. Pointing a run at an existing output directory is refused rather than overwritten, and after both refusals the inputs are checked unchanged. Ambiguous or unsupported targets are refusals, not best efforts.
Recovery. The qualification kills the running job at three verified boundaries: between operations, immediately before publication, and immediately after it.4 Resuming a job that is still running is refused. After a real kill, resume completes the package, and the operation journal proves each engine step executed exactly once. A job killed after publication resumes without touching the published files, and re-running a completed job returns the same receipt without re-executing anything. A cancelled job discards its staged state and refuses later resumes, and staged output tampered with between kill and resume causes refusal rather than publication.
Agent processes get cancelled, time out, and are killed by supervisors. When the operation journal records what already happened, an interrupted job is a resumable chore instead of a forensic puzzle. The journal is what the qualification exercises; nothing here claims crash-durable storage.
Architecture: independent engines, one contract
Wolf is deliberately not one monolithic library. Each format has an independent engine with its own wheel, command line, and pinned source commit: WolfXL for workbooks, WolfPPT for presentations, and WolfDocx for documents. A control plane composes them through a suite contract: a reporting request lists operations, each with its engine, payload, destinations, and policy, and a lock file pins every engine by wheel digest and source commit. The runner verifies the wheels against that lock before installing offline from the bundled wheelhouse, with package indexes and downloads disabled. Version labels alone are not identity; the digests are.
The separation is load-bearing: an engine that only edits workbooks has a small, testable contract. Each engine runs as its own process, and the control plane owns sequencing, staging, publication, receipts, and recovery state: edits are staged into a new output bundle and published only after verification, so a failing or killed engine stops the run before publication instead of leaving a half-updated pack. That sequencing and staging boundary is the qualified guarantee; it is not a claim that a failure in one format can never interact with the others. Licensing is stated plainly: WolfPPT is MIT, WolfXL is commercial, and WolfDocx and the control plane are distributed under adopted commercial terms, with license and third-party notice texts shipped in the bundle. Adopted terms are not accepted customer Orders.
Scope and evidence limits
This is a bounded demonstration, and the boundaries are part of the claim. The workflow is exercised on macOS arm64 and Linux x86_64 with a CPython 3.13 engine environment; Windows and other environments are unqualified.5 A receipt proves the requested edits were applied under the stated checks, nothing more: it does not establish the financial meaning of the values, which are supplied demonstration data, and the independent readback is structural, not a test of Microsoft Office rendering. Native-application evidence is retained from the original recorded run, covering PowerPoint 16.112.3 open, save, and PDF render, and Word 16.112.3 open, display, and save, each with independent readback; Word PDF export remains unqualified. Unseen customer templates, the rest of OOXML, and legal-document suitability are not covered; nothing here claims to replace Office. The demonstration and evaluation requirements, including what was exercised on each platform, are listed on the suite qualification page.
Where to go next
The reporting workflow above is the named workflow proposed for Wolf Suite early access. The suite is not purchasable yet, and the qualified candidate is not publicly distributed: a release needs an approved agreement, a qualified public package, and completed release review. WolfXL itself is available today, under its existing license, pricing, and evaluation path.