Type: Decision Status: Active Systems: Cache Author: Phil / Claude Date: 2026-06-01 Related: LLP 0012, LLP 0014, LLP 0015 Extended-by: LLP 0321, LLP 0336 (#retention-is-the-central-tradeoff: where and how often the window is enforced)
The always-on intrinsic store. Decomposed from
hypaware-design.md(Local Query Cache).
The cache is the always-on intrinsic store for captured data. It is not a
plugin and not configurable as a destination. Its location is
HypAware-managed (under ~/.hyp/hypaware/ by default; an admin can relocate the
root, but the layout inside is fixed) and its on-disk format is an
implementation detail. If you want data in a layout, location, or format you
control, you configure a sink (LLP 0014): the cache
is how you don't.
Every row a source produces is written into the cache; sources never see sinks
(LLP 0012). hypaware query runs against the cache
(LLP 0015).
Retention is configurable per dataset. Rows older than the window are deleted permanently, if the data wasn't exported to a sink before then, it's gone. The cache is recent-data-only by design, and this is the tradeoff to surface to users.
{ "query": { "cache": { "retention": { "default_days": 90, "datasets": { "logs": 7 } } } } }Default retention is 90 days. A deployment with no export sink relies entirely on this window. A deployment that pairs the cache with a queryable sink (local-fs+parquet, or S3+iceberg) gets recent queries served locally and historical queries reaching into the sink, transparently (LLP 0014).
Cache eviction vs. export coupling: should the cache wait to evict a
partition until all configured sinks have acked their export, or evict purely on
retention? Retention-only is simpler; ack-coupled protects against data loss
when a sink is slow. Unresolved; see LLP 0000.
A reserved wait_for_sink_ack retention knob was once parsed (but never wired);
it has been removed from the config surface until this question is decided, so
the option will reappear only alongside a real implementation.