Capstone: Repair a Broken CRM Population

Every policy in this guide has proven itself in isolation: the duplicate policy correctly held an ambiguous pair, the consent architecture correctly protected a customer contact, the departure policy correctly preserved history. Isolation is the problem. A plan that only works one fixture at a time hasn't been tested against what a real CRM actually looks like: every condition present simultaneously, competing for the same records, on the same day.

Eleven conditions, one population, at once

The capstone loads a fresh canonical population combining every seeded condition from the guide: the duplicate pair, the inconsistent field batch, Priya Shah's marketing opt-out, Leah Fenwick's sales DNC request, Derek Chen's employer change, Kessler Metal Works' stale status, Sam Okafor's re-engagement, the provider-conflict pair, the enrichment-ineligible cohort, the unsafe proposed merge, and the failed partial scan.

Approve only when every check passes together

Run every completed chapter's policy against the combined population and inspect whether any policy undermines another. Would the duplicate policy's protected-record check still hold if the same record is also mid-review under the conflict-resolution policy? Approve the plan only when all twelve validation checks pass against the combined population, not against each fixture in isolation.

What this actually buys you

A plan that passes its own capstone means the reliability program stops depending on any one person remembering the exception. The duplicate rule, the consent architecture, and the enrichment gate all still hold when they're all running at once, against records that don't cooperate with each other, which is the only condition a real CRM actually operates under.

Carry this into your business

A policy that passes its own test case is a start, not a finished program. Run every policy against one messy, realistic population before you trust any of them.