projection        = derived state computed from source state/events
materialized view = persisted projection optimized for reads

what should we precompute so reads do not redo expensive work?

derived, keyed, rebuildable copies of truth

index/search projection   → index_structures.md (whole)
cache projection          → cache.md (whole, incl. key completeness)
streaming projection      → checkpoint_replay.md's composite
                            (state + offsets bound by coordinate)
                            + log.md's applied rung
batch publish discipline  → garbage_collection.md's publication protocol
aggregate/rollup          → GC Part II query-sufficient rung + index_structures.md
denormalized read model   → cache.md's write-path axis, at schema level

read speed and query simplicity  vs  freshness, correctness, maintenance cost

on-read / lazy:    populated by misses; DEMAND decides what exists
                   (cache: pay per miss, coverage emergent)
on-write / eager:  maintained by changes; COVERAGE decided upfront
                   (MV, index: pay per write — capacity.md's
                    write amplification, by subscription)
hybrid:            read-through fill + background refresh

Who pays — the reader on miss, or every writer forever?
Is the coverage set known upfront (eager viable) or emergent (lazy)?
What is the hit pattern that amortizes eager maintenance? (index_structures.md axis 5)

the answer itself:      cache, MV — serve directly
a pointer to candidates: index — verification step mandatory,
                         silent omission* lives there (index_structures.md)

event time:       when it happened        (the domain's truth)
processing time:  when the projection saw it
the gap between them is unbounded and arrives OUT OF ORDER

watermark:          "I declare hour 14 closed" — a completeness BET made
                    explicit. arrivals after it are LATE by definition.
allowed lateness:   a grace window; late-but-tolerated events retract
                    and reissue the affected result
late-data policy:   drop / side-output / retract-and-reissue — chosen,
                    not discovered in an incident
bitemporal record:  store event time AND processing time, so
                    "what did we know when" is answerable
idempotent upsert:  a late correction is an overwrite, not a double-count

point-in-time leakage  = a training join that saw the future
                         (bitemporal join done wrong)
training/serving skew  = the same feature computed under two different
                         event-time disciplines

non-associative aggregation: reordered application changes the answer —
                             the function itself must be commutative-
                             associative, or inputs must be sequenced first
double-count:                the same event applied twice because the
                             progress coordinate and the state diverged
                             (binding coordinate*, checkpoint_replay.md)

Event time or processing time — and does every window say which?
Where is the watermark, who advances it, and on what evidence?
The late-data policy: drop, side-output, or retract? Written down?
Can the aggregate absorb out-of-order application, or must input be sequenced?
For features: is the offline join point-in-time correct, and is the
  online path computing the SAME function?

1. build new generation ALONGSIDE the old (never in place)
2. backfill from a source snapshot          (checkpoint_replay.md rebuild path)
3. catch up on the live stream from the
   snapshot's coordinate                    (the snapshot→stream seam:
                                             the GAP/OVERLAP DIAL, 4th appearance —
                                             gap = writes during rebuild missed;
                                             overlap = old and new views mix /
                                             events double-applied; you choose,
                                             and idempotent upserts pay for overlap)
4. validate the new generation against source (drift check before, not after)
5. cut over ATOMICALLY                      (GC's publication protocol:
                                             generation pointer flips once;
                                             readers see old or new, never a blend)
6. retire the old after readers drain       (GC's pin registry: visibility
                                             proof before physical deletion)

Which step is skipped in the current design? (usually 4 or 6)
Cutover: is there a single generation pointer, or can queries straddle?
Catch-up seam: gap or overlap — and what makes overlap safe? (idempotency)
Can the source still produce the backfill? (the retention treaty:
  a projection is only as rebuildable as the history that survives)

a projection over event time can never know it has seen everything.

"late events" is not a failure mode; it is the terrain.
the failure mode is a watermark policy chosen implicitly.

watermarks + declared lateness bounds
retraction/reissue for tolerated latecomers
bitemporal storage ("what did we know when")
idempotent upserts (corrections overwrite, never accumulate)
completeness metrics (watermark lag observed, not assumed)

what source truth is projected, under which time semantics,
where the watermark is and what advancing it costs,
the late-data policy by name,
how progress and state stay bound (the coordinate),
and the six cutover steps for the day the projection is wrong.

projection  materialized view  read model  derived state
event time  processing time  watermark  allowed lateness
late event  retraction  reissue  bitemporal  point-in-time
grain  rollup  window  non-associative
backfill  catch-up  cutover  generation  drain
training/serving skew  leakage  feature freshness
(coordinate, rebuild, publication, freshness, key → owning files)

derived state      vs  source of truth     (cache.md / log.md: the family's premise)
freshness          vs  correctness         (cache.md axis 1)
cache              vs  materialized view   (family axis A: who pays, miss or write)
index hit          vs  authoritative existence (index_structures.md: candidate ≠ truth)
event delivery     vs  projection update   (log.md rung 4 vs applied state)
checkpoint         vs  completed side effect (commit point*, queue.md)
rebuild            vs  atomic cutover      (native: steps 1–3 are not step 5)
processing time    vs  event time          (native: the star's terrain)