ListMatchGenie

The _lmg_ columns

Every export includes a set of metadata columns prefixed with _lmg_. These tell you exactly what matched, how confidently, and why — without polluting your original data.

ListMatchGenie never modifies the original columns you uploaded. Instead, it appends a set of metadata columns to every exported row, all prefixed with _lmg_. These columns are the auditable, machine-readable record of what the Genie decided and why.

Because they all share the same prefix, you can filter, pivot, or programmatically strip them without breaking your original schema.

The columns you always get

_lmg_row_id

An integer assigned to each row of your source file, starting at 1. Preserved across cleansing and matching even if rows are collapsed by deduplication — so a row ID of 47 in the export always refers to row 47 of the original file.

Use this to join match results back to your source-of-truth system, or to point colleagues at specific rows without sharing the full file.

_lmg_match_status

One of match, review, or unmatched. This is the engine's classification for the best candidate found for this row. See Confidence scores for how classification works.

_lmg_match_score

The composite score of the best candidate, 0 through 100. Empty if _lmg_match_status is unmatched.

_lmg_master_row_id

The row ID of the matched record in the master file. Use this to look up full master-record details, or to detect when multiple source rows matched to the same master (a common audit check).

Empty if _lmg_match_status is unmatched.

_lmg_match_method

Which pass of the match engine produced this result. Values:

  • exact_id — matched on an identifier (email, NPI, account number, etc.)
  • deterministic — all comparable fields exact or near-exact
  • fuzzy — scored via the fuzzy scoring pipeline
  • phonetic — matched primarily via phonetic coding (names that sound alike)
  • manual — approved by a human in the review queue

Use this to audit your match quality by method. A healthy run is dominated by exact_id and deterministic when those columns are available; a run dominated by fuzzy suggests your data could benefit from more identifier enrichment.

The columns you get conditionally

_lmg_review_decision

Only present when _lmg_match_status started as review and a human resolved it. Values: approved, rejected, or empty if still pending.

_lmg_review_by / _lmg_reviewed_at

When a review decision was recorded, by whom (name) and when (ISO 8601 timestamp). Team-plan accounts get per-reviewer attribution; solo accounts show the account owner.

_lmg_distance_miles

Only present when ZIP radius matching was enabled. The great-circle distance in miles between source and master locations.

_lmg_cluster_id

Only present in contact dedupe mode. Source rows that the engine clustered together as probable duplicates share the same _lmg_cluster_id. Cluster IDs are stable within a single job but not across jobs.

_lmg_notes

Freeform annotations recorded during review. Useful for recording why a borderline case was accepted or rejected — the notes export with the results so downstream teams have the same context.

Per-field score columns (on request)

For audit-heavy use cases, you can opt in to per-field score columns — one score per comparable field, named _lmg_score_<field>. For a person match this expands to:

  • _lmg_score_first_name
  • _lmg_score_last_name
  • _lmg_score_email
  • _lmg_score_phone
  • _lmg_score_zip
  • _lmg_score_city
  • _lmg_score_state
  • _lmg_score_address

Each score is 0 through 100, or empty when the field was missing from one or both records. These let you see exactly which fields drove the composite score up or down.

Per-field score columns are opt-in because they substantially widen the export. Enable them in the Export step's "Include audit columns" toggle.

Pipe-safe by default

All _lmg_ column values are plain strings or numbers — no nested JSON, no special characters, no embedded commas in the value itself. You can process exports with grep, awk, or Excel without quoting gymnastics.

Column order in exports

Columns in a ListMatchGenie export always appear in this order:

  1. Your original source columns, in the order they appeared in your upload.
  2. Matched master columns, in the order they appeared in the master file. These are empty when _lmg_match_status is unmatched.
  3. _lmg_ metadata columns, in the order listed above.

This convention means your downstream tools never have to learn a new schema — they see their original columns first, followed by enrichment, followed by metadata.