kittinhulk/quant-dashboard

Purpose and entry points

This is a small Python forecasting/dashboard repository centered on JPY exchange-rate analysis, apparently using Streamlit. There is no README documentation, package structure, or explicit service layer; the application behavior is defined directly in several top-level scripts.

Primary candidate entry points:

• app.py

• app_streamlit_jpyx_forecast_dashboard.py

• app_streamlit_gc_f_with_comparison.py

These likely represent alternative dashboard versions rather than one composed application.

Dashboard variants

The repository keeps multiple independently runnable Streamlit implementations:

• app_safe_streamlit_gc_f.py

• app_streamlit_gc_f_with_pretty_plot.py

• app_streamlit_gc_f_with_comparison.py

The gc_f naming suggests a gold-futures-oriented variant, while app_streamlit_jpyx_forecast_dashboard.py targets a JPY index/currency forecast dashboard. Shared functionality, if any, is duplicated at script level rather than extracted into modules.

Forecasting and visualization stage

Each application script likely owns the complete request-to-result workflow: obtain time-series data, build or run a forecast, and render interactive results. The “pretty plot” and “comparison” variants indicate visualization and forecast/model comparison are first-class features:

• app_streamlit_gc_f_with_pretty_plot.py

• app_streamlit_gc_f_with_comparison.py

• app_streamlit_jpyx_forecast_dashboard.py

There is no visible internal domain-model or pipeline package boundary.

Runtime and dependencies

The runtime is Python, with dependencies declared in:

• requirements.txt

Streamlit is strongly implied by the application filenames. Forecasting, market-data retrieval, plotting, and numerical libraries may be present in requirements, but cannot be confirmed from the supplied tree. The apps should be launched as standalone Streamlit scripts rather than imported as a conventional Python package.

Control and data boundaries

The primary control boundary is the Streamlit process: user interaction triggers script execution and dashboard rendering. Any external market-data source, forecasting engine, or model API is accessed directly from the top-level app scripts, if present:

• app.py

• app_streamlit_jpyx_forecast_dashboard.py

• app_safe_streamlit_gc_f.py

No persistent database, backend API, container/deployment configuration, or infrastructure-as-code is represented in the repository tree.

Validation and maintenance

A standalone test/prototype file exists:

• test.py

Because the repository contains parallel application scripts and no shared source directory, changes to data acquisition, forecast logic, or UI conventions may need to be propagated across variants manually. The most important architectural decision for future work is whether to retain these as separate experiments or consolidate common market-data, forecasting, and rendering stages into reusable modules.