- A Waterfall Is an Ordered Route for One Unresolved Field
- Move the Field Forward Only While It Remains Unresolved
- Read a Later Result as More Than a New Fill
- Put Verification and Lineage Around the Cascade
- Stop When Another Lookup Cannot Change the Field Decision
-
Frequently asked questions
-
What does waterfall enrichment include, and where does the definition stop?
-
Which parts of waterfall enrichment are observed directly and which are inferred?
-
What evidence should remain attached when waterfall enrichment enters a workflow?
-
When can waterfall enrichment change the next action without stronger evidence?
-
What does waterfall enrichment include, and where does the definition stop?
Waterfall enrichment is justified only when the next provider can add a previously unfilled, source-verified field or materially improve confidence or conflict resolution. Stop the sequence when another lookup cannot justify its cost or the risk of a harder-to-audit record.
A Waterfall Is an Ordered Route for One Unresolved Field
Start with a narrower question than, "How many providers can we put in a chain?" Ask, "Which one unresolved field is worth moving forward?" Before you route a record, name that field. Waterfall enrichment is an ordered route for it. A record arrives with something that matters still unknown, and the route gives one source the first chance to return an acceptable result before another source is considered. It is not a general promise to make a database fuller.
Why insist on one field? A sequence has no clear stopping point when its purpose is merely "more data." When you define the decision gap, you can tell whether a returned value fills it, duplicates a usable value, or creates a contradiction that someone must resolve. The route becomes meaningful only when the desired field, the acceptable result, and the use it will support are named before the first lookup.
Define the field before choosing a source
Start with a field decision, not a provider category. The question may be whether a record has a usable work contact, whether an existing value is current enough for its intended use, or whether two returned values can be reconciled. If you set that decision first, you do not need a perfect record. You need a stated condition for accepting, holding, or escalating the field.
Why provider count is the wrong unit of value
Use this test: judge the route by the field decision it can change. When you evaluate a first source, it may meet the condition and end the route. A later source can fill what remains unresolved, correct a stale value, strengthen confidence, or surface a conflict. If it does none of these, you are counting provider length, not value.
Move the Field Forward Only While It Remains Unresolved
What makes a cascade operational rather than decorative? Move a field only while it remains unresolved by its rule set. If you automate the route, Apollo's Waterfall Enrichment documentation, checked in September 2026, gives a useful picture of the possible workflow: ordered data sources alongside optional email or phone validation, CRM enrichment, stale-value refresh, and CSV export. It is not proof that every available source is necessary for every record.
The harder question follows immediately: what counts as resolved? When you inspect a field, it can be present yet still fail the condition because it is unvalidated, too old for the intended action, unsupported by its source, or in conflict with another value. Conversely, a field can be sufficiently resolved before every possible provider has been tried. Let the sequence follow the condition, not a habit of exhausting the chain.
Set what qualifies as an acceptable first result
Set the acceptance condition in the language of the next decision. It may require a source that can be retained, a validation state, an observation date, or a way to keep an uncertainty visible. The exact condition depends on the workflow. Can you name that condition before the provider order becomes automatic? If you cannot, the route is not ready to run.
Use a fallback when the current result cannot meet that condition
A fallback is justified when it can address the named deficiency, not simply because it is next in line. That is why a multi-provider cascade can be easier to automate than to audit. You can automate routing, but you still need the acceptance rule and a record of what changed before deciding that a new result remedies the deficiency. Measure marginal accepted yield against added handling and conflict risk.
Read a Later Result as More Than a New Fill
Does a later result matter only when the field was blank? No. When you receive a later result, it can also materially improve confidence in a value already present, identify that a value is stale, or produce a conflict that changes how the field should be handled. If every later result is called a simple fill, those distinctions disappear and a full-looking record appears more certain than it is.
That changes the role of waterfall tools. When you use a tool to route a record and deliver a result, the workflow still needs to retain which source supplied the value, what validation applies, and whether the new information changed the field state. Treat a new candidate detail as something to review in context, not as an automatic reason to overwrite the working record.
A later source can correct a stale value or strengthen confidence
The field outcome is not limited to accepted or blank. When you review it, you may preserve the existing value, replace it, mark it for recheck, or retain two values pending resolution. Record why that state was chosen. Without that record, a later provider can look like an improvement when it has only replaced one unexamined assertion with another.
Conflicting results need a recorded resolution, not last-write-wins
A conflict is a field state that needs an accountable decision. If you keep competing values long enough, you can identify their sources and the reason for the resolution. Do not let delivery order decide the canonical value. Escalate if the disagreement still affects the intended use and no documented rule resolves it.
Put Verification and Lineage Around the Cascade
The sequence itself is not the control. The control is the information travelling with each field. If you compare providers, Lusha's Search documentation, checked in September 2026, describes multiple data-source categories, cross-checking, stated continuous refresh for static attributes, and CRM, CSV, and API delivery routes. Demandbase's marketing-data FAQ describes overlapping sources, category-specific update statements, and configurable export delivery while distinguishing delivery schedule from field freshness.
That distinction answers a common mistake. When you receive a field today, it is not necessarily a field observed or refreshed today, and a cross-check is not an automatic resolution of disagreement. Retain the distinctions that affect acceptance. Otherwise, delivery can create an appearance of freshness and agreement that the underlying field cannot support.
Keep source, validation, freshness, and delivery state with the field
Keep each label because the field decision may need the distinction. When you retain source, validation state, freshness information, and delivery state together, you can see where the field came from, whether presence means acceptance, whether delivery timing differs from field timing, and whether movement through CRM, CSV, or API changed the decision.
Place waterfall tools inside the control flow, not in a ranking
Do not start with the abstract question of which provider looks strongest. If you ask whether this next route can deliver information that changes the field decision while preserving the evidence needed to audit it, you have the more useful test. That is also the useful question when an OKKI Go workflow passes a reviewed company context into later research. Place the provider inside a controlled route, not at the top of a generic leaderboard.
Stop When Another Lookup Cannot Change the Field Decision
Use one bounded scenario: a record needs one field for a defined next action. If you model the route, accept the first result only if its source, validation state, and freshness are sufficient for that action. The first lookup returns a value, but the condition is not met, so the route advances. A later lookup supplies information that lets the team accept the field, hold it, correct it, or send it to resolution. The useful result is the changed decision, not the number of lookups completed.
What happens after an accepted result meets the intended use? Stop. If you have met the condition, more providers may still be available, but they do not automatically create more value. Continue only when a later lookup can plausibly fill something still unresolved, materially improve confidence, or give the evidence needed to resolve a conflict. In an OKKI Go research flow, the same stop rule keeps further discovery tied to a reviewed decision gap instead of turning every available detail into a new research task.
- Advance only when the next lookup has a named unresolved field to address.
- Stop when no expected result can change the field decision enough to justify its added cost or conflict risk.
Stop after a verified result meets the intended use
The stop condition is deliberately modest. It does not say the record is complete forever, or that no later source could ever disagree. When you change the intended use, you may change the acceptance condition too. Until then, the present field is verified enough for the named use, and another lookup has no expected decision-changing value that justifies its cost or added conflict risk. That is a new decision, not a reason to keep the old cascade running without limit.
Questions to ask when a conflict or no-gain result remains
No-gain is a reason to stop, not a missing step. Ask what unresolved field the next lookup would address, what source or validation evidence could make its result acceptable, and who would record a conflict resolution. If you cannot name an answer that changes the field decision, the route has reached its proper boundary.
Waterfall enrichment is not a race to extend a provider chain. It is a decision route for a field that remains unresolved. Before the next lookup, ask whether it can add verified value, materially improve confidence, or resolve a conflict. If not, what decision would it change?
Frequently asked questions
What does waterfall enrichment include, and where does the definition stop?
It is an ordered fallback route for a specific unresolved field. It includes the conditions for accepting a result, moving to a fallback, retaining source evidence, and stopping. It does not mean asking every available provider for every possible field.
Which parts of waterfall enrichment are observed directly and which are inferred?
Provider documentation can show that an ordered route, validation option, refresh statement, cross-check, or delivery path is offered. Whether a later result should change a particular field decision is an operational judgment that requires the stated acceptance rule and the field evidence.
What evidence should remain attached when waterfall enrichment enters a workflow?
Keep the field source, its validation state, freshness information, delivery state, and the reason for accepting, holding, correcting, or escalating a result. Those details make a provider sequence auditable rather than merely automated.
When can waterfall enrichment change the next action without stronger evidence?
Only when the new result meets the documented condition for the intended use, or when it materially improves confidence or resolves a conflict. If it cannot change that decision, the next lookup should not be presumed useful.
