starcoach-hackathon/zarinpal-analytics-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: define source timestamp normalization

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-20 13:15:11 +03:30
parent 491c673153
commit 2753162a75
3 changed files with 32 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/DATA-FOUNDATION-SPEC.md
View File

@@ -113,7 +113,7 @@ erDiagram
}
```
This ERD is a logical baseline, not an approved physical schema. In particular, source key types, timestamp timezone interpretation, card-key retention, analytics projections/materialized views, and whether session-level fields can conflict across retries must be resolved from a profiling report before migrations are approved.
This ERD is a logical baseline, not an approved physical schema. In particular, source key types, card-key retention, analytics projections/materialized views, and whether session-level fields can conflict across retries must be resolved from a profiling report before migrations are approved.
## Import contract
@@ -152,9 +152,10 @@ Resolved: use manual constructor injection with explicit wiring at thin `cmd/` c
Resolved: use Ent for application persistence/modeling and pgx/PostgreSQL `COPY` for streamed bulk-ingestion staging. Migrations are explicit and versioned; production startup never performs automatic schema changes. See ADR 0003.
Resolved: interpret timezone-naive source timestamps as `Asia/Tehran`, normalize canonical timestamps to UTC, expose ISO-8601 timestamps through APIs, and retain the immutable source/import provenance needed to reproduce the conversion. See ADR 0004.
Remaining approval gates:
1. Source timestamp timezone and daylight-saving assumptions.
2. Whether `payer_card_key` must be retained, irreversibly transformed, or omitted after derived analytics.
3. Minimum cohort size and suppression policy for peer benchmarks.
4. Physical partitioning/materialization strategy, which must follow measured query needs rather than the logical ERD alone.
1. Whether `payer_card_key` must be retained, irreversibly transformed, or omitted after derived analytics.
2. Minimum cohort size and suppression policy for peer benchmarks.
3. Physical partitioning/materialization strategy, which must follow measured query needs rather than the logical ERD alone.