featuresJune 5, 2026· 3 min read

CSOURCE: answer lineage and cascade-purge when the source changes

Cached answers derive from sources — a doc, a config, an API. CSOURCE ties answers to their origin so that when the source changes, every answer built on it can be purged in one move.

Cached answers don't appear from nowhere; they're derived from a source — a knowledge-base article, a pricing config, an upstream API response. When that source changes, every answer built on it is silently stale, and a cache with no concept of lineage has no way to find them. CSOURCE adds that concept.

In plain words: Crowkis remembers which source each cached answer came from. Change the source — a doc, a config — and one command purges every answer built on it, instead of hoping a timer expires them.

CSOURCE LINK ties a cache entry to a source id; CSOURCE LIST shows what derives from a given source; CSOURCE PURGE invalidates everything linked to a source in one cascade. So when the pricing doc revs or the upstream API changes its answer, you don't hunt for affected entries — you purge by source and the derived answers go with it.

the write-trust pipeline

Five stages score every write before it can ever be served.

This is the difference between freshness you hope for and freshness you can prove. Time-based TTLs guess at how long an answer stays true; source lineage knows the exact moment it stopped, because it's wired to the thing that changed. The two compose — TTLs for the unknowable, lineage for the knowable.

The bottom line

An answer that can't name its source can't be invalidated when the source moves. CSOURCE makes the cache's contents accountable to where they came from — which is what 'trustworthy cache' actually means when the underlying truth is a moving target.