What does “saved” mean in an embedded document editor?

Document the states supported by the actual integration: accepted locally, synchronized with the editing service, persisted by that service, and available as a business file version are possible examples. Do not invent states that the provider cannot observe. Identify which system is authoritative during an active session and after it closes. If export runs asynchronously, distinguish a durable editing state from the latest downloadable file. This vocabulary should appear consistently in application messages, monitoring, support procedures, and agreements about recovery after an interruption.

Use separate state fields when the architecture exposes separate milestones. For example, editing_state_confirmed can describe the last acknowledged editor state, while published_file_version identifies a retrievable business file. These are example application concepts; the provider may expose different or fewer signals. Never manufacture a precise status from a timer after the user stops typing.

Failure messages also need this distinction. If export fails after the editor has persisted changes, saying that all work was lost is inaccurate. Say which result is unavailable and provide the supported recovery action. If the integration cannot prove persistence, avoid reassuring language that exceeds the available signal. Ask the provider which state survives a process restart, and reproduce that recovery in acceptance before deciding what the interface should promise.