How to Compare LeanData or Custom L2A Against a Deterministic Match
You already run LeanData, a custom Flow build, or years-old consulting-built L2A. The matches feel opaque, the match field feeds assignment rules, and nobody wants to touch it without evidence. Shadow the incumbent with a deterministic matcher, produce a disagreement report, and decide if promotion is justified — without writing anything.
Published April 18, 2026 • Discovery-first L2A is currently in private beta
Short answer
Start discovery against the incumbent match field, then run the shipped L2A match-health scout. The review writes nothing customer-owned and produces an evidence package for deciding whether a promotion path is justified.
The workflow
Five steps. Nothing customer-owned is written until step five is explicitly approved with an acknowledged risk hash.
Point discovery at the incumbent field
Point Architect discovery and the working-session review at the incumbent match field before any replacement path is designed.
Scout in shadow
Run the shipped L2A match-health scout and review a sample of incumbent matches against the discovery-first decision taxonomy.
Open disagreements.csv
The buying signal is the disagreement list — rows where the deterministic decision differs from the incumbent value. Every row carries a decision code.
Review blind_spot_digest.md
What the matcher could not resolve: consumer-email-only leads, parent/child collisions, inactive candidate accounts, unknown-risk fields. Honest companion to the safe-match count.
Decide whether to promote
Promotion to shared_existing requires an acknowledged risk audit hash. Observe-only stays safe indefinitely.
Start discovery
Creates the L2A Architect project that collects Lead and Account context before the incumbent field is changed.
g-gremlin autopilot architect init l2a_association_engine \
--variant salesforce \
-p target_sandbox=dev \
-p prod_org_alias=prodScout in shadow
Measures the current match-health profile and feeds the working-session disagreement review. No customer fields change.
g-gremlin scout run lead_to_account_match_health \
--param lookback_days=30 \
--param match_rate_threshold=0.7 \
--format json \
--output l2a_match_health.jsonWhat the disagreement report tells you
Each row in disagreements.csv is a testable claim: either the incumbent field is right, or Gremlin is. The decision code and evidence chain let operators judge without a threshold argument.
| Signal | Meaning | Suggested action |
|---|---|---|
| Gremlin safe, incumbent null | Incumbent missed a deterministic match | Candidate for shared_existing if_empty_only |
| Gremlin review, incumbent set | Incumbent auto-resolved ambiguity | Manual review — the matcher declined to pick |
| Gremlin safe, incumbent different | Two systems picked different accounts | Trace the lead to see which evidence is stronger |
| Gremlin blocked, incumbent set | Incumbent wrote a value Gremlin would refuse | Likely routing-driven — risk audit the downstream |
FAQ
How do I audit LeanData matches before touching them?
Run the governed matcher in observe_existing mode pointed at the LeanData-populated field. Gremlin evaluates every open lead deterministically, compares against the LeanData value, and emits disagreements.csv without writing anything. The disagreement report is the artifact you hand to RevOps or leadership before any removal conversation starts.
Can I run a deterministic matcher alongside LeanData or a custom Flow build?
Yes. Observe_existing mode is specifically designed for this — it is read-only against the incumbent match field and writes only to a Gremlin-owned namespace (optional) or nothing at all. No routing changes, no territory writes, no lead conversion. The incumbent tool keeps running as-is while you collect evidence.
What does an observe-existing L2A review do?
It treats the existing customer L2A field (typically Account_Match__c or similar) as evidence, compares a sampled set of incumbent values against the discovery-first taxonomy, and writes nothing customer-owned. The output is a review artifact, blind-spot summary, and working-session recommendation.
Why would I run a matcher that does not write?
Because the incumbent field likely feeds assignment rules, Flow, or territory logic. Writing it without evidence can change routing behavior. Observe_existing produces the evidence — a decision code and candidate account chain per lead — before any field is touched.
How do I hand disagreements to RevOps?
Share disagreements.csv and blind_spot_digest.md. Each row lists lead_id, email, gremlin_decision_code, gremlin_candidate_account, existing_field_value, and agreement. Operators sort by decision code or candidate account and mark rows for apply or escalation.
When do I graduate from observe_existing to shared_existing?
After the downstream automation risk audit is acknowledged and the customer field has been classified as low_risk or explicitly accepted as high_risk. Shared_existing also defaults to if_empty_only semantics, so non-empty rows yield L2A_BLOCK_SHARED_FIELD_NONEMPTY instead of overwriting.
Can I keep running observe_existing forever?
Yes. It is a fixed-scope diagnostic engagement and a permanent compare surface. Many teams run it indefinitely alongside their existing routing stack because the disagreement report and blind-spot digest are useful inputs on their own.
Keep the conversation going
These pages are meant to help operators solve real problems. If you want the next guide, grab the low-friction option. If you need the implementation, not just the guide, book time.
Get the next guide when it ships
I publish architecture guides grounded in real implementations. No generic AI filler.
Use your work email so I can keep the list useful and relevant.
Need the implementation, not just the guide?
Book a 15-minute working session with Mike right on his calendar. Tooling, consulting, or a mix of both is fine.
Open Mike's calendarIf you want me to come in with context, leave your email and a short note before the call.