Find conflicting definitions across the data dictionary

For: Data governance lead or analytics engineering manager

Pattern: Map, verify, reduceNeeds scaleDesigned for 40 to 1,500 agents

The pain today

Active customer, net revenue and churn are each defined several ways across tables, models and dashboards. Two teams bring different figures to the same meeting and nobody can say which definition each used.

The ask

I attached our data dictionary export, the SQL model files and the dashboard metric definitions. For each business term, show every definition in use, where the definitions differ in filters, time windows or joins, and quote the code or text behind each.

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Data dictionary export
  • SQL model files
  • Dashboard and metric definitions
  • Business glossary

The unit of work

One worker task per one table, model or metric definition.

Why a swarm fits

Each definition is read alone: one model file or one dictionary entry. Conflicts only appear when the small extracted definitions are laid side by side, which is the reconciler's job.

Not for

A small warehouse with one modelling layer. One engineer with search finds the conflicts faster.

The decision tree

6 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Planner, while planning

    Scope checkYes or no, with a probability

    Before work starts on a unit

    Does this model file or dictionary entry compute or define the business term, rather than only select a column that carries its name?

    Sees only: One business term and one SQL model file or dictionary entry

    Why: Pass-through models add noise; only places where the logic lives are worth reading.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.30 up to 0.60thenAccept
    • No: below 0.30thenSkip this unit
  2. Before workers, before a task runs

    Small worker or strong modelYes or no, with a probability

    Before a task runs

    Is the term's logic in this file a single query without macros, nested subqueries or window functions?

    Sees only: One SQL model file

    Why: Small workers misread templated or deeply nested SQL; those files go to the stronger model.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.40 up to 0.60thenEscalate to a strong model
    • No: below 0.40thenEscalate to a strong model
  3. After workers, the judge checks

    Evidence checkYes or no, with a probability

    After a worker answers

    Do the quoted SQL lines apply the filter, time window, join and grain exactly as the worker's extracted definition states?

    Sees only: The extracted definition and the SQL lines quoted for it

    Why: A misread filter would create a conflict that does not exist, or hide one that does.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenEscalate to a strong model
    • No: below 0.50thenReject and retry
  4. Reconciler, while merging

    Conflict checkA choice among options

    While reconciling

    In which respect, if any, do these two verified definitions of the same business term differ?

    Sees only: Two verified definitions of one term with their quoted logic

    Why: Names the difference precisely so metric owners can decide instead of investigate.

    • Same logicthenAccept
    • Different filter or windowthenMark unresolved
    • Different join or grainthenMark unresolved
    • Cannot comparethenEscalate to a strong model
  5. Run control, between rounds

    Retry or stopYes or no, with a probability

    After a rejection or low confidence

    Does this definition depend on an upstream model whose logic must be read before the comparison can be trusted?

    Sees only: One definition's quoted logic and the names of the models it selects from

    Why: Spends the stronger model only where a difference may be hiding one level up.

    • Yes: 0.60 or higherthenEscalate to a strong model
    • Unsure: 0.30 up to 0.60thenEscalate to a strong model
    • No: below 0.30thenAccept
  6. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Is either conflicting definition used by a dashboard or report named in the supplied metric definitions?

    Sees only: One conflict and the list of dashboards using each variant

    Why: Choosing the standard definition is a business decision for the governance lead and metric owners.

    Accountable: The data governance lead and metric owners decide which definition becomes the standard.

    • Yes: 0.50 or higherthenAsk a person
    • Unsure: 0.20 up to 0.50thenAsk a person
    • No: below 0.20thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model lists the business terms and finds which files and entries mention each one.

    Decisions here:1. Scope check

  2. Workers

    Small fast workers from an open-weight family, one per definition, extracting filters, windows and joins with the code quoted.

    Designed for 40 to 1,500 agents, one worker task per one table, model or metric definition. Each worker receives only its own unit.

    Decisions here:2. Small worker or strong model

  3. Judge, from a different model family

    A decision model from a different family checks the extracted logic against the quoted SQL or text.

    Decisions here:3. Evidence check

  4. Reconciler

    A strong reasoning model groups definitions per term and shows exactly where they differ.

    Decisions here:4. Conflict check5. Retry or stop

  5. Accountable person

    The data governance lead and metric owners decide which definition becomes the standard.

    Decisions here:6. Person decides

Checked before anything is accepted

  • Every extracted rule quotes the SQL lines or dictionary text it came from
  • Definitions that depend on an upstream model are traced one level up before comparison
  • Differences are stated as filter, window, join or grain, not as a vague mismatch
  • Terms with a single definition are listed as consistent, with the source

What comes back

  • Per business term: every definition in use, with code quotes
  • Difference table: filters, time windows, joins and grain
  • Dashboards and models using each variant
  • Columns documented one way and computed another

What to measure

  • Share of reported conflicts metric owners confirm
  • Conflicts found later that the run missed
  • Engineer hours per term reconciled
  • Cost per definition read

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

Cross-check a source-to-target mapping before migration

For: Data migration lead or solution architect moving a legacy system to a new platform

The mapping sheet has thousands of fields, filled in by different people from column names.

Pattern: Cross-examinationNeeds scale6 decisionsDesigned for 40 to 2,000 agents