Updated docs, improved UI, fixed minor bugs.

Updated the documentation to provide information on scripts and snapshot
bindings registry. Updated setup and usage instructions. Altered a few
other parts of the docs for clarity.

Improved the GUI by adding descriptions to each page, highlighting
optional vs required fields, and adding some styling to make it more
visually appealing.

Updated the Dockerfile and requirements.txt to not include sdv and a
specific torch version required by generate_fake_data.py when training
the CTGAN model on RTX 5070 Ti GPU, but still included the two packages
as commented out lines, along with some comments for clarity.

Fixed minor bugs in the code related to the above changes.

Note: the gifs have not been updated yet, as more changes are expected
soon, but they will be updated in the near future to reflect the new UI.

Author: Sebastijan-Dominis

Dockerfile

@@ -1,6 +1,7 @@
 # ===== Base image with GPU support =====
-# FROM pytorch/pytorch:2.10.0-cuda12.8-cudnn9-runtime
-FROM nvidia/cuda:12.8.0-runtime-ubuntu22.04
+FROM pytorch/pytorch:2.10.0-cuda12.8-cudnn9-runtime
+# NOTE: Uncomment the line below and comment out the line above only if you want to generate fake data. For regular use, stick to the current image. If you use the image below, make sure to also uncomment the torch installation line in this Dockerfile. Likewise, uncomment the sdv dependency in requirements.txt.
+# FROM nvidia/cuda:12.8.0-runtime-ubuntu22.04
 
 # ===== Set working directory =====
 WORKDIR /app
@@ -23,28 +24,29 @@ ENV PATH="/opt/conda/bin:$PATH"
 RUN conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/main && \
     conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/r
 
-# ===== Copy dependency files first for faster rebuilds =====
+# ===== Copy environment.yml first for faster rebuilds =====
 COPY environment.yml /tmp/environment.yml
-COPY requirements.txt /tmp/requirements.txt
-COPY setup.py .
-COPY pyproject.toml .
 
 # ===== Create Conda environment =====
 # Create env
 RUN conda env create -f /tmp/environment.yml -n hotel_management
 
+# Copy the rest of the files needed for installation
+COPY requirements.txt /tmp/requirements.txt
+COPY setup.py .
+COPY pyproject.toml .
+
 # Install torch (nightly CUDA 12.8)
 # This version works with Nvidia RTX 5070 Ti GPU. If you experience issues, change to a compatible version for your GPU.
-RUN conda run -n hotel_management pip install --pre \
-    torch==2.12.0.dev20260320+cu128 \
-    --index-url https://download.pytorch.org/whl/nightly/cu128
+
+# NOTE: Uncomment this only if you want to generate fake data. In that case, use the commented out base image at the top of this file. Likewise, uncomment the sdv dependency in requirements.txt. For regular use, stick to the current image.
+# RUN conda run -n hotel_management pip install --pre \
+#     torch==2.12.0.dev20260320+cu128 \
+#     --index-url https://download.pytorch.org/whl/nightly/cu128
 
 # Install rest
 RUN conda run -n hotel_management pip install -r /tmp/requirements.txt
 
-# Install your package
-RUN conda run -n hotel_management pip install -e .
-
 # ===== Use the environment for all container commands =====
 SHELL ["conda", "run", "-n", "hotel_management", "/bin/bash", "-c"]
 
@@ -54,6 +56,9 @@ COPY pipelines ./pipelines
 COPY scripts ./scripts
 COPY ml_service ./ml_service
 
+# Install the package
+RUN conda run -n hotel_management pip install -e .
+
 # ===== Expose ports =====
 EXPOSE 8000
 EXPOSE 8050

README.md

@@ -38,7 +38,7 @@ Two options:
   - operate the workflow through a `browser`
 - **Manual use**
   - requires `python` and `conda` (preferably)
-  - operate the workflow through a `browser` or `cli + manual` (configs)
+  - operate the workflow through a `browser` or `cli + manual (configs)`
 
 ## Usage
 

docs/configs/bindings.md

@@ -0,0 +1,171 @@
+# Snapshot Bindings Registry
+
+Snapshot bindings registry defines which snapshot of each specified dataset
+and feature set will be used by a script that uses these configs.
+
+It allows the use of specific snapshots, hence enabling reproducibility.
+
+Unlike some of the other configuration types, snapshot bindings are **centralized in a single configuration file** and selected dynamically at runtime of a given pipeline (likely `freeze.py`,
+`search.py`, or `train.py`).
+
+## 1. Location
+
+Snapshot bindings are defined in a single file:
+
+```text
+configs/snapshot_bindings_registry/bindings.yaml
+```
+
+This file contains all of the defined **snapshots of snapshot bindings**.
+
+## 2. Configuration Structure
+
+The configuration is organized hierarchically
+
+General structure:
+
+```text
+snapshot_id
+  └─ snapshot_bindings
+```
+
+Example:
+
+```yaml
+2026-03-20T02-54-47_61509023:
+  datasets:
+    hotel_bookings:
+      v1:
+        snapshot: 2026-03-17T03-26-25_4e817323
+      v2:
+        snapshot: 2026-03-17T03-26-27_c04ca84b
+  feature_sets:
+    booking_context_features:
+      v1:
+        snapshot: 2026-03-17T06-41-04_530962ff
+      v2:
+        snapshot: 2026-03-17T04-27-05_b9099899
+      v3:
+        snapshot: 2026-03-17T04-27-07_6ecc2061
+      v4:
+        snapshot: 2026-03-17T04-27-08_e45a7462
+      v5:
+        snapshot: 2026-03-17T04-27-09_72290e7c
+      v6:
+        snapshot: 2026-03-17T04-27-10_f299b9d2
+      v7:
+        snapshot: 2026-03-17T04-27-12_eba7203e
+    channel_and_agent_features:
+      v1:
+        snapshot: 2026-03-17T04-27-24_d2b1a0df
+      v2:
+        snapshot: 2026-03-17T04-27-25_1bd99237
+      v3:
+        snapshot: 2026-03-17T04-27-27_e73d2e8c
+    customer_history_features:
+      v1:
+        snapshot: 2026-03-17T04-27-13_47665433
+      v2:
+        snapshot: 2026-03-17T04-27-14_1881a909
+      v3:
+        snapshot: 2026-03-17T04-27-15_c7be8caf
+      v4:
+        snapshot: 2026-03-17T04-27-17_1c0339c3
+    pricing_party_features:
+      v1:
+        snapshot: 2026-03-17T04-27-18_2e72ae25
+      v2:
+        snapshot: 2026-03-17T04-27-19_dd815223
+      v3:
+        snapshot: 2026-03-17T04-27-20_0592cbb0
+      v4:
+        snapshot: 2026-03-17T04-27-21_c2f019fb
+      v5:
+        snapshot: 2026-03-17T04-27-23_8ef8fcc4
+    room_allocation_features:
+      v1:
+        snapshot: 2026-03-17T04-27-28_0368fd56
+      v2:
+        snapshot: 2026-03-17T04-27-29_e07095bc
+```
+
+Required snapshots are selected based on snapshot id at runtime. Extra dataset and feature set snapshots do not break the execution. Missing ones do.
+
+## 3. Fields
+
+### Dataset Snapshot Bindings
+
+Dataset snapshot bindings follow the following nesting policy:
+
+```text
+datasets:
+  └─ {dataset_name}
+       └─ {dataset_version}
+            └─ snapshot_information
+```
+
+Each nested layer specifies which snapshot should be used.
+
+Example:
+
+```yaml
+datasets:
+hotel_bookings:
+    v1:
+    snapshot: 2026-03-17T03-26-25_4e817323
+    v2:
+    snapshot: 2026-03-17T03-26-27_c04ca84b
+```
+
+### Feature Set Snapshot Bindings
+
+Feature set snapshot bindings follow the following nesting policy:
+
+```text
+feature_sets:
+  └─ {feature_set_name}
+       └─ {feature_set_version}
+            └─ snapshot_information
+```
+
+Each nested layer specifies which snapshot should be used.
+
+Example:
+
+```yaml
+feature_sets:
+    booking_context_features:
+      v1:
+        snapshot: 2026-03-17T06-41-04_530962ff
+      v2:
+        snapshot: 2026-03-17T04-27-05_b9099899
+      v3:
+        snapshot: 2026-03-17T04-27-07_6ecc2061
+      v4:
+        snapshot: 2026-03-17T04-27-08_e45a7462
+      v5:
+        snapshot: 2026-03-17T04-27-09_72290e7c
+      v6:
+        snapshot: 2026-03-17T04-27-10_f299b9d2
+      v7:
+        snapshot: 2026-03-17T04-27-12_eba7203e
+    channel_and_agent_features:
+      v1:
+        snapshot: 2026-03-17T04-27-24_d2b1a0df
+      v2:
+        snapshot: 2026-03-17T04-27-25_1bd99237
+      v3:
+        snapshot: 2026-03-17T04-27-27_e73d2e8c
+```
+
+## 4. Validation
+
+Snapshot bindings are validated using the `validate_snapshot_binding_registry` and
+`validate_snapshot_binding` functions.
+
+Validation ensures:
+- the config file is formatted properly
+- snapshot is not empty
+- snapshot contains dataset or feature set bindings, if required
+
+Invalid configurations raise a `ConfigError`.

docs/configs/feature_registry.md

@@ -150,6 +150,8 @@ Validation ensures that every column listed in columns appears exactly once acro
 
 Defines feature engineering operators applied during feature freezing.
 
+**Operator hash** is generated via a script found in `scripts/generators/generate_operator_hash.py`.
+
 Operators can either:
 - materialize features into the dataset
 - define logical feature relationships

docs/configs/promotion.md

@@ -1,6 +1,6 @@
 # Promotion Thresholds
 
-Promotion thresholds defines the **minimum performance thresholds** a trained model must meet in order to be promoted (for example from candidate → production).
+Promotion thresholds registry defines the **minimum performance thresholds** a trained model must meet in order to be promoted (for example from candidate → production).
 
 Promotion rules act as a **safety gate** to prevent models with insufficient performance from being promoted.
 
@@ -27,15 +27,13 @@ General structure:
 ```text
 problem_type
   └─ segment
-       └─ promotion policy
+       └─ promotion_policy
 ```
 
 Example:
 
 ```yaml
-classification:
-
-  cancellation:
+cancellation:
 
     global:
 

docs/setup.md

@@ -65,23 +65,37 @@ In `{repo_root}/.env`.
 ### Environment Variables
 
 `ML_SERVICE_BACKEND_URL` = URL in which you want to run the `FastAPI` backend from `ml_service`
-`ML_SERVICE_FRONTEND_URLS` = URLS you want to allow access in the backend
+`ML_SERVICE_FRONTEND_URL` = URL in which you want to run the `Dash` frontend from `ml_service`
 
 Notes:
 - keep default frontend urls unless you change them in the frontend as well, or want to add more
-- frontend ports currently explicitly defined in the frontend code -> change if security becomes an issue
+- frontend port currently explicitly defined in the frontend code -> change if security becomes a concern
 
 ### Defaults
 
-`ML_SERVICE_BACKEND_URL`= http://localhost:8000
-`ML_SERVICE_FRONTEND_URLS`= [http://localhost:8050, http://localhost:8051, http://localhost:8052, http://localhost:8053, http://localhost:8054, http://localhost:8055]
+`ML_SERVICE_BACKEND_URL`=http://localhost:8000
+`ML_SERVICE_FRONTEND_URL`=http://localhost:8050
+
+## Fake data generation
+
+Fake data can be generated using a script found in `scripts/generators/generate_fake_data.py`.
+If you want to do so, make sure to either:
+1. uncomment and install the two commented-out packages in `requirements.txt`
+2. uncomment `sdv` in `requirements.txt` and the relevant parts of the `Dockerfile` (if using `Docker`)
+
+> Note: the code in that script is not modularized, as this repo does not focus on fake data generation,
+> and instead uses fake data generation only as a utility for quick and easy simulation and testing.
+
+- The repo should include some fake data at any given point, along with a trained fake data generation model.
+- Only use this feature if necessary - the packages (sdv + torch) can act oddly depending on hardware, and
+tend to take a while to install.
 
 ## Post-installation
 
 You can now operate the ml workflow in following ways
 - using `ml_service` in browser
    - backend on localhost:8000 (default)
-   - frontend on localhost:{8050-8055} (split for easier maintenance; `Dash` scales poorly)
+   - frontend on localhost:8050
 - manually
    - cli for pipelines
    - manual writing of configs