Hi @Mridu,

Rather than building everything greenfield, you can lean heavily on Databricks’ existing Entity Resolution Solution Accelerators (Customer ER, Product Matching, Public Sector ER) as a starting point and then adapt their patterns to your blueprint, instead of maintaining a custom implementation end‑to‑end yourself. In my previous projects, I’ve done ER with a mix of third‑party tools and custom code, which worked but was always a bit clumsy and high‑maintenance. The current Databricks accelerators and patterns are much more mature and provide a cleaner, more scalable starting point. 

I've tried to map the various accelerators readily available to your modular requirements.

• Normalization & validation --> In the Customer Entity Resolution accelerator, the first notebooks clean and standardise attributes (names, emails, phones, addresses) into curated Delta tables with audit‑friendly schemas.
  
  
• Blocking strategy --> The same accelerator uses multiple blocking keys/candidate‑generation strategies (e.g., LSH/similarity search on text) to cut down comparisons at scale. The Product Matching and Public Sector ER accelerators follow the same pattern for products and people/orgs.
  
  
• Fuzzy matching & scoring --> Customer ER + Product Matching show how to compute multi‑field similarity scores (string distance, embeddings, etc.) and assemble a single match score per pair.
  
  
• Clustering --> They then group matched pairs into clusters/entities (e.g., using graph‑style connected‑components logic) to get from pairwise to entity‑level views.
  
  
• Golden‑record selection --> Each accelerator includes examples of deterministic survivorship rules (recency, completeness, source priority) to pick the best record per cluster.
  
  
• ML‑assisted matching --> Customer ER (with Zingg) and the Zingg‑based blogs train ML models on engineered similarity features, log them in MLflow, and use them to auto‑classify candidate pairs.
  
  
• Human‑in‑the‑loop review --> The same pattern supports a "grey zone" of scores that go to human review. Reviewer decisions are written back to Delta and reused as labels for retraining and for audit trails.

On your specific question about blocking at scale, I would recommend you start with multiple composite keys (e.g. phonetic last name + postcode, email username + domain, etc.), plus a semantic/vector‑based candidate retrieval step for messy text.

In terms of storing reviewer decisions, you can model them as a labelled pair table in Delta (pair ID, entity IDs, label, reviewer, timestamp, key features). The accelerators and blogs use those labels both for ML training/evaluation and as an auditable system‑of‑record.

If you haven’t already, I’d start by cloning the Customer Entity Resolution accelerator and then adapting each notebook step to your domain instead of rebuilding the framework from scratch.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.