fix: updated content of aggregator sections

APIs/openEO/federation/backends/contract.qmd → APIs/openEO/federation/backends/guidelines.qmd

@@ -1,17 +1,19 @@
-# Federation Contract
+# Federation provider guidelines
 
-For a federation to work, all providers need to agree with a common federation contract.
-For the Copernicus Data Space Ecosystem, the proposed contract is based upon the groundwork established through ESA's openEO platform.
+For a federation to be effective, all providers must agree to a common set of guidelines. These guidelines have two main 
+goals:
 
-This contract has 2 main goals:
+* **Boost User Satisfaction**: Measure user satisfaction through metrics such as user growth and the ratio of complaints 
+to the usage of specific features.
+* **Agree on Interfaces and Harmonization Rules**: Align different services within the federation by agreeing on standard 
+interfaces and harmonization rules.
 
-1. Boost user satisfaction, which can be measured in terms of user growth and number of complaints versus the usage of a specific feature.
-2. Agree on interfaces and harmonization rules to align the different services within the federation.
 
-To join the federation, providers are expected to fulfill the requirements outlined on this page.
-However, to accommodate and encourage new backend entries into the federation, these requirements are open to negotiation if there are good arguments for changing the current contract agreements.
+To join the federation, providers are expected to fulfill the requirements outlined on this page. However, to accommodate 
+and encourage new backend entries into the federation, these requirements are open to negotiation if there are compelling 
+reasons for changing the current compliance guidelines.
 
-For more detailed information, please refer to the different parts of the federation contract:
+For more detailed information, please refer to the different parts of the federation guidelines:
 
 - [API](./api.md)
 - [Collections](./collections.md)
@@ -36,7 +38,8 @@ The short-term benefits of joining the federation include:
 3. Integrate the CDSE identity provider as your openEO service will need to accept CDSE users.
 4. Integrate with the accounting component by reporting the usage of CDSE users through a JSON HTTP API. The API details will be provided upon request.
 
-Finally, an official agreement will need to be established confirming that the service provider agrees with the federation contract and SLA.
+Finally, an official agreement must be established, confirming that the service provider agrees to a federation contract, 
+confirms compliance with the guidelines outlined in this document and adheres to the SLA.
 
 > **Important**<br/>
 > When joining the openEO federation, the provider agrees to the statements outlined in the following policies:
@@ -63,11 +66,15 @@ Reverting a 'stable' feature to 'experimental' should be considered as a backwar
 
 ## Credit reporting
 
-As specified, service providers need to log the resource usage in the federation's central accounting service.
-This will allow them to be compensated for incurred usage.
-The value of a credit is fixed, and service providers are free to choose the resources they log.
-Typical examples include memory and cpu hours, but it can also be based on a more complex logic, such as amount of input data or specific processes that are used.
-To ensure full transparency, service providers are requested to document this logic.
+As specified, service providers must log resource usage in the federation’s central accounting service. This central 
+service provides an API interface that supports federated accounting by offering endpoints for checking user credits and 
+logging resource usage based on various metrics. This system ensures that providers are compensated for incurred usage.
+
+The value of a credit is fixed, and service providers have the flexibility to choose the resources they log. Typical 
+examples include memory and CPU hours, but resource logging can also be based on more complex criteria, such as the 
+amount of input data or specific processes used. To ensure full transparency, service providers are required to document 
+their logging logic.
+
 
 ## Availability of the service
 Providers are encouraged to continuously enhance their backend systems to optimize processing efficiency and improve the overall user experience.

APIs/openEO/federation/openeo_federation.md

@@ -19,12 +19,20 @@ All external providers comply with the regulations of the federation, but are no
 broader Copernicus ecosystem, they are either fully independent providers, or are governed and/or funded by other parties. This mainly impacts their currently foreseen lifetime, but also 
 how they handle aspects that are not part of federation governance.
 
-You can find a description of the technical design [here](./backends/design.md), as well as a more extensive [overview of federation governance](./backends/contract.qmd).
+You can find a description of the technical design [here](./backends/design.md), as well as a more extensive [overview of federation governance](./backends/guidelines.qmd).
 
 ## Federation credit usage
 
-The usage of processing capacity in the federation is likely to lead to credit consumption.
-This usage will be reported in the [openEO algorithm plaza](../../../Applications/PlazaDetails/Reporting.qmd). 
+Using the federation's processing capacity will lead to credit consumption. This credit usage can be monitored through 
+openEO Algorithm Plaza's [reporting capabilities](../../../Applications/PlazaDetails/Reporting.qmd). Users can also get 
+more information on their credit wallets via the openEO Algorithm Plaza billing page. Detailed instructions on accessing 
+your credit wallets are available [here](../../../Applications/AlgorithmPlaza.qmd#step-3-check-your-credits).
+
+![Credit wallets in federation](../../../Applications/_images/billing_federation.png){#fig-federation}
+
+As shown in @fig-federation, credit wallets can be linked to one or more providers. This setup provides a clear overview 
+of the remaining credits available for usage with different providers.
+
 To support basic processing within the federation, external providers can allow a limited amount of credits, similar to the [free openEO credits](../../../Quotas.qmd) offered by CDSE.
 It is important to note that there is clear separation of your credits amongst the external providers.
 This means that using an external provider will not lead to a reduction in the free credits supplied by CDSE. 

Applications/AlgorithmPlaza.qmd

@@ -78,7 +78,7 @@ Using any openEO processes, including those offered as services in this marketpl
 This marketplace simplifies credit management, allowing users to monitor their account's credits easily. You can check your openEO credit under the [`Billing`](https://marketplace-portal.dataspace.copernicus.eu/billing){target="_blank"} section. Moreover, every user is provided with 4000 credits each month, with which they can execute multiple services.
 
 
-![](_images/billing2.png)
+![](_images/billing.png)
 
 Credits are deducted based on the chosen services and spatial extent.The amount will vary depending on the processing complexity and time required for each type of service. Detailed examples of some well-known services and how they fit into the 4000 free credits can further be found [here](PlazaDetails/Strength.qmd).
 

_quarto.yml

@@ -135,8 +135,7 @@ website:
             - section: "openEO federation"
               href: "APIs/openEO/federation/openeo_federation.md"
               contents:
-                - href: "APIs/openEO/federation/backends/contract.qmd"
-                  text: Federation contract
+                - href: "APIs/openEO/federation/backends/guidelines.qmd"
             - href: "https://openeo.org/documentation/1.0/developers/api/reference.html"
               text: REST API Reference
               target: "_blank"