Update README.md

README.md

@@ -71,16 +71,14 @@ docker run -it \
 
 ![Gen-HVAC](assets/Decision_transformer.png)
 ### Data generation
-Trajectory generation is executed through the rollout runner combined with a behavior policy.
-The framework is policy-based: any controller that maps  
+Trajectory generation is executed via the rollout runner coupled with a behavior policy. Use the data-generation script together with the rollout runner to generate 
+temporally consistent data across different buildings, climates, and envelope/occupancy variants. You can generate datasets using rule-based controllers,
+learned policies, MPC-style rules, or real-building logs such as Ecobee traces, and the same pipeline will serialize them into a unified trajectory format.
+The provided rollout utilities support targeted generation for a specific location or building type, as well as generation that mixes envelope variants, weather files,
+and building archetypes to construct large, diverse training corpora.
 
-
-use the data generation script along with rollout runner to generate sequential data. 
-
-Our architecture works with all kinds of policy and you can try different patterns for generating data. If you have ecobee data then that can work too. if you have MPC rules for
-a particular building model then it will work excellent. This works a framework for data generation.
-
-We have rollouts which you can use to generate specific building location data or building type or combine different envolop locations and weather and building type.
+All of this needs to be run inside a docker container which has energy plus. If you already have energy plus setup as a native software then you can simply adopt the synergym setup, and
+generate the sequential training data.
 
 ```bash
 # Inside Docker container
@@ -127,23 +125,22 @@ Each file contains:
 
 Temporal resolution: 15 minutes  
 Episode length: 35040 timesteps (1 simulation year)
-### Training Phase
-
-After you have generated data you can move on to the training phase which , for our experiments we generted more than 2300 sequential data combinations and resulted in more than 3 million trajectories.
 
-Training phase is devided into 3 parts Dataloader, decision transformer and losses and finally the main training code.
+### Training Phase
 
-The only changes needed will be mapping of the observation data from the sensors and also the action keys. We have already done that for a office small STD2013 and Office Medium STD2013. The same architecture
-can be extended to other buildings in the HOT data set and also with the ecobee data set as well as any real building dataset.
+After data generation, you can proceed to the training phase. In our experiments, we generated 2,300+ building–weather–policy combinations, yielding 3M+ sequential
+state–action transitions. The training pipeline is modular and consists of the dataloader, the Decision Transformer model, the loss modules, and the main training loop. 
 
-Next comes the training code. We tried to make a system which can a be framed as a general zero shot system. However the novelty also lies in the entire system since this system can be extended
-to cover vast amount of data atleast 1000 to 10000 times more. In the training code you have to simply increase the size of the transformer model and our losses and embeddings layers will 
-try to generalize over more and more buildings residential homes etc.
+In most cases, the only required adaptation is mapping your raw sensor observations to the expected schema and defining the corresponding action keys;
+we provide validated mappings for OfficeSmall STD2013 (5-zone) and OfficeMedium STD2013 (15-zone), and the same interface extends directly to other HOT buildings 
+as well as Ecobee or other real-building datasets. The training implementation is designed for generalization and zero-shot transfer.
+Scaling to larger and more diverse building types primarily requires increasing model capacity (d_model, layers, heads), the embedding and loss structure can remain
+unchanged. It supports heterogeneous buildings, zone counts, and sensing modalities.
+We condition the policy on multi-objective return-to-go (RTG) targets for energy and comfort, and optionally apply Top-K filtering/selection by RTG to bias training 
+toward higher-quality sub-trajectories, enabling the model to learn how different action sequences causally trade off energy consumption and comfort outcomes.
 
-We condition on different RTG for comfort and energy savings. Anykind of data will already be filtered on different RTG and TOPK filtering helping model to understand what kind of 
-actions lead to what kind of consequenses.
 
-5) LLM deployment phase
+### LLM deployment phase
 Gen-HVAC supports an optional LLM + Digital Human-in-the-Loop (DHIL) layer that modulates preference/RTG targets and high-level
 constraints. For local LLM hosting, install Ollama, pull a quantized model
 , and launch the service.
@@ -154,7 +151,7 @@ In our testing we choose Deepseek R1.
 Once pulled, sanity-check locally with ollama run deepseek-r1:7b, then in another terminal point your Gen-HVAC LLM client to the default endpoint  and run your integration from the llm/ folder (e.g., python -m llm.server --host 0.0.0.0 --port 8000 and python -m llm.client --base_url http://localhost:xxxx --model deepseek-r1:7b.
 After the LLM endpoint is up, you can proceed to the inference server step to bind the persona/prompt layer to RTG conditioning and the control loop in one end to end pipeline.
 
-7) Inference 
+ ### Inference 
 During inference, we deploy Gen-HVAC as a stateless HTTP microservice
 
  that loads the trained Decision Transformer checkpoint and normalization statistics at startup, maintains a short autoregressive context window internally,