Design a Freshness Policy by Field

Start with the decision that needs fresh evidence

Ask what would go wrong if a field changed after collection. A stale executive role can route a message to the wrong person. A closed vacancy can make a hiring reference awkward. An outdated platform label can place a company in the wrong agency campaign. A slightly old description of a stable product category may have much less effect. These differences should drive the review policy.

The Government Data Quality Framework treats timeliness in relation to the period data represents and the use it serves. That principle is more useful than assuming all data has a fixed shelf life. For account research, translate it into a question: how recent must the evidence be for this particular decision, given the consequence of being wrong?

Document the intended use beside the field. A historical platform record may be perfectly suitable for a migration-history analysis but unsuitable for a current-platform prospect list. A former executive can be relevant to company history while being inappropriate for present-day outreach routing. Freshness is therefore not only age; it is alignment between the evidence period and the claim being made.

References: Government Data Quality Framework: timeliness ↗

Keep observation, publication, and event dates separate

The observation date is when the researcher inspected the evidence. The publication date is when the source says it was published or updated. The event date is when the underlying change occurred, if known. These dates can differ widely. Reading an old announcement today does not make the appointment current, and a newly published case study can describe a project completed much earlier.

Store unknown dates explicitly. Do not copy the access date into an event-date column just to avoid blanks. If a source displays an update date without explaining what changed, preserve that date as source metadata rather than treating every factual statement on the page as newly confirmed. The record should say what the timestamp actually describes.

For a small team, the minimum practical schema is value, observed_at, source_url, source_date when available, review_due, and freshness_status. Add event_date and valid_from or valid_to when the business question requires history. Keep the data types and time-zone convention documented so that imports do not silently reinterpret dates or compare incompatible formats.

Group fields by how they can change

Create a short inventory of field families: entity identity, business description, locations, current roles, contact channels, public offers, technology observations, vacancies, and dated events. The categories help you think about change mechanisms. Roles can change when people move; vacancies can close; offers can be revised; web technologies can differ across surfaces even on the same day.

Do not assign a supposedly scientific decay rate without relevant evidence. You can choose an operating interval as a policy decision and label it accordingly. Then adjust it using your own correction history and the campaign's needs. A policy that starts with clear reasoning is more defensible than a precise-looking schedule copied from an unrelated dataset.

Use a separate current-use requirement for especially consequential fields. A company identity may be relatively stable, yet a redirect or acquisition can make an old match dangerous. A technical platform check may be recent but still too narrow for a company-wide claim. Freshness never substitutes for correct scope or source quality.

Define freshness states that change behavior

Use a status model that distinguishes recent evidence from confirmed current truth. 'Within review interval' can mean that the scheduled review is not due; it should not imply that the company could not have changed yesterday. 'Review due' means the policy requires another look. 'Historical' means the evidence is intentionally retained for a past period. 'Superseded' means a later supported value has replaced it.

Keep source uncertainty separate from age. A recent but ambiguous observation is not fresh confirmation. An old but well-supported historical fact can remain useful indefinitely for a historical question. A record may therefore have both an evidence status and a freshness status. If the interface can display only one label, retain the underlying fields elsewhere so the simplified view does not destroy meaning.

Specify what each status permits. A review-due optional field may remain visible with its date. A review-due mandatory platform field may block entry into a current-platform campaign. A superseded contact should stay out of active routing even if it remains in the archive. The state model becomes useful only when the team knows which action follows.

Choose intervals as explicit policy assumptions

Select a starting interval by considering volatility, consequence, review effort, and the next planned use. A team might choose to review active job postings at each campaign launch, current contacts before a new outreach cycle, and stable product descriptions at a less frequent scheduled review. These are illustrative decisions, not externally validated guarantees. Write the reasoning so that future changes can be assessed.

Combine calendar checks with event triggers. A scheduled review catches gradual staleness, while a redirect, role-change announcement, returned message, revised product page, or buyer correction can trigger immediate re-evaluation. Event triggers should identify the affected fields rather than invalidating an entire profile automatically. A contact departure does not necessarily change the company's product category.

Set a stop rule for repeated inconclusive refreshes. If a field cannot be confirmed publicly after an agreed search, change it to unresolved with the latest review date. Reopening the same page every day does not create evidence. The policy should allow abstention, escalation, or a revised campaign criterion when the public information is insufficient.

Worked example: one account, three different clocks

Imagine the fictional company Ridgeway Systems. Its service pages were reviewed on September 1, a named operations leader was researched on August 10, and a job posting was observed on October 1. A campaign is prepared on October 11. The file's latest update is October 1, but that date belongs only to the vacancy observation and cannot make the leadership role current.

The team's illustrative policy requires role confirmation before role-specific outreach and vacancy confirmation at campaign preparation. The service description is reviewed on a separate schedule unless new evidence suggests a change. A researcher reopens the leadership page and confirms the person remains listed, then finds that the job posting has closed. The product description remains usable within its stated policy.

The refreshed record now contains different outcomes: current role evidence observed October 11, vacancy marked closed or historical with its earlier observation preserved, and service description still dated September 1. The campaign can use the role if other requirements are met, but it should remove the hiring reference. Updating the entire row to October 11 without field-level history would hide this useful distinction.

Worked example: a platform label survives a site change

The fictional retailer Juniper Supply was observed with Platform A on its store domain in July. In October, its homepage shows a new design and a separate site-builder trace. A simplistic refresh overwrites the company platform with the site builder and declares a migration. That conclusion confuses a marketing surface with the transactional system and assumes a change that has not been established.

The reviewer compares like surfaces. The July record concerns the store domain, so the October review should inspect the relevant current store pages and document what can be observed there. If the commerce evidence remains Platform A, the marketing redesign does not establish a commerce migration. If the old store redirects and the new checkout evidence is unavailable, the current commerce platform may remain unresolved.

The freshness policy should retain the July observation as history, add the October surface-specific findings, and state whether the current claim is supported. A 'reviewed today' badge can then coexist with an unresolved current-platform value. The review is fresh; the desired fact is still unknown. That is a more accurate result than forcing a new label into the old field.

Build a review queue around consequence

Create a queue that combines review due dates with field importance. Place blocked company identities, required current contacts, and mandatory campaign criteria ahead of optional descriptive fields. A useful queue entry says which field needs review, why it matters, what evidence was previously used, and what would count as a successful resolution. Avoid assigning a vague task to 'refresh the company.'

Group related work where it saves effort. A current leadership page may resolve several role fields at once, and a revised product page may update both classification and offer fit. Record each field's actual result even when the page visit is shared. Do not mark unrelated attributes refreshed merely because the company website was open in the browser.

Reserve a review path for buyer feedback. A salesperson who learns that a person left or a product was discontinued has actionable information, but it should be recorded with provenance and scope. The feedback may supersede a public page or may need clarification. Keeping it separate until adjudicated prevents an informal note from silently rewriting every downstream dataset.

Preserve changes without creating contradictory active values

Keep one clearly designated current value per field when the application requires it, alongside a history of previous observations. The history should show old value, new value, observation dates, source references, and reason for change. This supports audit and helps distinguish a genuine business change from a corrected research error.

Do not label every difference a migration or event. A platform label can change because the method improved, a company match was corrected, or a different surface was inspected. A role can change because a typo was fixed. Include a change_type field such as observed change, correction, scope change, or unresolved conflict when the distinction matters to analysis.

Protect newer corrections from older imports. If a team uploads an archived spreadsheet after a fresh review, the import process should not overwrite the current field merely because the file is being processed later. Compare evidence dates and authority rules, not just ingestion time. This is a workflow requirement to test explicitly when setting up recurring enrichment.

For example, store an old platform observation under its original web-property identifier even after the company rebrands. If the domain relationship changes, record that relationship separately. Otherwise a future comparison may treat two different sites as consecutive observations of the same surface and produce a false migration history. Historical usefulness depends on preserving identity as carefully as preserving dates.

Refresh dependent scores and message suggestions

A company score can become stale even when most descriptive fields remain accurate. If the offer requires an active vacancy, the closure of that vacancy may change eligibility. If a named buyer leaves, the suggested approach may need a new stakeholder. If a service line disappears, the seller-specific fit rationale may no longer hold.

Record which inputs each important score or recommendation depends on. When one changes, flag the dependent output for recalculation or review. A general company summary may need only a sentence update, while an offer-specific dossier may need a new conclusion. The right action depends on the claim's role in the decision, not the number of characters that changed.

Review outreach wording before use. A fresh role check does not refresh an old expansion claim, and a current company profile does not validate a previously drafted pain hypothesis. The message should use supported current facts and present open questions honestly. A buyer can find an account relevant without claiming that it is currently seeking a supplier.

Measure whether the policy improves decisions

Track review-due fields, completed reviews, confirmed changes, unresolved refreshes, and corrections discovered at use. These measures help you see whether the queue is keeping pace and which fields produce the most meaningful changes. They do not require inventing a universal data-decay rate. Start with your own observed workflow and retain the denominators.

Investigate recurring late discoveries. If roles often change before the next scheduled review, tighten the relevant use trigger or improve the source. If optional fields consume most review time without affecting decisions, reduce their priority. If many reviews remain inconclusive, reconsider whether the field is publicly researchable or whether the buyer can provide an additional input.

Separate policy compliance from truth. A field can be within its review interval and still be wrong; a review can be completed on time and still misread the source. Audit accuracy independently. The freshness report should show when evidence was checked, while a claim-quality audit checks whether the evidence was interpreted correctly.

Launch a maintainable freshness policy

Begin with the fields that control the next campaign rather than attempting to refresh every possible attribute. Assign an owner, define the date meanings, write the review triggers, and test the status transitions on a few examples. The first version should be small enough that the team can explain it without consulting a large manual.

Before sharing a delivery, include the evidence dates and material freshness limitations. If the service delivers research once, do not imply an ongoing monitoring commitment. For a recurring internal process, document who operates it and how failures or overdue work are surfaced. A calendar rule with no responsible owner is a reminder, not a functioning policy.

• Identify the decision and consequence associated with each essential field.
• Separate observation dates from source publication and business event dates.
• Choose illustrative starting intervals and record why they fit the use case.
• Add event triggers for corrections, redirects, role changes, and new campaign use.
• Define current-use, review-due, historical, superseded, and unresolved behavior.
• Preserve old observations and label genuine changes separately from corrections.
• Revisit scores, routing, and message suggestions when their inputs change.
• Measure queue completion and accuracy without presenting review age as certainty.