E6 ยท Publication Volume 28

Caching and Data Packs

precomputation, freshness, incremental update and invalidation

*precomputation, freshness, incremental update and invalidation*

Source versions, derived caches, dependency edges, freshness and invalidation
Source versions, derived caches, dependency edges, freshness and invalidation

Learning objectives

This lesson is general and institution-neutral. It uses no real company, individual, property, project or identifiable place. Generic roles describe responsibilities only, and SYN-ARCH identifiers denote explicitly synthetic teaching evidence.

  • Frame the decision governed by precomputation, freshness, incremental update and invalidation.
  • Model the relevant boundaries, states and contracts before selecting an implementation.
  • Define measurable invariants, failure evidence and a safe release consequence.
  • Produce a cache dependency and offline data-pack policy with freshness tests from synthetic evidence and defend its trade-offs.

Decision boundary

Cache only a declared derivation for a declared decision context. The design must identify source versions, parameters, code or algorithm version, policy, access scope and acceptable staleness before precomputation is considered safe. A cache is not a second authority; it is a replaceable representation whose lineage leads to retained sources. Distinguish response caching, query-result caching, tiled or level-of-detail artefacts, analytical summaries and offline data packs because they have different keys and invalidation consequences. Prefer explicit dependency and validity rules to an arbitrary time-to-live.

Core concepts

A complete cache key describes every input that can change meaning: dataset snapshot, interpretation branch, spatial and temporal subset, query normalization, parameters, contract version, transformation version, permissions and representation. Freshness is a property relative to a decision, not simply elapsed time. Some approved historical packages remain valid indefinitely; a live review queue may become unsafe within minutes. Incremental update is correct only when the transformation is decomposable and the change set is complete. Invalidation travels along a dependency graph and may require deletion, recomputation, access re-evaluation or a visible stale state.

System model and contracts

Represent each cached artefact with cache identity, dependency identities and digests, derivation activity, parameter set, contract version, creation time, valid interval, freshness policy, access class, completeness and replacement state. An offline pack adds a signed or integrity-protected manifest listing members, extents, references, units, versions, digests and dependency closure. The dependency graph is queryable in both directions: which outputs depend on this source, and which sources justify this output. Aliases such as current point to approved immutable artefacts and change atomically after validation.

Invariants and acceptance criteria

| Invariant | Test evidence | Release consequence | |---|---|---| | Every cached artefact traces to complete versioned dependencies and parameters. | contract test and recorded counterexample | block publication | | Freshness is evaluated against a declared decision policy. | replay comparison and digest check | quarantine the artefact | | Permission changes cannot remain hidden behind ordinary cache lifetime. | role-based acceptance trace | return the decision unresolved | | Incremental results match a full recomputation for the same inputs. | failure injection and recovery record | retain the last verified version | | Every offline pack verifies its declared members before use. | domain review against declared evidence | record an explicit review finding |

Quantitative engineering

Cache hit rate is H=h/(h+m), but report it with decision class, bytes avoided, computation avoided and correctness outcome. Freshness age is A_f=t_{read}-t_{validated} relative to the latest required dependency, while a validity rule determines whether that age is acceptable. Measure invalidation fan-out, recomputation delay, stale-read count, pack completeness, digest failures and storage amplification. A high hit rate can be harmful if keys omit permissions or version. Benchmark cold, warm and partially invalidated states separately and include the cost of proving freshness.

Data quality, evidence and uncertainty

Build the dependency graph from recorded transformations rather than from filename convention. Replay changed-source scenarios and compare a full recomputation with the incremental result. Test permission reduction, corrected reference metadata, late-arriving observations, algorithm change, deleted source and branch merge. For every stale result, preserve whether it was served, blocked or visibly labelled and which policy allowed that outcome. An offline pack must be inspectable without network access and must state what is absent; a successful download does not prove semantic completeness.

Interoperability and versioning

The cache contract defines canonical key construction, dependency capture, freshness calculation, invalidation event, replacement transition and response metadata. A response can expose cache status, source snapshot, validation time and stale warning without leaking protected internals. Data-pack manifests use stable relative member references, media types, byte lengths and content digests. Consumers verify the manifest before opening members and reject undeclared additions when strict reproducibility is required. Pack schema, content version and derivation version remain distinct so a reader can explain compatibility precisely.

Security and professional responsibility

Include effective access scope in cache identity or enforce authorisation after retrieval with evidence that no protected field can leak through shared representation. Permission reduction triggers invalidation or access re-evaluation immediately, not at the ordinary freshness interval. Offline packs are scoped, encrypted where confidentiality requires it, integrity checked and assigned expiry or recall policy. Do not log sensitive keys, extents or pack member names. Cache poisoning controls validate origin, contract, digest and transformation identity before publication, and untrusted input cannot select another role or version through crafted key components.

Operational workflow and observability

Observe dependency-graph lag, key cardinality, hit and miss reason, invalidation queue, recomputation outcome, stale policy decision and pack verification. A failed recomputation retains the last verified artefact only when policy explicitly permits it and labels its age; otherwise the result is unavailable. Invalidation events are idempotent and replayable. Periodic audits select source changes and prove every affected output reached the expected state. Remove caches through governed lifecycle rules, while retained publication packages and provenance remain available for the required evidence period.

Integration checkpoint

Connect the caching and data packs artefact to the preceding volume architecture. Trace one synthetic object from source identity through the new boundary to a reviewed output, then trace one rejection or failure back to the earliest violated invariant. Update the architecture decision record with the chosen option, alternatives, assumptions, evidence, consequences, owner role, review state and triggers for reconsideration. A checkpoint passes only when another reviewer can reconstruct both the successful path and the blocked path without oral explanation.

Synthetic worked example

SYN-ARCH-06 caches map tiles by extent and style but omits interpretation branch and access scope. A reviewer sees a tile from another branch after approval changes, and a restricted outline remains visible after permission reduction. The revised key includes source snapshot, branch, transformation, style, reference and effective scope. A dependency event invalidates affected tiles and one summary, while unrelated regions remain warm. A synthetic offline pack carries a manifest and digests. Full and incremental recomputation produce matching member identities, and a tampered member is rejected before display.

Practice and assessment

  1. Which inputs can change the meaning or visibility of this cache entry?
  2. What decision-specific rule defines acceptable freshness?
  3. How is invalidation propagated and proven complete?
  4. Can the offline pack be interpreted and verified without hidden services?

Assessed artefact: a cache dependency and offline data-pack policy with freshness tests. Submit the artefact with its source manifest, acceptance evidence, unresolved risks and a short explanation of why one plausible alternative was not selected.

Common failure modes

  • Using time-to-live as the only invalidation rule.
  • Omitting source, branch, parameter or permission state from a key.
  • Treating a cached preview as an authoritative source.
  • Applying an incremental update without proving change-set completeness.
  • Calling a downloaded pack complete without checking its manifest.

Sources and further reading