Pilot and acceptance

A pilot proves real embedding, not a presentation: your document opens inside your application, is edited, saved, and reopened without loss. The go or no-go decision is made against written criteria, and the report stays with you either way.

What is verified

What we verify	What counts as passed
Opening	A real document or workbook opens inside your application; no separate editor window appears. The declared capabilities are visible.
Editing	The user performs the agreed edits; each edit creates one history entry, and the application learns about unsaved changes.
Saving	The file is returned to your application; the right to save is declared explicitly.
Reopening	The saved file reopens from a cold start without loss of meaning or integrity — for documents and for spreadsheets.
Events	The application receives the open (ready), change (dirty), save (saved), error (error), and close (unmounted) events; events of a white-label delivery are by agreement. For spreadsheets, the event contract is fixed and versioned, but the part that implements it isn’t in the release yet: you can write code against the names today, but you can’t run it, and this row can’t be verified for spreadsheets during the pilot (what the kit includes).
Security	The token and credentials don’t leak, the service listens only on the local address, document content doesn’t end up in logs; the policy is checked before opening, saving, and any network call.
Resource release	After closing, no processes, connections, or background tasks remain.
Performance	Startup, opening, editing, recalculation, saving, and memory on the agreed classes of documents and workbooks.

Pilot plan: two weeks

A pilot is a structured two-week verification on your document corpus with written acceptance criteria: what opens, what survives the “open — save — open” round trip, and what performance you see.

Stage	Duration	Result
Assessment	1–2 business days	Choice of platform and server side, key scenarios, document corpus, acceptance criteria, security requirements, and the business owner on your side.
Prototype and measurements	by the end of the second week	Opening, editing, saving, and reopening real DOCX and XLSX files from your corpus inside your container; performance measurements against the acceptance criteria.
Decision: go or no-go	1 meeting at the end of the second week	A report against the acceptance criteria, the final list of capabilities, the list of work before production use, a commercial estimate, and the expected commitments on availability and version support period.
Work for your process	after the decision, by estimate	Styling under your brand, a storage adapter, single sign-on and audit, events, selected product routes. These are not part of the pilot: they are changes for your process, with a price and a deadline named in advance — commercial packaging.

When a pilot counts as successful

A pilot is successful only if the chosen capability profile works in your real application, saves documents, survives a cold-start reopen, leaves no hidden processes or handlers behind, and never puts secrets into logs.

For developers

• What to give your engineers and in what order to read it — How to start a pilot.
• The list of checks before a pilot — the SumSheet checklist and the SumDoc checklist.
• Event names: for documents — SumDoc embedding, for spreadsheets — the embedding kit. The evaluation kit is described in the glossary.