issu321/marketmind-intelegence-ai-system-based

1. Overall shape

- This is a single-process Flask monolith for market intelligence and forecasting, not a distributed system.

- The application is server-rendered: Flask routes in app.py select HTML templates under templates/, and static assets live under static/.

2. Core runtime boundary

- app.py is the main entry point and web server.

- The app listens on port 5000 and is configured for local Docker deployment (sdk: docker, app_port: 5000).

- The repo includes a prebuilt SQLite database at instance/marketmind.db, which suggests the app boots with persisted state rather than external infrastructure.

3. Primary business subsystems

- The functionality is split into domain-focused modules:

- predictor.py for forecasting and model selection

- analyzer.py for data analysis / consumer intelligence

- intelligence.py for competitor intelligence

- utils.py for shared helpers

- These modules are the main computation boundary between web request handling and analytics logic.

4. Data ingestion and dataset lifecycle

- Datasets are a first-class input: users can upload CSVs through the datasets area, and uploaded files are stored in uploads/.

- Example data is bundled in Example-Datasets/, including a dataset guide and a sample sales forecast CSV.

- The dataset workflow likely follows: upload/import → persist file → register metadata in SQLite → analyze/forecast → display results in templates.

5. Persistence layer

- database/models.py contains SQLAlchemy ORM models; the database is SQLite, as described in the README and reinforced by instance/marketmind.db.

- The persistence boundary appears to cover application state such as users, datasets, activity logs, login history, and possibly generated reports.

- This is a local embedded database architecture, not a remote DB service.

6. Authentication and administration

- The app supports registration, login, password management, role-based access, activity logging, and login history.

- Admin views live under templates/admin/, indicating a separate administrative UI surface for user and database oversight.

- This creates a clear separation between end-user analytics flows and privileged operational flows.

7. Analytical capabilities

- Forecasting is the most compute-heavy subsystem and supports multiple ML models, auto-selection, backtesting, and confidence intervals.

- Competitor intelligence computes scoring, SWOT-style insights, and market concentration metrics.

- Consumer intelligence handles sentiment/emotion/topic extraction.

- Opportunity detection and scenario simulation are additional analytical pipelines, each likely invoked from its own Flask route and rendered into a dedicated page.

8. Presentation layer

- The UI is organized by domain in templates such as forecasting/, competitors/, consumer/, opportunities/, simulation/, executive/, reports/, visualizations/, and search/.

- templates/base.html provides the shared layout, while templates/landing.html, templates/dashboard.html, and role-specific pages form the main navigation surfaces.

- This strongly suggests a multi-page application with page-level workflows rather than a single-page front end.

9. Reporting and exports

- Reports are a distinct subsystem with templates under templates/reports/, including a report template and view pages.

- The README indicates export formats such as PDF, HTML, CSV, and JSON, so reporting likely acts as a downstream consumer of analysis outputs.

- Reports bridge analytics results and business presentation, probably reusing data from forecasts, intelligence, and executive summaries.

10. Visualization pipeline

- Visualizations are separated into their own route/template area, with Plotly implied by the README.

- Charts are likely generated from analysis outputs and dataset summaries, then embedded into server-rendered pages.

- This is an important boundary: analytics modules produce results, while the visualization layer turns those results into interactive charts.

11. Search and executive aggregation

- templates/search/ suggests a cross-domain lookup surface over datasets, insights, reports, or entities.

- The executive dashboard consolidates outputs from multiple subsystems into a higher-level KPI view.

- In architecture terms, this is the aggregation layer that sits above forecasting, intelligence, and consumer analysis.

12. Operational artifacts

- uploads/ contains persisted uploaded CSVs, while instance/marketmind.db stores application state.

- Example-Datasets/ is documentation and seed data for users to understand supported inputs.

- These folders are part of the app’s local runtime state and should be shown in any diagram as file-based storage alongside the SQLite database.

13. Technology profile

- The stack is Python 3.11+, Flask, SQLAlchemy, pandas/NumPy/SciPy, scikit-learn plus XGBoost/LightGBM/CatBoost, Plotly, and NLP tooling such as NLTK and TextBlob.

- These libraries matter architecturally because the app is a hybrid of web UI, ML inference/training, statistical analysis, and text analytics inside one backend.

14. Key architectural takeaway

- The cleanest diagram is: browser → Flask routes in app.py → domain modules (predictor, analyzer, intelligence) → SQLite / file storage → rendered templates.

- Everything else is a domain-specific surface on top of that core flow, with admin/auth and reporting as supporting subsystems.