Keep Customer Locks and Rhythm Protection Apart

Context

Customer locking controls permitted record work, while Rhythm protection prevents customer operations from removing system safeguards. These are separate constraints with different authorities.

Decision

Dedicated customer lock actions require administrator permission, a current version and an audited reason; the legacy contact-role ordinary-write path is an exception; rhythm protection is independent and cannot be lifted by customer permissions.

Alternatives Considered

Let general saves establish full locks. That would let ordinary editors freeze records outside the narrowly authorized release flow. Contacts and organizations reject such writes.

Combine customer locks with Rhythm protection. A customer unlock must not release a system safeguard that the product depends on.

Consequences

Dedicated actions are audited and versioned. The ordinary role-save exception is already explicit in approved planning; the examination corrects the draft’s broader claim. Missing release operations for other catalogue locks also remain unresolved.

Contacts, organizations and roles have dedicated lock actions; other classifications can enforce locks without a supported release action. Pinned seed code creates no protected entries, but deployed operator data was not examined. The ordinary role delete-lock exception is explicit in approved planning; the examination corrects the draft’s universal dedicated-action claim.