docs: promote AI growth analyst capability
This commit is contained in:
@@ -18,7 +18,7 @@ The hackathon demo will seed one account per merchant. Where merchant profile fi
|
|||||||
| 3 | Analytics engine | Deterministic metrics, cohorts, trends, diagnostic drill-downs, bounded parallel on-demand section jobs, and a 30-day Redis cache namespaced by the sole completed immutable dataset snapshot | Data foundation | Yes |
|
| 3 | Analytics engine | Deterministic metrics, cohorts, trends, diagnostic drill-downs, bounded parallel on-demand section jobs, and a 30-day Redis cache namespaced by the sole completed immutable dataset snapshot | Data foundation | Yes |
|
||||||
| 4 | Merchant API | Stable authenticated interfaces and tenant-scoped SSE for partial analytics delivery | Identity and access, analytics engine | Yes |
|
| 4 | Merchant API | Stable authenticated interfaces and tenant-scoped SSE for partial analytics delivery | Identity and access, analytics engine | Yes |
|
||||||
| 5 | Merchant dashboard | Persian RTL dashboard, responsive navigation, accessible charts/tables and explanations | Merchant API | Yes |
|
| 5 | Merchant dashboard | Persian RTL dashboard, responsive navigation, accessible charts/tables and explanations | Merchant API | Yes |
|
||||||
| 6 | AI assistance | AvalAI-backed explanation/recommendation workflow over sanitized aggregates | Analytics engine, merchant API | No |
|
| 6 | AI growth analyst | Deterministic 90-day event-aware forecasts, persisted report snapshots, cost controls, and bounded AvalAI interpretation over sanitized evidence | Analytics engine, merchant API | Yes |
|
||||||
| 7 | Platform operations | Compose, Nginx, manual deployment, phased observability, backup/restore, release and rollback | All deployables | Yes |
|
| 7 | Platform operations | Compose, Nginx, manual deployment, phased observability, backup/restore, release and rollback | All deployables | Yes |
|
||||||
|
|
||||||
Build sequence: data foundation → identity and analytics → API → dashboard → platform operations → AI assistance.
|
Build sequence: data foundation → identity and analytics → API → dashboard → platform operations → AI assistance.
|
||||||
@@ -45,7 +45,7 @@ Build sequence: data foundation → identity and analytics → API → dashboard
|
|||||||
3. Every displayed metric has a definition, source fields, filters, time window, and drill-down path.
|
3. Every displayed metric has a definition, source fields, filters, time window, and drill-down path.
|
||||||
4. Dataset imports are repeatable and produce a versioned manifest with checksum, counts, timestamps, and validation results.
|
4. Dataset imports are repeatable and produce a versioned manifest with checksum, counts, timestamps, and validation results.
|
||||||
5. Secrets stay outside Git; examples contain names and safe placeholders only.
|
5. Secrets stay outside Git; examples contain names and safe placeholders only.
|
||||||
6. AI is post-MVP, receives only minimized/sanitized aggregates, and cannot become the source of record.
|
6. AI growth analysis is feature-flagged, receives only minimized/sanitized aggregates, and cannot become the source of record. Deterministic forecasts and cached reports remain usable when AvalAI is disabled, unavailable, or over budget.
|
||||||
7. External calls have timeouts and bounded retries; jobs are idempotent and observable.
|
7. External calls have timeouts and bounded retries; jobs are idempotent and observable.
|
||||||
8. Production changes are reversible and backed by documented health checks and rollback steps.
|
8. Production changes are reversible and backed by documented health checks and rollback steps.
|
||||||
9. `Paid` and `Verified` are both successful bank payments; `Paid` still requires merchant verification and `Verified` is finalized. Paid-volume and recovery metrics include both while verification metrics keep them separate.
|
9. `Paid` and `Verified` are both successful bank payments; `Paid` still requires merchant verification and `Verified` is finalized. Paid-volume and recovery metrics include both while verification metrics keep them separate.
|
||||||
@@ -60,6 +60,8 @@ Build sequence: data foundation → identity and analytics → API → dashboard
|
|||||||
18. Authentication uses revocable server-side sessions and an opaque host-only `Secure`, `HttpOnly`, `SameSite=Lax` cookie. Passwords use Argon2id; sessions expire after 12 idle hours or seven absolute days and are revoked on logout/account disablement. Demo credentials are generated once and never stored in Git.
|
18. Authentication uses revocable server-side sessions and an opaque host-only `Secure`, `HttpOnly`, `SameSite=Lax` cookie. Passwords use Argon2id; sessions expire after 12 idle hours or seven absolute days and are revoked on logout/account disablement. Demo credentials are generated once and never stored in Git.
|
||||||
19. Demo authentication stays replaceable and minimal because ZarinPal SSO will own production identity after acceptance. Failed logins are limited by username and IP without permanent lockout; mutations require CSRF and same-origin checks; each user has at most two active sessions.
|
19. Demo authentication stays replaceable and minimal because ZarinPal SSO will own production identity after acceptance. Failed logins are limited by username and IP without permanent lockout; mutations require CSRF and same-origin checks; each user has at most two active sessions.
|
||||||
20. Demo sessions live in PostgreSQL and store only SHA-256 digests of 32-byte random tokens. Activity writes are coalesced to five-minute windows; Redis remains disposable and is not the session source of truth.
|
20. Demo sessions live in PostgreSQL and store only SHA-256 digests of 32-byte random tokens. Activity writes are coalesced to five-minute windows; Redis remains disposable and is not the session source of truth.
|
||||||
|
21. AI growth reports are keyed by authenticated merchant/optional terminal plus data, catalog, analytics, prompt/schema, and model versions. PostgreSQL is authoritative; Redis may coordinate locks, limits, budgets, and hot reads only.
|
||||||
|
22. Merchant page visits reuse the current matching report. At most one explicit merchant-wide refresh is allowed per Tehran calendar day, and budget exhaustion degrades to deterministic partial output instead of hiding analytics.
|
||||||
|
|
||||||
## Required capability specs
|
## Required capability specs
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user