Features explained

Ask what your documents said at a point in time

The Knowledge API can answer from the corpus as it stands now, from a corpus pinned at the start of your run, or from the corpus exactly as it was when an earlier answer was given. You name which one, and every response says what it actually guaranteed.

A knowledge base is not a fixed thing. Documents arrive, get replaced, get deleted. If your integration asks a question while any of that is happening, the answer can be built from a mixture: one passage from before the update, one from after, and no way to tell afterwards which it was.

Consistency modes let you say which corpus you want to be answered from.

The four modes

Latest available. The default, and what every call did before this existed. Best effort against whatever is in the corpus right now. Fast, and honest about being best effort.

Consistent snapshot. Pins to the corpus at the moment your request starts. A run that takes several steps cannot see a document that arrived halfway through it. Use this when a single answer draws on several passages and you need them to describe one moment rather than a moving target.

As recorded at. Answers from the corpus as it stood at a point you name. This is what makes an answer you were given last month reproducible today: pass the sequence number that answer recorded, and you get the same evidence back, including documents that have since been deleted and excluding documents that have since arrived.

Strict freshness. For the caller who would rather wait than be told something stale. If material is still being ingested or the index is still catching up, you get told that instead of an answer. Nothing is generated and nothing is charged.

Every response says what it actually guaranteed

This is the part worth reading carefully, because it is where most systems quietly overclaim.

The evidence store is event sourced, so a snapshot mode really does pin it to a point. The text index is a separate system, and results from it are checked against that point rather than held still by it. Those are different strengths and the response reports them separately, per source, rather than putting one word on the whole answer.

If a response says a source was snapshot guaranteed, it was. If it says a source was checked against the watermark, that is a weaker claim and it is stated as one. You should never have to infer which you got from the name of the mode you asked for.

What is deliberately missing

There is no mode for filtering by when a rule was in force in the real world, as opposed to when the document arrived. That would need validity dates extracted from the documents themselves, and GPTree does not yet write them. Asking for that mode returns a clear refusal explaining exactly that.

The alternative would have been to accept the parameter and filter on fields that are always empty, which returns either everything or nothing while looking like a working feature. A refusal you can read is better than a result you cannot trust.

When it matters

  • Audits and reviews. Someone asks why an answer said what it said. You can reproduce it against the corpus that produced it, rather than against today's.
  • Multi step runs. A long job that reads, reasons and reads again stays on one corpus for its whole length.
  • Pipelines that run alongside ingestion. A nightly sync and a scheduled question no longer race each other silently.

Getting started

Add a consistency field to an /ask request. Leave it out and nothing changes: you get latest available, exactly as before. /search and /context do not take a consistency mode yet. For a replay, pass as_recorded_at along with the sequence number recorded on the answer you are reconstructing.

Available wherever the Knowledge API is. It costs nothing extra to ask, and the refusal modes cost nothing at all.

Related reading