Direct answer: a score or signal should stop triggering marketing and sales when the supporting evidence changes faster than the company can verify it. Do not assign one universal time-to-live. Set validity by evidence type, rate of change, consequence of error, and recomputation capability. At expiry, the system must recompute, lower confidence, request review, use a safe rule, or take no action. Keeping the last value because the field remains populated is a hidden policy—and often the worst one.
A lead can retain a 92 score from a pricing-page visit 45 days ago. A customer may receive an offer from yesterday's inventory. A recommendation may remain active after a purchase, cancellation, support case, or territory change. The problem is broader than model drift: the organization has confused when something happened, arrived, was computed, and remained valid for action.
Use the Freshness-to-Action Contract
- Decision and owner — the action the value unlocks, the accountable operator, and the unacceptable error.
- Evidence — event, attribute, preference, commercial state, score, or recommendation; source and grain.
- Clocks — occurred, ingested, computed, confirmed, and expires.
- Validity rule — duration, change condition, or both, including channel and market exceptions.
- Expired behavior — recompute, query the source, reduce weight, review, suppress, or stop.
- Dependencies — identity, consent, inventory, capacity, territory, opportunity, service, and model.
- Version — logic, features, source, window, timezone, and configuration.
- Execution evidence — value read, age, decision, action, outcome, correction, and override.
The contract belongs to a decision, not a field. A business email may remain correct for months yet be insufficient to authorize contact. A declared preference should not decay like a click; it remains until changed or withdrawn, with confirmation when purpose or context changes. Price, balance, open case, or availability may require minutes. A predictive score needs a computation time, model version, horizon, and invalidation rule.
Separate five business clocks
- Occurrence — when the interaction, purchase, change, or signal happened.
- Ingestion — when CRM, CDP, or the warehouse received the fact.
- Computation — when a rule, model, or aggregate produced the value.
- Confirmation — when a source or person verified that it still applies.
- Expiration — when the value can no longer release the action without new evidence.
One updated_at field cannot represent all five. A batch may touch the record today using an old event. An operator may correct a label without renewing its evidence. Recomputing can emit the same score without observing anything new. Google Cloud recommends timestamps and point-in-time lookup for time-sensitive features. The same discipline helps reconstruct what the system actually knew when it acted.
Validity changes by evidence class
- Declared preference — preserve source, scope, and withdrawal; reconfirm when purpose or context changes rather than applying arbitrary decay.
- Engagement — use a window and decay aligned to the buying cycle; separate likely human activity from scanners or privacy proxies.
- Fit and firmographics — refresh after company, territory, role, size, or offer changes; do not treat an old profile as permanent truth.
- Commercial state — payment, order, opportunity, service, consent, and inventory require authoritative sources and transitions, not only a timer.
- Score or recommendation — store time, version, features, and horizon; invalidate when a critical dependency changes.
HubSpot supports configurable event-score decay. Microsoft documents different refresh cadences for new and updated leads. Salesforce explains that stored formulas do not update automatically while calculated insights can run on a schedule. Those capabilities are useful, but a product cadence is not automatically a business SLA.
Example: the high score that should not open another queue
Consider a U.S. B2B company. A lead attended a webinar and visited pricing, received a high score, and entered an SDR queue. The account then opened an opportunity through a partner and moved to a named-account team. Forty days later, a batch reproduces the score without checking the active deal or owner. Automation creates another SDR task and starts a nurture.
The fix is not changing 92 to 78. The contract makes active opportunity, owner, and contact state preconditions; intent events have a window; account reassignment invalidates the match; the executor rechecks CRM immediately before action. If critical evidence is stale, it prepares context for review instead of sending.
Run a six-week pilot
- Week 1 — choose one action and inventory the 10 to 20 fields, events, and scores it uses; measure how often decisions read values without reliable dates.
- Week 2 — assign source, five clocks, owner, dependencies, and expired behavior; identify what the platform recomputes versus merely stores.
- Week 3 — implement validity flags and decision logs in shadow mode without changing routing or messages.
- Week 4 — compare current decisions with blocked, recomputed, and reviewed decisions; investigate false expiry and artificially refreshed evidence.
- Week 5 — release a small cohort with fallback and daily review; test delay, duplicates, timezone, correction, state change, and source outage.
- Week 6 — evaluate outcome, risk, cost, and operating load; keep, repair, expand, or stop.
Deliverables include a decision-to-evidence inventory, versioned contract, clock dictionary, validity rules, recomputation queries, action gateway, logs, dashboard, runbook, and investment decision. NIST recommends production monitoring for drift, anomalies, and reliability; the business still must define process-specific limits.
Choose proportional architecture
- Native configuration — fast for simple decay, filters, and refresh; constrained by platform objects, cadence, and history.
- Action-time rule — rechecks source and state before execution; adds calls, latency, and failure handling.
- Warehouse or feature table — preserves history and point-in-time correctness; requires identity, modeling, processing, and operations.
- Decision gateway — centralizes validity, authorization, and fallback across CRM, media, commerce, and service; adds engineering responsibility.
Cost grows with decisions, sources, frequency, regions, identities, history, SLAs, volume, corrections, environments, rules, and downstream actions. Real-time computation everywhere can be expensive and fragile; a daily batch may be too slow for consent, inventory, price, or an open case. The contract helps fund low latency only where risk and value justify it.
Measure valid actions—not updated fields
Measure evidence age at use, actions blocked by expiry, successful recomputation, refresh latency, review backlog, overrides, false blocks, corrected actions, and cost per valid decision. Connect conversion, revenue, or contribution only among eligible, mature units. Lower action volume may be an improvement when it removes inappropriate contact; a higher average score may only reflect a changed window.
Use https://makinai.co/insights/en/ask-observe-infer-customer-preferences-ai-crm-personalization to separate declared preference from inference, https://makinai.co/insights/en/ai-lead-scoring-model-drift-pipeline-quality to monitor model deterioration, https://makinai.co/insights/en/blank-crm-fields-ai-missingness-freshness-contract to govern missingness and freshness, and https://makinai.co/insights/en/ai-customer-revenue-state-reconciliation-crm-commerce to reconcile commercial states. If a score triggers queues, messages, or offers without computation time, expiry, and fallback, bring MAKINAI, through https://makinai.co/services/en/crm-ecommerce-commerce-transformation, one decision, 30 days of logs, and its supporting fields. We can scope the smallest pilot before replacing the stack.
The sources document platform capabilities and monitoring practices. They do not establish universal TTLs or prove commercial lift. The contract, five clocks, pilot, and economics are MAKINAI editorial recommendations to validate in the real workflow.