docs(cache): remove static dataset invalidation

docs/ANALYTICS-SPEC.md

@@ -29,7 +29,7 @@ Turn normalized ZarinPal payment facts into trustworthy, merchant-scoped analyti
 - Current-period trends against an approved equivalent baseline
 - Same-category merchant-weighted peer median and performance percentile
 - Lazy, bounded parallel calculation with partial SSE delivery
-- Versioned 30-day Redis cache and PostgreSQL revision invalidation
+- Versioned 30-day Redis cache keyed by the immutable MVP dataset snapshot
 - Traceability from aggregate metrics to permitted merchant-owned evidence
 
 ## Out of scope for MVP
@@ -61,7 +61,7 @@ Every section uses a versioned typed contract and has independent `queued`, `cal
 - Rates are calculated from summed numerator and denominator components for the selected period, never averaged from daily percentages.
 - Timing percentiles exclude null values and expose sample size and non-null coverage; missing time never becomes zero.
 - `NoAttempt` markers create zero-attempt sessions and never count as attempts or retries. `InBank` is an observed attempt stage, not proof of rejection.
-- Every result states the exact Tehran-local half-open period, Jalali label, unit, sample/denominator, source revision, metric-definition version, and calculation timestamp.
+- Every result states the exact Tehran-local half-open period, Jalali label, unit, sample/denominator, dataset snapshot, metric-definition version, and calculation timestamp.
 - Approved period types are one Tehran-local day, one Saturday–Friday week, one Jalali month, or one Persian season. Holiday/event dimensions do not exist in the MVP contract.
 
 ## Peer comparison contract
@@ -75,13 +75,13 @@ Every section uses a versioned typed contract and has independent `queued`, `cal
 
 ## Calculation and cache lifecycle
 
-1. An idempotent authenticated start request resolves merchant, selected period, merchant revision, cohort revision, and metric-definition version.
+1. An idempotent authenticated start request resolves merchant, selected period, immutable dataset snapshot, and metric-definition version.
 2. Equivalent requests map to one current analytics run and do not enqueue duplicate work.
 3. Missing section results are enqueued together and calculated independently by the Go worker through Asynq `v0.26.0`, explicitly a pre-1.0 dependency pinned for compatibility.
 4. Worker limits default to 16 jobs globally and four per merchant. All four core sections begin in bounded parallel and become visible independently.
 5. Each attempt times out after 60 seconds. Transient failures receive at most two retries using exponential backoff of approximately one then two seconds plus jitter; deterministic failures are not retried.
-6. Successful section results are published atomically to Redis under revisioned/versioned keys with a 30-day TTL. PostgreSQL facts and revision rows remain authoritative.
-7. Relevant fact inserts advance the affected merchant and category/cohort revisions in PostgreSQL. New requests use new keys; old keys expire without scans.
+6. Successful section results are published atomically to Redis under keys containing the immutable dataset snapshot, merchant, period, section, and metric-definition version, with a 30-day TTL. PostgreSQL normalized facts remain authoritative.
+7. Payment facts do not change during the hackathon MVP, so no insert/update/delete invalidation trigger exists. Any future dataset replacement requires a separately approved recovery and cache-namespace-selection contract.
 8. Redis loss causes safe lazy recomputation. It never causes loss of payment facts or metric definitions.
 
 ## Partial delivery contract
@@ -131,7 +131,7 @@ Every section uses a versioned typed contract and has independent `queued`, `cal
 - `Paid` plus `Verified` success, verification completion, retry recovery, and timing coverage match catalogue definitions.
 - Saturday–Friday, Jalali-month, and Persian-season boundaries match `calendar_dates` and API half-open ranges.
 - First access starts all missing sections once; ready sections stream independently and equivalent concurrent starts deduplicate.
-- Cache hits avoid repeating source aggregation; merchant/cohort revision changes select fresh keys and recompute only missing sections.
+- Cache hits avoid repeating source aggregation; the immutable completed-import snapshot keeps equivalent requests in one stable namespace.
 - Redis flush causes correct cold-cache rebuilding without source-data loss.
 - Timeouts, transient retry limits/backoff, failed-section isolation, manual retry, rate limits, heartbeat, replay, and snapshot fallback behave as specified.
 - Peer results exclude the active merchant, use equal merchant weighting, obey both suppression thresholds, and never expose individual peers.