Core purpose
Book metadata, Post bodies, and chapter tables of contents are not the same kind of data, and they do not need the same history strategy. REZICS lets each product define the scope that truly needs tracking, then creates revisions on formal publication.
Drafts can be saved and validated repeatedly. History records published versions, not every keystroke or content that has not yet taken effect.
What is available now
- List a Unit’s published revisions and current version.
- View Post content history and management pages.
- Preserve revisions for books, media, collections, and other content structures.
- Compare node additions, moves, changes, and removals between two structure versions.
- Restore a past state by creating a new revision, without overwriting existing history.
- Use optimistic-concurrency tokens to prevent a stale draft from silently overwriting a newer version.
Why history granularity differs
A Portable Text article is suited to comparison by block identity. A large chapter tree needs comparison by stable node ID and position. General Unit fields may track only specific governable attributes. A shared history protocol handles revision identity and publication boundaries; product projections interpret the differences.
In development
Dedicated discussion spaces for each revision, discussion Posts created from history, finer field/block locking, and cross-language version descriptions continue to expand. Until they are formally available, capability documentation will not claim support for arbitrary automatic merges or complete draft time travel.
Relationships and boundaries
History does not belong to the editor, and it is not an audit record. The editor manages the current draft; History preserves published content versions; platform audit records security and governance actions. Restoration must also create a new revision: a past version must not overwrite later history.