DCR-Choreographies/Simple-EDP-Use-Case.md

 # Overview
 
-To complement the other [Use Case](DCR%20Choreographies/EDP%20Use%20Case), we present a scenario where the Orchestrator (the entity that manages the Community) can request information on how much energy the producers will generate in the next period, calculate the total available energy, and update the Community Orchestrator's records accordingly.
+In this scenario, the Orchestrator (entity that manages the Community) can request information on how much energy the producers will generate in the next period, calculate the total available energy, and update the Community Orchestrator's records accordingly.
 
 ```ruby
 # roles
@@ -8,16 +8,14 @@ P(Number)
 O(Number)
 Z
 ;
-# security lattice / information flow 
+# security lattice/information flow 
 Z flows Z
 P flows P
 O flows O
 ;
 
-
 (oInfo:Info) (Z;Z) ['Manager'] [O(0)]
 
-
 (rpf:requestProductionForecast) (Z;Z) [? ] [O(0) -> P(0), P(1)]
 (acc:accountingCommunity) (Z;Z) [?: {kw:Number}] [O(0)]
 
@@ -35,3 +33,35 @@ gpf1 -->+ acc
 gpf0 -->+ acc
 acc -->% acc
 ```
+In this case, there are two roles, Prosumer (P) and Orchestrator (O), both parameterize with an id, _e.g:_ `P(1), O(0)`.
+
+> **NOTE**: The roles are defined in the first lines of the process and are used to identify the prosumers in the process. The role `Z` is a dummy role used to define the security lattice and information flow of all the events in the process.
+
+---
+The process comprises the following event representing the orchestrator information (computation event).
+
+```ruby
+(oInfo:Info) (Z;Z) ['Manager'] [O(0)]
+```
+To emulate the intended behavior, the Orchestrator (`O(0)`) sends a request (`rpf`) to all prosumers (`P(0)`,` P(1)`) asking for their production forecasts. Each prosumer responds with their forecast (`gpf_0`, `gpf_1`), and the Orchestrator updates the energy accounting records (`acc`).
+> **NOTE**: The event `acc` is local, meaning that is only available for `O(0)`, who updates the community's energy records.
+
+```ruby
+(rpf:requestProductionForecast) (Z;Z) [? ] [O(0) -> P(0), P(1)]
+(acc:accountingCommunity) (Z;Z) [?: {kw:Number}] [O(0)]
+
+(gpf_0: generateProductionForecast) (Z;Z) [?: {kw:Number}] [P(0) -> O(0)]
+(gpf_1: generateProductionForecast) (Z;Z) [?: {kw:Number}] [P(1) -> O(0)]
+```
+
+The arrows define the relations between events:
+For example, the relations below represent the flow of the process, 
+so, when the `O(0)` requests the production forecasts of the prosumers, they are mandatory to generate their production forecast (by execution of the event gpf_0), then the `O(0)` needs to update the energy accounting 
+due to the milestone and include relation. After the execution of the `acc`, the event is excluded.
+```ruby
+rpf *--> gpf_0
+rpf *--> acc
+gpf0 --><> acc
+gpf0 -->+ acc
+acc -->% acc
+```
\ No newline at end of file