Data enrichment freshness rules: 9 checks that keep scoring and routing honest

Bad enrichment is rarely about missing fields. It is stale fields that look complete: a title, a headcount band, a tech stack that all read as filled, so scoring trusts them and routing fires on them, when in reality they changed two quarters ago. If you want lead scoring you can rely on and clean handoffs, you need enforceable freshness rules sitting on top of enrichment, not a one-time run that you assume stays true.

Chronic runs as an autonomous revenue operator: it does discovery, enrichment, signal scoring, outreach, and reply handling against your revenue goal, and surfaces approvals for the decisions that matter. The rules below are the data hygiene that makes that work. They apply just as well if you keep your records in HubSpot, Salesforce, or a spreadsheet. The point is the same: enriched data is only useful for as long as it stays true, and freshness has to be a system, not a hope.

Why freshness rules matter (and why "enriched" is not the same as "correct")

Most B2B teams already accept that contact and account data decays quickly. Industry estimates commonly put B2B contact decay at roughly 2 to 3 percent per month, which works out to somewhere around a fifth to a quarter of a database going wrong over a year, and it compounds silently. Job changes are the biggest driver: with average job tenure under three years, a large share of contacts move roles annually.

That decay shows up in three painful places:

• Bad scoring: the model trusts "VP Marketing" and "200-500 employees," but both changed.
• Misrouting: the SDR queue fills with leads that should go to an AE, or an SMB gets sent down the enterprise track.
• Damaged outreach: personalization references the wrong role, the wrong tech stack, or the wrong stage, which kills replies and, at scale, hurts deliverability and the sender's reputation.

Data governance research is consistent that poor data quality carries real cost. Gartner's widely cited figure puts the cost of poor data quality at about $12.9M per year on average, drawn from its 2020 survey of data quality buyers. (Gartner, via BRC) Whatever the exact number for your business, the direction is clear: stale data is not free.

Freshness rules are how you turn "data decay is real" into a system that prevents drift.

9 freshness rules that keep scoring and routing honest

1) Set TTLs by field, not one global "re-enrich every X days"

Rule: every enriched field gets an explicit time-to-live (TTL) and a "stale" state.

A single global refresh cadence is the fastest way to waste spend and still miss the changes that matter. Titles change faster than HQ address. Tech stack changes faster than NAICS code. Headcount drifts, but not daily.

A TTL baseline to adjust to your market:

• Contact title / role: 60-120 days
• Department / function: 90-180 days
• Email deliverability status (valid / invalid / risky): 7-30 days, or event-driven
• Company headcount / size band: 90-180 days
• Funding / growth signals: 30-90 days (if you route on them)
• Tech stack / installed technologies: 60-120 days
• Industry, HQ location: 180-365 days
• Website domain: event-driven, with a 365-day fallback

Make it enforceable:

• Store field_last_verified_at and field_ttl_days.
• Compute field_is_stale and feed that into routing and scoring.
• If a lead is high-fit but key fields are stale, force a refresh before assignment.

Why it prevents misroutes: routing fires on fresh facts instead of last quarter's snapshot.

2) Enrich on create vs enrich on stage change (two different jobs)

Rule: split enrichment into two pipelines:

1. Creation enrichment (lightweight, fast, cheap)
2. Lifecycle enrichment (heavier, contextual, stage-based)

Creation enrichment answers:

• Is this person real and reachable?
• What account do they belong to?
• Do they match the ICP at a coarse level?

Stage-change enrichment answers:

• Do we have the details the next action needs?
• Is this now worth a higher-cost enrichment (deep firmographics, technographics, intent)?

Example stage triggers:

• New lead created → verify email + basic company match
• MQL or inbound demo request → full account profile + key contacts + tech stack
• Opportunity created → re-verify title, map the buying committee, confirm account hierarchy

Why it prevents bad scoring: scoring behaves far better when it has the right fields at the right time, not a random mix of deep and missing data.

3) Re-enrich on reality triggers (bounce, domain change, job change)

Rule: freshness is primarily event-driven, not calendar-driven.

Calendar TTLs catch gradual drift. Triggers catch immediate breakage.

High-signal triggers worth implementing:

• Hard bounce or repeated soft bounce → re-verify the email, look for an updated pattern, flag the record as needs-attention.
• Reply that says the person left ("I no longer work here") → run the job-change workflow.
• Website domain change detected → re-match the account and refresh every domain-derived field.
• Job-change signal from a provider → refresh title, department, seniority, and re-check routing.
• Account merge or duplicate detected → re-run contact-to-account matching for the affected contacts.

Practical, enforceable thresholds:

• 1 hard bounce → re-enrich immediately and suppress sending until resolved.
• 2 soft bounces in 14 days → re-verify and throttle.
• Email domain that does not match the company domain → queue for review or automated re-link.

Why it prevents misroutes: a lead who just changed jobs should not stay attached to the old account and the rep who owns it.

4) Add confidence scoring per field, and use it in scoring and routing

Rule: every enriched attribute carries a confidence score and a source type.

A field with no confidence attached is a trap, because it makes a guess and a verified fact look identical.

Minimum metadata to store:

• source (vendor name, first-party, or manual)
• confidence (0-100, or a graded scale)
• verified_at timestamp
• evidence pointer (optional, but useful for audits)

How to use it:

• Lead scoring should down-weight low-confidence fields.
• Routing should require minimum confidence on critical fields (size band, region, segment).
• Personalization should avoid low-confidence details. Do not name a tech stack install at 40 confidence in a first-touch email.

Why it works: you stop over-trusting enrichment that is filled in but not actually reliable.

5) Multi-source conflict resolution (deterministic rules, not last-write-wins)

Rule: when two sources disagree, resolve with a deterministic policy.

Last-write-wins is why databases rot. A weaker source arrives later, overwrites a stronger one, and nobody notices.

A clean default policy:

1. Human-edited beats everything (unless explicitly unlocked).
2. First-party observed (web-form domain, product telemetry, billing) beats third-party.
3. Higher confidence beats lower.
4. More recent verified_at breaks remaining ties.
5. If still tied, keep both in a history log and mark one active.

Example, headcount:

• Source A: 51-200 (verified 20 days ago, confidence 80)
• Source B: 201-500 (verified 3 days ago, confidence 55)
• The policy keeps A, flags a conflict, and schedules a targeted refresh rather than blindly flipping the segment.

Why it prevents bad scoring: scoring models hate label noise, and conflict policies reduce it.

6) Contact-to-account matching is a first-class system, not a one-time cleanup

Rule: every contact has a reliable account linkage, and the linkage is re-evaluated when key identifiers change.

If a contact is attached to the wrong account, everything downstream breaks: territory routing, account ownership, do-not-contact suppression, deal history, and enrichment spend (you pay to enrich the wrong company).

A practical matching hierarchy:

1. Normalized domain match (website domain, not just email domain)
2. Subsidiary and parent mapping (account hierarchy)
3. Company name plus location fuzzy match (fallback only)
4. Manual override, protected (see rule 9)

Enforce it with link confidence:

• account_match_confidence
• account_match_method (domain, hierarchy, fuzzy, manual)
• A low-confidence match blocks auto-routing.

Why it prevents misroutes: routing is usually account-based, even when the object you are routing is a lead or contact.

7) Enrichment write scopes (limit which fields can be written at each moment)

Rule: enrichment operates under a write scope that defines which fields it may update, and under what conditions.

Without scopes, a well-meaning enrichment run overwrites segmentation fields that routing depends on, rep-updated notes, custom lifecycle tags, and campaign-specific fields.

Recommended scopes:

• Create scope: identity and matching fields only (name normalization, email verification status, company domain, account match).
• Qualification scope: ICP and routing-critical fields (size band, geo, industry, seniority, function).
• Opportunity scope: buying-committee and personalization fields (tech stack, initiatives, department mapping).

Why it prevents bad scoring: scoring features stay stable and comparable over time.

8) Audit logging for enrichment (who changed what, when, and why)

Rule: every enrichment write is audit-logged with the why, not just the what.

This is governance, not only debugging. Privacy law reinforces it: the GDPR accuracy principle, Article 5(1)(d), requires that personal data be accurate and kept up to date, with reasonable steps taken to rectify inaccuracies. (GDPR text)

The log should capture:

• record ID
• field changed
• old value, new value
• source and confidence
• trigger reason (TTL refresh, bounce, stage change, manual request)
• timestamp
• actor (system, user, integration)

What you get right away:

• faster incident resolution ("why did routing break yesterday?")
• a clean path for a rep to flag "this is wrong" and see where the value came from
• the ability to measure vendor quality by field and segment

9) "Do not overwrite" protection for human-edited fields (with explicit unlock)

Rule: human-edited fields are protected by default. Enrichment can suggest a change, not force one.

This is where teams lose rep trust for good. A rep fixes a title, an enrichment run reverts it, and the rep stops maintaining hygiene altogether.

Two mechanics:

• Field-level lock: field_locked = true when a human edits it (or asserts it is correct).
• Unlock workflow: requires a reason, or requires confidence above a threshold from two independent sources.

Fields commonly worth protecting:

• persona tags
• buying-committee role
• notes about org structure
• a manually confirmed email
• account ownership, territory, or routing overrides

Why it prevents misroutes: manual routing overrides usually exist for a good reason. Protect them unless something explicitly invalidates them.

How these rules change what an autonomous operator can do

Chronic acts on this data continuously, so the quality of the rules above sets the ceiling on what it can safely do for you. Three concrete payoffs:

Lead scoring stops drifting

Scoring fails in two predictable ways: feature staleness (title, size, tech stack are wrong) and label noise (wrong account, wrong segment, source conflicts). TTLs, trigger-based re-enrichment, confidence, and conflict resolution give the model more consistent inputs, let you down-weight stale or low-confidence fields, and let you see which fields cause score instability. This pairs naturally with AI lead scoring and freshness-aware buying-window signals. (See Buying signals and scoring in 2026.)

Routing gets accurate because matching and freshness become gating checks

Routing should not be "IF employee_count > 200 THEN enterprise." It should be: IF headcount is fresh (TTL ok) AND its confidence clears a threshold AND account-match confidence clears a threshold, THEN route; otherwise refresh first or send to triage. That logic prevents misroutes and cuts reassignment churn, which improves speed-to-lead.

Personalization gets believable because you stop putting "maybe true" facts in emails

Outreach falls flat when it cites the wrong title, an outdated tool, or the wrong department. Using confidence and stale flags, the operator can personalize only with high-confidence facts, fall back to safer details (industry, category, verified initiatives) when it cannot, and skip the creepy-and-wrong moments. This is where lead enrichment and the AI email writer earn their keep: better inputs, better output.

Implementation template: the exact fields and checks to add

Use this as a practical checklist for whoever owns your data layer.

Metadata per enriched attribute (or per record group)

• verified_at (timestamp)
• ttl_days (integer)
• is_stale (boolean)
• source (string)
• confidence (0-100)
• write_scope (enum: create, qualify, opp)
• locked (boolean, for protected fields)

System workflows

1. On create: identity enrichment + account match
2. On stage change: scope-based enrichment (qualify, opp)
3. On bounce: immediate re-verification + suppression
4. On job change: refresh title and seniority, reroute if needed
5. On domain change: re-match the account + refresh domain-derived firmographics
6. Nightly stale sweep: queue refresh jobs by priority tier

Priority tiers for refresh (this is your cost control)

• Tier 1: active opps, hot inbound, high-fit leads
• Tier 2: nurture leads, target accounts
• Tier 3: long-tail database, closed-lost older than X

Common trade-offs (so you do not overbuild)

• More freshness means more spend if you refresh blindly. Solve it with TTLs, triggers, and tiers.
• More sources means more conflicts unless you add deterministic resolution rules.
• More automation means more distrust unless you protect human edits and show the audit trail.

If you are weighing how different stacks handle enrichment and field governance, it helps to benchmark on auditability and field control. (Chronic vs HubSpot, Chronic vs Salesforce, Chronic vs Apollo)

FAQ

What do enrichment freshness rules actually mean in plain English?

They are the operational rules that keep enriched data fresh, verifiable, conflict-resolved, and safe to use in scoring, routing, and outreach. In practice that means field TTLs, trigger-based refreshes, confidence scoring, write scopes, audit logs, and protection for human edits.

How often should we re-enrich records?

No single cadence fits every field. Use TTLs by field plus trigger-based refresh. High-churn attributes like titles and email validity need much shorter TTLs than stable ones like HQ country. Industry estimates of a few percent of B2B contact data decaying per month support short TTLs on contact attributes.

What causes more misrouted leads: stale fields or bad matching?

Bad matching. If a contact is linked to the wrong account, even perfectly fresh firmographics route incorrectly, because ownership, territory, and suppression flow from the account. Fix matching first, then freshness.

Should enrichment overwrite rep-edited fields?

Default to no. Protect human edits with locks, and require an explicit unlock or very high confidence from multiple sources. Otherwise you lose rep trust and quality degrades faster.

How do confidence scores improve scoring?

They let you down-weight uncertain features and cut noise. Instead of feeding the model "title = VP" as a hard fact, you treat it as "VP, confidence 60," or drop it when stale. That reduces score volatility and stabilizes routing when paired with freshness gating.

Do we need enrichment audit logs if we are not in a regulated industry?

Yes. Audit logs are how you debug routing incidents, vendor quality, and scoring drift. They also support keeping personal data accurate and up to date, which the GDPR accuracy principle treats as a standard worth following even for teams outside the EU. (GDPR text)

Put these rules into production this week

1. Pick 10 fields that your scoring and routing lean on most (title, size band, region, account match, tech stack).
2. Add verified_at + TTL + confidence for each.
3. Run two enrichment flows: light on create, heavy on stage change.
4. Add three triggers: hard bounce, job change, domain change.
5. Turn on do-not-overwrite locks for human-edited fields.
6. Log every enrichment write with source, confidence, and reason.
7. Update scoring and routing to refuse stale, low-confidence inputs and refresh before assignment.

If you do nothing else, do steps 1 through 4. That is the shortest path to fewer misroutes, cleaner scoring, and personalization that stops embarrassing your team.