Readiness checklist

• The archive was downloaded from dl.layers.md, not received by email or from a third-party mirror.

• The checksum of the downloaded file matched the one in SHA256SUMS from the same folder of the release directory.

• The application’s signature is verified — using your own system’s method, as shown in the Verifying the signature section.

• The compute_contract_cli processor is found inside the installed application and runs.

• The workbook opens with the open_workbook_subset call.

• subsetId and the sheet key are taken from the response, not built on your own side.

• Three cells are changed with a single apply_cell_edits operation, not three in a row: otherwise a refusal partway through leaves the workbook half-changed. A batch of edits never crosses from sheet to sheet — a mixed batch is refused entirely with unsupported-cross-sheet-edit, and edits for different sheets go out as separate requests (apply_cell_edits).

• read_cell_details returned the expected value — in the quick start, that’s 42 in cell C1.

• Undo and redo run on the core’s history, not your own stack on your side.

• The saved file is created and reopened by a different process — that’s how you verify a finished workbook landed on disk, not a half-baked one.

• Refusals are parsed from the ok and code fields, and the interface never shows success when the operation was refused.

• Warnings from warnings are read, not discarded: the operation may have turned out differently than expected. At least two cases are checked — backendUsed matches the engine you asked for, and formula numbers are shown after recalculation, not taken from whatever Excel last saved (what warnings look like).

• If the workbook pulls data from outside — over https, from Postgres, or from SQL Server — the host answers the core’s counter-requests: the core has no network of its own, and it will wait indefinitely without a response. Verified with a request that actually reaches outside, not just reading the workbook from disk.

• For the browser and server, a separate broker process and a list of allowed file addresses are in place.

Check workbooks before the pilot

Before the pilot, you can check your corpus of workbooks without installing anything: on the public check page or with the bot in Slack and Telegram (@sumoffice_check_bot). It accepts .xlsx, .xlsm, .xlsb, .xls, .xltm, .xltx, and .xlam up to 50 MB; no account is needed.

The report shows functions (how many the engine knows, the unknown ones as a list), pivot tables, Power Query, external links, and a route for every macro: Native — the engine takes on running it itself; Migration — waiting for further work, blockers are named; Excel bridge — stays in Excel by design; Preserve only — not classified and stored byte for byte. In the contract this is the VbaExecutionRoute field — native, excel-bridge, excel-bridge-legacy, and preserve-only: “Migration” on the report is the excel-bridge route, “Excel bridge” is excel-bridge-legacy (VBA types).

Nothing from the workbook is run: the service reads it three times — the package structure, the function map, and the VBA project — and deletes it no later than 24 hours afterwards. The same service can be installed on your side next to the web host — what exists.

If a checklist item doesn’t check out

• Open or save isn’t working — diagnostics.
• The response contents or refusal code are unclear — How the API session works.
• You need an operation that’s not in the example — the Compute Contract reference.
• It’s about Web or server — SumSheet as a server-side processor and The core in the browser through WebAssembly.