Skip to main content

Senzing Cookbook

Place Settings

A place setting is how you serve and explore the resolved data — the presentation layer a diner actually interacts with. These are reusable building blocks that recipes reference instead of repeating the prompt — not recipes themselves.

Place-setting rules (apply to any place setting; inherited by recipes that serve through one):

  • → Populate the UX only from a Senzing mart and/or the SDK — no direct database queries.
  • → Follow the Senzing MCP’s reporting_guide for query patterns, graph layouts, and why-match interfaces.
  • → Render a network graph only for a selected entity, never the whole graph at once (it’s unreadable at scale).

The place settings

Good for POCs

Simple Web Visualizer

Author: Clair Sullivan

A lightweight, single-screen web UI to review and explore resolution results. Good for POCs.

Features

A summary dashboard with drill-down; search (Senzing Search — by name, address, other attributes); a network graph (per selected entity) with a legend; cross-source entities listed at the top; everything on one screen, no scrolling where possible.

Canonical prompt

Prompt · Simple Web Visualizer
Goal: Utilizing the data already loaded into Senzing, create an interactive web visualizer including a summary dashboard and the ability to explore entities, including a network graph.

Hard rules:
— Use the Senzing MCP. Do not rely on general training.
— Don't forget the previous Hard Rules.
— Always confirm that the website is responding before completing this task.
— Only use a Senzing mart and/or the Senzing SDK to populate the UX. Do not use any direct database queries.
— Only present the network graph based on a selected entity. Never the whole graph at once.
— Always confirm that the web visualizer is responding before completing this task.

Features:
— On the network graph visualization, present a list of entities - with the cross-source entities at the top - that the user can click on to select which entity to visualize in the graph.
— The UX should include a match summary screen with drill-down options.
— The UX should include a search feature, using the Senzing 'Search' method (including search by name, address, and other attributes).
— Present a network graph with labels to visualize the related entities.
— Keep visualization elements to one screen, no scrolling required, wherever possible.
— Provide a legend for the graph.

Used by: Fraud Check with CORDs (Clair).

Richer / production serving

Entity Browser

Author: Nigel DeFreitas

A fuller web UI for exploring the identity graph, with provenance and why-match. Good for richer or production serving.

Features

Search by name, entity ID, or exclusion status; resolved entities shown with their source-labeled records; a labeled network graph of entity-record relationships; “Why match?” with feature scores for any selected pair.

Canonical prompt

Prompt · Entity Browser
Important: Use the Senzing MCP's reporting_guide for this task.

Goal: Build an Entity Browser web UI that loads the resolved entity export from the previous step and lets users explore the identity graph.

Hard rules:
- Follow the Senzing MCP reporting_guide for all query patterns, graph layouts, and why-match interfaces.

Features:
- Search across resolved entities by name, entity ID, or exclusion status (using the Senzing query interface).
- Show resolved entities with their linked source records, clearly labelled by source.
- Network graph with labels to visualize the identity graph and entity-record relationships.
- "Why match?" with feature scores for any selected entity pair.

Used by: Healthcare Exclusion Screening (Nigel).

Coming soon: MDM Lite — a lightweight MDM screen with custodian / stewardship functions (Jonas). (planned)

ⓘ

Note on stewardship (merge/split/correct): a place setting that only displays is safe; one that lets a steward change entities is seasoning the dish — it changes the resolved truth for every view. Gate those writes (confirm each merge/split; never automatic).

Ready to serve