The Database Writes Record History

Context

The approved history plan separates durable revisions from transient delivery events. Contact and organization capture settles one aggregate revision with the transaction’s attribution.

Decision

A changed contact or organization transaction leaves one database-written, application-read-only revision with actor and source context; revisions survive owner deletion and remain until workspace purge.

Alternatives Considered

Write audit history from each application path. A path could omit capture, and writable application history would allow forgery or alteration.

Retain delivery events as the history store. Delivery events are transient and removed after queue acceptance; revisions require independent retention.

Consequences

Application read-only access preserves that record of change, including after deletion. Classification records do not use this mechanism, and the console still lacks an organization-history entry despite available service operations.

Application permissions permit history reads but not revision mutation, including after owner deletion. Missing required attribution prevents the corresponding change from committing. History access uses the reader-tier permission defined by the approved plan.