One-way data flow

The rule

Data flows in one direction. Your systems - the ERP, the CRM, the accounting package, your own applications - are the sources. Records are copied from them into the index, on a schedule, by push or by pull. Readers take from the index: application screens through an API, dashboards and grids, a conversational assistant, AI clients through an MCP server. At no point does anything flow from the index, or from any reader, back into a source. It is a simple rule, and most of what makes an indexed layer safe to adopt follows from it.

In, on a schedule

Each collection is refreshed on its own clock, from a full import at the start to incremental imports of new and changed records after that. The schedule is chosen by how fresh each screen must be - orders hourly, products daily - and the index says on the screen how fresh it is. The source does not participate beyond being read: no triggers installed, no tables added, no change to how it is written to. Incremental indexing covers the mechanics of the inbound half.

Push or pull, still one way

There are two ways for records to arrive and both keep the rule. With push, your system sends records to the index through its API whenever they change: an order is placed, the application writes it to the database and posts it to the index. With pull, the index reads the source on a schedule and imports what is new or changed since the last run. Push is fresher and asks for a small change to the application; pull asks for nothing from the application and runs on its own clock. In both cases the direction is the same - from source to index - and in both cases the source is only ever read or sent from, never written to by anything downstream. Which to use is a question of freshness, not of safety.

Out, to readers

Every reader is a read. A catalog search asks for the products matching jaket; a dashboard asks for orders faceted by region; the assistant asks the same on a user's behalf; an MCP client calls a facet tool. The index answers from the copy and nothing it does reaches the source. A reader cannot adjust stock, cancel an order or edit a customer through the index, because the index has no path to the systems that hold those things.

Three consequences

A small blast radius. If the index is misconfigured, over-filled, or simply wrong, the damage is a bad copy. Rebuild it from the source with a full import and it is right again. No source was touched, so no source needs repairing.

An easy audit. A reviewer has one direction to trace: what was copied in, on what schedule, and who read what out. There is no inbound path to the systems of record to analyse, because there is none.

An easy rollback. Removing the index means pointing the screens that used it back at the database and switching it off. The sources never knew it existed, which is exactly the property that made it safe to add in the first place.

What the rule does not cover

One-way flow is about your systems of record. It says nothing about what leaves the environment to an AI provider or an AI client, which is a different flow with its own rules and its own page. A product can be perfectly one-way with respect to your database and still send a question to a language model; the two statements are both true and should be made separately. Data flow map keeps them separate.

Why vendors should say it plainly

"Never writes back" is a checkable claim: there is either a path to the source or there is not, and a diagram shows which. It is also the claim that lets an index be adopted screen by screen - the slow listing first, the checkout never - because nothing about the sources changes between the first screen and the last. A vendor who cannot say it plainly is probably describing a product that does something else, such as synchronizing records in both directions, which is a different and far riskier thing. When not to use an index server is the list of screens to leave on the source for exactly that reason.

Related

EXPLAINER Incremental indexing: keeping an index fresh An index is a copy, so it has to be refreshed. The question is how, how often, and what to tell users. EXPLAINER Data flow map: what leaves your environment, per product One boundary, four flows. What goes in, what stays, what goes out, to whom, and who controls it - for each product separately, because the honest answer differs. EXPLAINER When not to use an index server An index server is a copy built for reading. Some screens need the original. Knowing which is most of the design.