Audit, soft delete, and versioning are different controls

What the public implementation shows

Guevara implements separate auditable-entity, soft-delete, versioned-entity, and domain-event interceptors in its persistence layer.

Each interceptor adds one cross-cutting persistence rule without requiring every command handler to reproduce it. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleTraceability is stronger when time, lifecycle, and concurrency have separate representations.

The decision behind the mechanism

Separation preserves distinct meanings: audit records authorship and time, soft delete controls active visibility, and versioning supports change coordination.

One generic status field cannot reliably answer who changed a record, whether it was deleted, or whether a concurrent update overwrote another. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Capture authenticated actor and UTC timestamps.
• Filter soft-deleted records by default.
• Use version state for concurrency decisions.
• Dispatch domain events only after a successful persistence boundary.

How the control should be operated

Operators and auditors need documented query behavior for deleted rows, version conflicts, actor identity, timestamps, and emitted events.

The control plane retains institutional memory without overloading business code. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.