Record Protection and History
What It Models
Record Protection and History models the safeguards around a change, rather than another customer business identity. Staff encounter a version when saving, a lock when an action is restricted, archive metadata when a record is set aside and revisions when investigating what changed. These mechanisms apply to contact and organization aggregates and the supported catalogue records.
Our reading is that independent safeguards answer different operational questions without conflating permission, preservation and mutation. A reader may inspect an archived person, an editor may encounter a customer lock, and an administrator may still be unable to change Rhythm-protected configuration. Workspace settings are included here as an existing storage facet, while CRM Settings remains the planning concept explaining their business meaning.
Identity and Attributes
Archive keeps its own time, actor and explanation on the live owner. Reopening clears those archive fields and retains the reopening reason. It does not add a separate pair of reopening time and actor fields to that owner: the attributed revision and ordinary modification stamps explain the changed transaction. Revision attribution describes the verified calling channel, such as Console or an integration, rather than an arbitrary API label supplied by the client.
Record protection is embedded in the contact, organization or catalogue record it governs. Lock audit rows and revisions have independent identities and identify their subject. Protected-record entries key workspace, record type and identity; CRM settings use one row per workspace.
The table describes logical properties. Optional values can be absent; a required collection member is distinct from requiring the collection itself. Examples illustrate association information and do not establish new defaults. Service-owned values remain separate from fields that staff or integrations supply.
| Property | Meaning and writer | Constraints | Example |
|---|---|---|---|
| version | Records begin at version 1. Writes that change owner or child data advance the owner version, including system changes. Set by system. | Records begin at version 1. Writes that change owner or child data advance the owner version, including system changes. | 7 |
| creator and modifier stamps | Creation and modification retain actor and time; reads resolve current actor display names through Platform. Set by system. | Creation and modification retain actor and time; reads resolve current actor display names through Platform. | Coordinator on 2026-10-23 |
| lock | Locks allow all actions, prohibit deletion, or prohibit updates and deletion. Contacts and organizations change locks through dedicated actions. Set by staff. | Locks allow all actions, prohibit deletion, or prohibit updates and deletion. Contacts and organizations change locks through dedicated actions. | deletes |
| element locks | Contact points and affiliations may have additional element locks. Set by staff. | Contact points and affiliations may have additional element locks. | Work address locked |
| lock change entry | Lock audit entries retain actor, time, a reason of at most 1,000 characters, old and new locks and released elements. Set by system. | Lock audit entries retain actor, time, a reason of at most 1,000 characters, old and new locks and released elements. | Reason: verified by membership staff |
| protected record | Operator or migration records distinguish Rhythm protection from customer locks. The pinned seed code inserts no protected records. Set by system. | Operator or migration records distinguish Rhythm protection from customer locks. The pinned seed code inserts no protected records. | Rhythm-owned Other type |
| archive information | Archive and unarchive actions own timestamps, actors and reasons, each reason limited to 500 characters. Set by system. | Archive and unarchive actions own timestamps, actors and reasons, each reason limited to 500 characters. | Archived: firm closed |
| revision | Changed contact and organization transactions produce a revision with operation, field changes, historical labels and actor names, source, correlation and time. Set by system. | Changed contact and organization transactions produce a revision with operation, field changes, historical labels and actor names, source, correlation and time. | Phone changed by Ruth’s coordinator |
| workspace default layouts and forms | Workspace defaults select contact and organization console and portal layouts and forms from Platform definitions. Set by staff. | Workspace defaults select contact and organization console and portal layouts and forms from Platform definitions. | Workspace contact edit form |
| workspace default affiliation type | The Organization command and Add Person use this affiliation type; the initial default is Other. Set by staff. | The Organization command and Add Person use this affiliation type; the initial default is Other. | Other |
| dates reconciled through | The compliance date-window cursor advances monotonically. It does not prove that bounded pending link work is exhausted. Set by system. | The compliance date-window cursor advances monotonically. It does not prove that bounded pending link work is exhausted. | 2026-10-22 |
| settings version | The settings version remains 0 until the first persisted settings write. Set by system. | The settings version remains 0 until the first persisted settings write. | 2 |
Policy and audit properties
These properties belong to the catalogue or safeguard facet named in the property column. They explain the implementation’s exposed policy and audit context without allocating another domain object. System attribution is read-only; catalogue policy is administered through its own permitted operation and is not changed by an ordinary record edit.
| Property | Meaning | Example |
|---|---|---|
| Creation / actor | System identity attributed to original creation. | Association coordinator |
| Creation / time | Creation timestamp, distinct from a revision’s capture time. | 2026-10-23T14:00:00Z |
| Modification / actor | System identity attributed to the latest saved modification. | CRM System |
| Modification / time | Timestamp of the latest saved modification. | 2026-10-23T14:30:00Z |
| Archive / time | Timestamp written by the dedicated archive action. | 2026-10-23T14:00:00Z |
| Archive / actor | Identity responsible for archive. | Association administrator |
| Archive / reason | Dedicated action explanation, limited to 500 characters. | Organization closed |
| Unarchive / reason | Dedicated action explanation, limited to 500 characters. | Closure was recorded in error |
| Lock change / identity | Append-only audit identity retained after ordinary subject deletion. | Recorded lock action |
| Lock change / record type | Subject kind whose customer lock changes. | crm.contacts |
| Lock change / record identity | The subject identity, rather than a cascading live-owner reference. | Ruth’s contact |
| Lock change / operation | Locked or unlocked audit action. | unlocked |
| Lock change / before | Restriction before the action; null means none. | deletes |
| Lock change / after | Restriction after the action; null means released. | None |
| Lock change / reason | Required action explanation, limited to 1,000 characters. | Verified authority to correct the record |
| Lock change / actor | Verified actor making the dedicated action. | Association administrator |
| Lock change / recorded time | The audit action timestamp. | 2026-10-23T14:00:00Z |
| Revision / identity | Immutable identity used to retrieve the capture. | Saved contact revision |
| Revision / sequence | Database-generated order establishes the subject timeline under its write lock. | 48 |
| Revision / record label | Historical subject label retained where captured, including deleted subjects. | Ruth Moreno |
| Revision / operation | Creation, change or deletion identifies the kind of capture. | updated |
| Revision / changes | Compact before-and-after difference document for owner and child changes. | Work phone changed |
| Revision / changed fields | Top-level fields and collection names support timeline filtering. | Phone numbers |
| Revision / capture format | Format discriminator allows readers to interpret the stored difference document. | 1 |
| Revision / transaction identity | Groups records that changed within the same save. | Shared save transaction |
| Revision / recorded time | Capture clock time near settlement, not a claimed database commit timestamp. | 2026-10-23T14:00:00Z |
| Revision / transaction start | Transaction beginning time, separate from capture time. | 2026-10-23T13:59:59Z |
| Revision / actor identity and label | Verified actor and captured historical display name. | Ruth’s coordinator |
| Revision / source | Verified request, job or maintenance context; not client-chosen attribution. | console |
| Revision / operation name | Verified operation attribution for the write. | patchContact |
| Revision / correlation identity | Context linking related execution evidence. | Save correlation |
| Revision / request identity | Verified request context when applicable. | Console save request |
| Revision / job identity | Owning Data Job identity for a batch-produced capture; absent for ordinary requests. | Import job |
| Revision / job batch identity | Batch context distinguishes the job transaction that made the change. | Import batch 3 |
| contact default / console_page_layout | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | contact console page layout definition |
| contact default / console_create_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | contact console create form definition |
| contact default / console_edit_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | contact console edit form definition |
| contact default / portal_page_layout | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | contact portal page layout definition |
| contact default / portal_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | contact portal form definition |
| organization default / console_page_layout | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | organization console page layout definition |
| organization default / console_create_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | organization console create form definition |
| organization default / console_edit_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | organization console edit form definition |
| organization default / portal_page_layout | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | organization portal page layout definition |
| organization default / portal_form | Optional Platform definition reference for this independent workspace slot; type-specific assignments override this default. | organization portal form definition |
Relationships
Contacts and organizations each have their own version and restriction fields and potentially many revisions and lock-change entries. These are governed through their subject rather than through a second editable safeguard record. Ordinary deletion removes the subject’s live data but retains revision evidence; archive retains both the subject and its relationships.
Affiliation and contact-point restrictions participate in the contact aggregate. Workspace settings reference the default affiliation type and Platform presentation definitions rather than owning those definitions. The selected default prevents deleting its type. Lock changes can release selected element locks, with the audit identifying which restrictions changed.
Lifecycle
The record-lock lifecycle explains no customer restriction, deletion restriction and restriction against updates and deletion. Dedicated lock and unlock actions require the applicable grant, the current version and a reason. Rhythm protection is independent and can refuse those customer actions even when the actor holds every ordinary administrative permission.
Archive and business status have their separate record lifecycle models. Revisions are immutable evidence produced by database capture, not an editable state machine or a restore service. Settings begin with an unpersisted version of zero and acquire stored versions when configured.
Invariants
Customer locks and Rhythm protection answer different authority questions. A delete lock can permit a correction while stopping removal; a full customer lock prevents ordinary modification as well. Rhythm protection independently prevents customer lock changes and deletion. Treating those overlays as interchangeable would either block intended correction or allow customer administration to release a platform-owned restriction.
Dedicated lock changes retain the reason and before-and-after restrictions so staff can explain why an operation is blocked and who altered that boundary. Contacts and organizations can also carry restricted nested elements. Contact roles have their own owner action and the documented ordinary-save exception; their audit cannot be described as identical to every contact transaction.
Revision capture preserves the committed aggregate difference, verified actor and calling context. Its independence from the live owner allows inspection after deletion, while transaction attribution prevents a failed save from acquiring a successful-looking revision. Application read-only access supports tamper resistance against application writers; it does not establish immunity to a database administrator. Retention, page access and the distinction between transaction time and recorded time belong to the history contract rather than to a display claim that every operation is instantaneous.
Permissions
The CRM authorization model separates workspace access from permission for a particular action.
The service checks these grants at the corresponding operation boundary. Additional record guards still apply: grants do not bypass archive, customer restrictions, dependencies, version comparison or Rhythm protection. Read access and history access are separate; record history checks the applicable read authority as well as the history grant.
How It Is Stored and Shared
Owner rows retain current versions, locks and archive stamps. Separate revision and lock-change storage retains explanations keyed to the subject. Database capture constructs aggregate contact and organization history from committed work, and application access to revisions is read-only. A missing required change context fails the write rather than storing an unattributed correction.
CRM settings use one workspace record with independently authorized sections. Platform supplies referenced forms and layouts, actor names and permission evaluation. The date cursor supports reconciliation, but an advanced compliance window is not proof that every pending link was processed.
Open Design Questions
The older contact-role write behavior remains an exception to dedicated lock auditing. Classification saves do not share the record no-op guarantee, and the date cursor does not measure all pending shared-link work. Existing findings preserve these differences; the design does not infer a broader guarantee from the common safeguard vocabulary.