Document revisions and replacement

Preserve immutable versions and refuse changes based on stale document revisions.

A managed document has a logical identity and an immutable content revision. Replacing its content publishes a new revision instead of overwriting the bytes of the earlier one. This makes it possible to bind an approval or receipt to the exact content it describes.

Create or replace

Use an App's managed upload control to create a document or replace its expected current revision. Managed upload accepts one file per handoff and stores the revision without automatically starting the ordinary ingest workflow. This differs from the normal document-processing upload mode.

A replacement must identify the current revision it expects to replace. If another action already changed that document, the replacement is refused rather than silently overwriting the newer head. Reload the document, inspect the change, and make a new decision.

The managed upload limit is 100 MiB per file. Use a canonical single filename rather than a path. A confirmed result identifies the document, revision, content hash, size, and media type.

Editable reader versions

An App's editable document reader can also save edited text as a new version and trigger re-indexing. Saving a version and finishing its processing are separate stages. Check the saved version and processing feedback before refreshing an extraction.

Existing results remain explicit

Replacing or editing a document does not automatically rewrite accepted table values or retained evidence from an earlier capture. Generate an update, review its source and values, and explicitly apply it when ready.

A deletion request for an earlier managed revision becomes invalid when replacement changes the current head. The owner must inspect and approve the intended current revision rather than using a stale approval.

For removal, see document deletion approvals. For uncertain writes, see recovery.