What should we ask a vendor about this?

How often each source is revisited, whether that is adjustable, and how quickly a deletion or a permission change takes effect. Those three answers predict most of the trouble you will have, and none of them appears in a demonstration, where everything was loaded that morning and nothing has changed since.

Why does connecting one particular system cost so much more?

Because it cannot say what changed. A source that reports its own updates is cheap to keep current; one that must be re-read in full, or reached through an interface never intended for the purpose, costs on every refresh forever. That difference bears no relation to how important the source is to you.

How stale is too stale?

It depends entirely on what the material governs. A policy corpus tolerates a slow schedule comfortably; anything used to answer customers, or anything where access changes matter, does not. The useful move is to set the interval per source against what it is used for, rather than accepting one figure across everything.

Glossary

Data ingestion

Data ingestion is the work of getting your material into a system and keeping it current, which is bought as a setup task and behaves as a standing obligation because the sources never stop changing.

In plain terms

Getting your documents in, and keeping them in step as they change. Loading them the first time is a project with an end. Keeping up as people edit, move, rename and delete things is not, and that second half is where the effort actually lives even though only the first half appears in anybody's plan.

Why it matters

Because the estimate covers the loading and the work is the keeping up. A first load finishes and feels like completion, after which the corpus immediately begins drifting away from reality as people edit and reorganise, and nothing about that drift announces itself until somebody acts on an answer built from a document that changed months ago.

How it works

Each source needs its own way in, and they are not equally cooperative. Some systems offer a proper route that reports what changed since last time, some only allow everything to be re-read from scratch, and some have to be reached through an interface never designed for it, so the practical cost of a source varies enormously and rarely matches how important it is.

Refresh is a schedule that somebody set, usually a default. How often each source is revisited decides how stale an answer can be, and because the setting is invisible and the consequence is delayed, the interval survives unexamined until a complaint traces back to it. That is the single most useful thing to check when a system starts feeling unreliable.

Permissions travel with the material and must be kept in step. What each person may see is recorded when material is taken in, so a change of access in the source system is not respected until the next refresh reaches that document, which makes the refresh interval a correctness question rather than a convenience one.

Removals are the part that is under-built almost everywhere. Adding is the obvious path and taking things away is easy to defer, so a system that faithfully ingests everything and forgets to un-ingest will keep serving material that has been deleted, superseded or moved somewhere its former readers can no longer reach.

What was estimated, and what was signed up for

The pattern this produces is consistent enough to predict. A deployment goes well: the material is loaded, the answers are good, people are impressed, and the project is closed. Nobody is assigned to the second column because it does not look like work, and for a while it genuinely is not, since the corpus has only just been built from the current state of everything. Drift accumulates quietly. A team reorganises a drive, a policy is superseded, somebody's access is tightened after they change role, a folder is archived. Each of those is invisible to the search tool until a refresh reaches it, and if the schedule was never examined it may be reaching some sources rarely and others not at all. Nine months later the complaint is that the search has got worse, which is not quite right: the search is doing exactly what it did on day one, to a copy of an organisation that no longer exists.

Seen in the wild

Enterprise search that indexes an organisation's applications, where each connected system arrives with its own refresh behaviour and its own access rules.
Glean
A curated knowledge layer that detects conflicting content, merges duplicates and flags stale material as the sources behind it change.
Guru
A private document tool where taking material in and storing it locally is handled for you, on hardware you operate.
AnythingLLM

Common misconceptions

People assume

It is a setup task.

In fact

The first load is a task and everything after it is an obligation that runs for as long as the system does. Documents change, move and disappear continuously, so the effort shifts from loading to reconciling, and the estimate almost never includes the second part because the first one visibly finishes.

People assume

All our sources are roughly equivalent to connect.

In fact

They differ by an order of magnitude and not in proportion to their importance. A system that reports what changed since last time is cheap to keep current; one that must be re-read entirely, or reached through an interface never meant for it, is expensive, and that cost is discovered after the source has been promised.

Telling them apart

Data ingestion vs Search index

Data ingestion

The process that fills and refreshes the copy.

Search index

The copy itself, which is what search reads.

A stale or missing answer is nearly always this rather than the other, which is why complaints about search so often resolve to a refresh interval.

Questions

What should we ask a vendor about this?: How often each source is revisited, whether that is adjustable, and how quickly a deletion or a permission change takes effect. Those three answers predict most of the trouble you will have, and none of them appears in a demonstration, where everything was loaded that morning and nothing has changed since.
Why does connecting one particular system cost so much more?: Because it cannot say what changed. A source that reports its own updates is cheap to keep current; one that must be re-read in full, or reached through an interface never intended for the purpose, costs on every refresh forever. That difference bears no relation to how important the source is to you.
How stale is too stale?: It depends entirely on what the material governs. A policy corpus tolerates a slow schedule comfortably; anything used to answer customers, or anything where access changes matter, does not. The useful move is to set the interval per source against what it is used for, rather than accepting one figure across everything.

Key takeaways

The first load finishes; keeping up does not, and only one is estimated.
Sources differ enormously in cost, unrelated to their importance.
The refresh interval is a correctness question because permissions travel with it.
Removals are under-built nearly everywhere, so deleted material keeps answering.