Color-coded AI auto-apply beats ratification queues
Designing an LLM-assisted enrichment pipeline for a personal CRM and rejecting the proposal/ratification-queue architecture in favor of additive-only auto-apply.
When an LLM proposes updates to user-owned data, a ratification queue (model proposes, user accepts/declines) structurally creates a second inbox to drain — high-friction even with grouping/bulk-accept. The cleaner pattern: AI is additive-only (never overwrites existing fields), every AI-authored item gets a visual diff (dotted underline + faint badge), and removal is one-click + a keyboard shortcut + a 5s undo toast. Replace-shaped updates become append-only observations on a dedicated section instead of overwrites. Suppression becomes emergent: deleting the same (entity, field, value) twice in 30d writes a quiet dont_propose entry, no explicit suppression UI needed. This collapses a lot of designed infra: no proposals table, no version-conflict mtime fingerprinting, no suppressions table, no ratification-queue route.
When reviewing an LLM-enrichment design, first ask whether the outputs are presented as proposals-to-ratify or as already-applied-with-fast-undo — they have wildly different infrastructure footprints.