Rhythm 2.0: Data Enrichment Architecture

What This Record Is

Proposes how Rhythm 2.0 enriches contact and organization records from external data providers for association staff: provider answers are stored as claims rather than facts, staff review suggestions before anything changes, CRM (customer relationship management) keeps every write, and spend is bounded per association. Proposed on 2026-10-22 as RHYTHM-ENR-ARCH-001; the same day Andrew ruled the six decisions that gate the first milestone (enrichment lives inside CRM, tier 3 personal-identity data offered from ENR-M1 behind attestation, the other four as recommended), six decisions remain open and nothing is built.

(Summary from the Rhythm 2.0 Architecture Library card; the parts below are the proposal's own text, converted verbatim.)

Parts

1. Rhythm 2.0: Data Enrichment Architecture: Status: **proposed 2026-10-22; the six decisions that gate ENR-M1 were ruled by Andrew the same day (2026-10-22 about 11:50 ET): ENR-D1 overturned (enrichment lives inside CRM), ENR-D2, D3, D4 and D8 as recommended, ENR-D6 overturned (tier
2. 01. Executive summary and recommendation: Status: proposed 2026-10-22; six gating decisions ruled by Andrew the same day (ENR-D1 overturned: enrichment lives inside CRM; ENR-D6 overturned: tier 3 offered from ENR-M1 behind attestation; the rest as recommended; see [15](15-open-deci
3. 02. Market and competitive analysis: Rhythm should use external providers for enrichment, keep their results separate from member records, and apply changes through a shared policy and review process. The opportunity is not to build another data source. It is to give associati
4. 03. Enrichment provider comparison: Status: proposed 2026-10-22. Nothing in this document is decided or built. ENR-D4 is the provider-selection decision; this document supplies the comparison and the tests needed before that decision.
5. 04. Architectural principles: Status: proposed 2026-10-22. Labels as in the README. Everything here is Recommended unless labelled otherwise.
6. 05. Service ownership and Integration Platform alignment: Status: proposed 2026-10-22. Labels as in the README. This document recommends an ownership boundary; it does not approve or implement it. The recommendation is decision ENR-D1 in 15, where Andrew ca
7. 06. Core workflows and use cases: Status: proposed 2026-10-22. Nothing in this enrichment design is decided or built. Labels are as defined in the README.
8. 07. Provider contracts and orchestration: Status: proposed 2026-10-22. Nothing in this proposed design is decided or built. The package's decisions are in 15 for Andrew to approve or overturn. Labels follow the README.
9. 08. Data model, provenance and policies: Status: proposed 2026-10-22. As ruled (ENR-D1, Andrew 2026-10-22 about 11:50 ET), the schema is crm and the tables are crm.enrichment_* in services-crm; the DDL below keeps the platform. prefix as written and is read with that substit
10. 09. Security, privacy and licensing: Status: proposed 2026-10-22. Labels as in the README.
11. 10. API and event architecture: Status: proposed 2026-10-22. Nothing in this proposed enrichment design is decided or built. Verified statements describe existing Platform or CRM capabilities, not completed enrichment work. Labels follow the README.
12. 11. Console and portal experience: The recommendation is to make enrichment part of the existing record and data-quality workflows, with the same experience whichever provider is connected. Staff should see proposed changes and understandable evidence, not provider-specific
13. 12. Commercial model and economics: Status: proposed 2026-10-22. This chapter's recommendations are not approved or built. References to existing framework capabilities describe what is available to build on, not a completed enrichment product. Decisions ENR-D4 and **ENR-
14. 13. Phased implementation milestones: The proposed sequence starts with one customer-provided person provider and staff-reviewed suggestions. It then adds organizations and automatic fill, bulk processing, employment changes, managed premium access, and finally opt-in AI resear
15. 14. Alternatives and tradeoffs: Status: proposed 2026-10-22. Labels as in the README. All judgements in this document are Inferred from the evidence cited in the chapters. Nothing in the enrichment proposal is decided or built; the Decided label below
16. 15. Open architectural decisions: The recommendation is to build enrichment as a Platform module, start with customer-owned provider accounts, and require review before applying information about people. Baseline features would be available to every workspace; costly featur
17. 16. Sources, research dates and how this document was produced: Status: proposed 2026-10-22. Labels as in the README.
18. R1. The Integration Platform as built: evidence for a Data Enrichment design: Evidence report for the Rhythm 2.0 Data Enrichment architecture proposal. Read-only investigation, 2026-10-22.
19. Evidence r2-crm: Rhythm 2.0 CRM as the target of Data Enrichment: Read-only investigation for the Data Enrichment architecture (filling and refreshing contact and organization data from
20. R3: Platform core, evidence for the Data Enrichment architecture: Read-only investigation of the Platform macroservice and its shared libraries, for the question "what does an enrichment
21. R4. Data operations (Data Job Engine) and the query layer: evidence for Rhythm 2.0 Data Enrichment: Read-only evidence report for the enrichment architecture proposal. Nothing in any repository was modified except this file.
22. R5. Rhythm 1.0 FullContact and Google Civic enrichment, and the customer-360 precedent: Evidence report for the Rhythm 2.0 Data Enrichment architecture proposal. Read-only investigation, 2026-10-22.
23. W1 Evidence: How association management systems (and the nearest nonprofit CRMs) handle data enrichment and data quality: Research date: 2026-10-22 (all "accessed" dates below are 2026-10-22 unless stated).
24. W2 evidence: how enterprise CRM/ERP platforms do data enrichment: Research date: 2026-10-22 (all "accessed" dates below are 2026-10-22).
25. W3 Evidence: Enrichment Provider Landscape for an Association Management System: Research date: 2026-10-22 (all pages accessed 2026-10-22 unless a row says otherwise)
26. W4 Evidence Report: Privacy Law and Data-Licensing Constraints on Rhythm 2.0 Data Enrichment: Research date: 2026-10-22 (all "accessed" dates below are 2026-10-22).
27. W5. Supplementary provider checks (read directly, 2026-10-22, 11:00 to 11:30 ET): The four market reports (w1 to w4) ran short of web-search budget before they could read several provider pages. This note