Kival preserves history at two levels: object versions record how authored knowledge changes, while events record important actions around that knowledge and the wider system.
The two histories answer different questions. Versions show what an object contained; events show what happened around it.
Content history
Every meaningful change to an object's title, body, or metadata creates a new immutable version. Each version records its object, version number, authored content, author, and creation time.
The object points to the version that is current now, while earlier versions remain readable. Version history is therefore the authoritative history of authored object content.
See Objects and versions for update and concurrency behavior.
Activity history
Kival also maintains an append-only event log for auditable domain activity. Events cover actions such as object and relationship changes, access grants, workspace/group membership, commentary, credentials, attachments, and lifecycle transitions.
Events have a globally ordered sequence number and can carry stable identifiers for the resources involved. This makes them useful both for audit and for incremental programmatic processing.
A version and an event may describe different aspects of the same change: the version preserves the new authored state; the event records that the change happened and who caused it.
Authorship and programmatic attribution
Versions record the user responsible for the authored state. Events separately record the actor behind the action.
When software authenticates through an API key, the action still belongs to the key's owning user, while the event can also retain the specific API key and label. Separate integration or agent credentials can therefore remain distinguishable without creating a separate principal model.
Provenance is explicit
Kival preserves provenance it can establish from concrete actions: who created a version, what version became current, which relationship or grant changed, which credential performed an action, and when those transitions occurred.
It does not infer the factual source of a claim simply because the claim appears in an object. If source lineage matters, represent it through authored content, references, relationships, attachments, metadata, or an integration convention.
Current and historical context
Not every kind of context stays current forever. References from older versions remain associated with those historical versions, while current backlinks and graph projections use current-version references. Explicit relationships have their own lifecycle and can be revoked without rewriting content history.
Commentary has a different durability boundary again: comments can be edited or deleted and are subject to retention. Important conclusions should therefore move into canonical object content rather than live only in a discussion thread.
Access to history
History is authorization-aware. Object readers can inspect ordinary object history; sensitive access-grant events require object-administrator authority. Workspace-wide and global event views require the corresponding administrative scope.
This prevents the audit trail itself from leaking knowledge or access changes that the viewer is not allowed to inspect.