You are a senior distributed-systems / data-pipeline architect. Produce an exhaustive, evidence-backed markdown analysis. Be concrete, give real patterns and tradeoffs, avoid filler.

PROJECT CONTEXT
We are deciding how a large-scale memory system (millions of documents) should defer or lazily perform expensive extraction. Pipeline: files (E0) -> chunks (E1) -> claims (E2, LLM) -> relations (E3, LLM + entity resolution). Postgres is the single source of truth and the system must be "rebuildable from Postgres" (D7). Processing is per-document via Cloud Tasks workers, each layer triggering the next (D12). Objection O3 proposes a value gate with tiers full/DEFERRED/chunks-only, and "lazy extraction" — e.g. extract a document's claims only when its chunks are first RETRIEVED, or when a special-purpose scope (K2) declares interest in its entities. Read first:
- /Users/jpuc/code/moje/ultimate_memory/ugm/plan/analysis/objections.md (O3)
- /Users/jpuc/code/moje/ultimate_memory/ugm/plan/designs/overall_design.md (planes, trigger model)
- /Users/jpuc/code/moje/ultimate_memory/ugm/decisions.md (D7 rebuildable, D12 triggers, D1 source of truth)

YOUR QUESTION (V3): What is the right architecture for LAZY / DEFERRED / on-demand extraction, and what does it cost us?

COVER:
1. Patterns for deferred/lazy heavy processing in data pipelines: eager vs lazy materialization, on-read computation + caching, work queues with priority, backfill-on-demand, tiered/staged processing. Which fit a per-document LLM-extraction pipeline?
2. "Extract on first retrieval": when a chunk is retrieved but its claims/relations were not yet extracted, extract synchronously then cache. Latency/UX implications; cold-start; how to avoid double-work; how to mark deferred state in Postgres. Who has done this (RAG-on-demand, lazy GraphRAG, etc.)?
3. "Extract on scope interest": a K2 scope (e.g. people-profiling) declares interest in certain entity types/sources, triggering extraction for matching deferred docs. How to model interest and fan-out.
4. CONSISTENCY: does lazy/deferred extraction break "rebuildable from Postgres" (D7)? Is a gate/defer DECISION itself versioned state that must be stored and replayable? How to keep deferred work tracked, idempotent, and not silently lost. How does it interact with the per-document trigger chain (D12)?
5. RECALL/UX risk: deferred facts are invisible to cross-document aggregation (L3/K, graph) until extracted — so a deferred document contributes nothing to global knowledge until something pulls it. Is that acceptable? Mitigations (priority queues, periodic drain, salience override).
6. Concrete recommendation for OUR design: which lazy/deferred patterns to adopt, where deferred state lives in Postgres, how it interacts with D7/D12, the trigger for promoting deferred->extracted, and the failure/lost-work safeguards.

Write the full analysis to stdout as markdown. 1500-3000 words. Lead with "Key findings", then detail, then "Recommendations for the ugm design".