Risks and honest boundaries

Promising “full Office” without criteria is easier, but such a promise can’t be verified. So this page names what’s still open and what closes it. Without this page, a conversation about rollout is incomplete.

Risk or open question	Why it matters	What covers it
What will be in the public interface	There are more internal capabilities than can be declared public and then supported for years.	A locked public interface, types, and versioning rules.
Fidelity of round-tripping	A file opening doesn’t yet mean it will come back from the editor without loss.	A matrix of critical documents and capabilities, before-and-after file comparison, a reopen check.
Archival PDF/A	For archives and legal or government records management, this is a condition of admissibility, and plain PDF isn’t enough there.	Plain PDF export works, including with embedded fonts; PDF/A-1b readiness is checked with a separate command, and export to that format itself is still closed and runs through your own verification program — what you can do with each file type.
VBA	Security requirements and incomplete compatibility clash with expectations that it “just works”.	A matrix of supported calls, a list of refusal kinds, security rules, and a ban on changing the document silently.
Power Query	Rollout most often runs into exactly this: queries, connections, and the data model.	Recognition and preservation first; refreshing and editing queries as a separate stage; acceptance by comparing files.
Speed claims	The market is already oversaturated with slogans like “ten times faster”, and arguing with slogans is pointless.	A reproducible benchmark on your own documents, fixed hardware, thresholds for typical and worst-case time.
Confirmation on every system	Verification on one system doesn’t automatically carry over to the others.	Separate acceptance on every declared system and in every embedding method. For documents, look at pagination first: text width is measured by the engine of the system where the core runs — the system engine on macOS, a portable one on Windows and Linux. Spreadsheets don’t have this cause: SumSheet doesn’t use system font engines; widths are taken as declared in the workbook itself.
A server with many clients at once	Working in a desktop application doesn’t carry over to a cloud service.	A separate architecture: quotas, access checks, a task queue, isolating clients from each other, observability.
Packaging and signing	An unsigned file won’t pass enterprise deployment.	Not everything is signed yet, and it differs by product — the list is below. Wherever there’s no signature, checksum verification remains; how to check is shown on the installation pages for SumDoc and SumSheet.
Version support	You depend on how long the version your product is built on stays supported.	A support period, deprecation rules, migration guides, an escalation process.

What is signed today

• SumDoc. The macOS app is signed with a Developer ID certificate and notarized by Apple; the Windows installers carry no signature.
• SumSheet. The app in the .zip archive is signed and notarized — verified on a downloaded build: the system answers accepted and source=Notarized Developer ID; the .dmg image from the same folder carries no notarization. The Windows installers are signed with a test certificate, “SumOffice Test Signing (DEVELOPMENT ONLY)” — the system will warn about an unknown publisher; this signature isn’t confirmed by the release evidence, so check it on the downloaded file yourself.
• Both products on Linux. The deb and AppImage packages have a detached .asc signature next to them; rpm doesn’t.

Decisions to make before you start

• Your target operating systems, your application’s technology, the embedding method, and the deployment boundary.
• A dozen critical user actions and three to five real documents.
• Requirements for comments, tracked changes, tables, drawings, fields, sections, and headers and footers.
• Requirements for formulas, charts, pivot tables, external references, Power Query, macros, and data connections.
• What agents are supposed to do, what permissions they’re given, what goes into the audit trail, and who approves their actions.
• Where files come from and where they’re saved, how backups and recovery work, how leaks are caught, what gets written to logs, and where performance metrics go.
• What availability commitments are needed, how many years a version must be supported, how often updates ship, who’s responsible for rollout, and how vulnerability handling works.

An honest way to put it

The foundation is already there: a processor inside someone else’s product, and a shell you can replace with your own. Turning this into a deliverable developer kit doesn’t mean rewriting the product — it means formalizing the boundary: a stable public interface, packaged delivery files, documentation, acceptance, security, support, and a capability matrix locked in by contract.

Next

• How these boundaries are verified on your documents — Pilot and acceptance.
• What the contract covers — Commercial packaging.
• In what order the rest gets covered — What’s coming next.
• Start small — early access request.