Combining Data for
Investigative Analysis

Drop this prompt into your LLM, replacing the ‘path/to/your/files’ in Step 1 with your path name:

Important: Use the Senzing MCP for this task.

Goal: Map my data sources to Senzing JSON, ready for ingestion.

Hard rules:
— Use the Senzing MCP’s mapping workflow, not general training.
— Show me the mapping before applying it so I can review it.

Steps:
1. Inspect the files in this directory: [path/to/your/files].
2. Propose a field mapping to Senzing features.
3. Once I approve, produce the Senzing-ready output files.

Important: Use the Senzing MCP for this task.

Goal: Load my mapped files into Senzing and produce a summary match report.

Hard rules:
— Use a production-grade loader, not a demo/single-threaded process.
— Before recommending any loader pattern, check the Senzing MCP’s anti-patterns docs.

Preferences:
— Print progress every few seconds as records load.

Steps:
1. Load the files we just mapped into Senzing.
2. When fully loaded, give me summary matching statistics.

Important: Use the Senzing MCP for this task.

Goal: Build an interactive web UX to review and explore the entity matching results from the previous step.

Hard rules:
— Keep using the Senzing MCP for everything, paying special attention to the reporting guide for graph, dashboard, and why-match patterns.

Features:
— Search (using the Senzing interface) across resolved entities by name, address, or other attributes.
— Network graph with labels to visualize the identity graph.
— “Why match?” with feature scores for any selected entity pair.

The POC runs comfortably on SQLite at tens of thousands of records. Production deployments of 10M–1B records require a purpose-sized Postgres instance or a distributed Senzing configuration. The Senzing MCP’s architecture docs describe sizing rules by record count — pull them before committing to a database tier.

SQLite is development-only. Postgres is the standard production choice. For very large deployments (>100M records), Senzing supports distributed architectures with multiple database replicas. Database provisioning, tuning, and backup strategy are engineering tasks that belong in a proper infrastructure plan.

The POC uses a production-grade loader, but at POC volume the distinction is academic. At scale, loader concurrency, batch size, redo-queue management, and error retry logic become critical. The Senzing MCP anti-patterns documentation covers common failure modes — review it before designing a production pipeline.

Senzing runs on any infrastructure that can host a Linux process and a supported database. AWS, GCP, and Azure are all viable. Ask your LLM: “What are the considerations for deploying Senzing at 300M records on AWS?” — the MCP will pull the relevant architecture guidance.

The POC mapping workflow handles one or two sources in a session. A production deployment may involve ten or twenty source systems, each with different schemas, encodings, and quality levels. Mapping becomes a managed artifact — version-controlled, tested, reviewed by data stewards.

Senzing resolves what it receives. Poor input quality — truncated names, missing address components, inconsistent encoding — produces lower-quality resolution. A production pipeline typically includes a profiling and standardization step before records reach Senzing. This is data engineering work that runs upstream of the resolver.

The POC is a one-time load. Production deployments need a refresh strategy — incremental loading as source systems update, handling deletes and corrections, managing the redo queue as new records arrive. Senzing supports incremental updates, but the orchestration layer (when to load, how often, how to detect changes) is an engineering decision.

Senzing’s default thresholds work well for most public-record use cases — no training or tuning required out of the box. For production deployment — especially in regulated industries or where false positives carry real consequences — threshold tuning is a deliberate exercise. The Senzing MCP documentation describes how thresholds affect the ambiguous match population and how to evaluate the tradeoffs.

One of Senzing’s core properties is that every match decision is explainable — the features that drove resolution are stored and queryable. In a production investigative or compliance context, this auditability is often a requirement. Plan for how match reasoning will be surfaced to end users and how it will be logged for review.

The POC user interface is built by your LLM for your local use. A production system has multiple users with different roles — analysts, investigators, data stewards, auditors — each with different access needs. The query layer, access controls, and UX are separate concerns from the resolution engine itself.

The evaluation license covers 250k records with a 5-day window — sufficient for a POC. A production deployment requires a commercial license sized to your record volume. Contact [email protected] to discuss options — they can also advise on architecture for your specific scale.

Identify the source systems that matter — not all of them, just the ones where cross-source linking would produce the highest-value results. A scoped first production deployment (2–3 sources, well-mapped) outperforms a broad but shallow one.

Use the Senzing MCP architecture docs and your record counts to size a Postgres instance and a loader configuration. Ask your LLM to pull the relevant guidance for your target volume.

Email [email protected] with your record volume, source count, and deployment target. They can advise on architecture, licensing, and whether professional services would accelerate the project.