EDC is an open source framework hosted by the Eclipse Foundation for building secure, globally-scalable data-sharing services.
EDC provides highly customizable components for creating control planes, data planes, decentralized identity systems,
-and federated data catalogs. Backed by leading companies and cloud providers, EDC gives engineers the tools they need
+and federated data catalogs. Backed by leading companies and cloud providers, EDC gives developers the tools they need
to deliver innovative solutions for data exchange networks.
+{{< /blocks/section >}}
diff --git a/content/en/documentation/for-adopters/control-plane/_index.md b/content/en/documentation/for-adopters/control-plane/_index.md
index 1a3d40f..63a8342 100644
--- a/content/en/documentation/for-adopters/control-plane/_index.md
+++ b/content/en/documentation/for-adopters/control-plane/_index.md
@@ -343,7 +343,7 @@ After a contract negotiation has been finalized, a consumer can request data ass
![Transfer Types](transfer-types.svg)
-> Pay particular attention to how data is modeled. In particular, model your assets in a way that minimizes the number of contract negotiations and transfer processes that need to be created. For large data sets such as machine-learning data, this is relatively straightforward: an asset can represent each individual data set. Consumers will typically need to transfer the data once or infrequently, so the number of contract negotiations and transfer processes will remain small, typically one contract negotiation and a few transfers.
+> Pay careful attention to how data is modeled. In particular, model your assets in a way that minimizes the number of contract negotiations and transfer processes that need to be created. For large data sets such as machine-learning data, this is relatively straightforward: an asset can represent each individual data set. Consumers will typically need to transfer the data once or infrequently, so the number of contract negotiations and transfer processes will remain small, typically one contract negotiation and a few transfers.
>
>Now, let's take as an example a supplier that wishes to expose parts data to their partners. Do not model each part as a separate asset, as that would require at least one contract negotiation and transfer process per part. If there are millions of parts, the number of contract negotiations and transfer processes will quickly grow out of control. Instead, have a single asset represent aggregate data, such as all parts, or a significant subset, such as a part type. Only one contract negotiation will be needed, and if the transfer process is non-finite and kept open, consumers can make multiple parts data requests (over the course of hours, days, months, etc.) without incurring additional overhead.
diff --git a/hugo.toml b/hugo.toml
index 83df25a..7c42182 100644
--- a/hugo.toml
+++ b/hugo.toml
@@ -126,7 +126,7 @@ offlineSearch = false
prism_syntax_highlighting = false
[params.copyright]
-authors = "Docsy Authors | [CC BY 4.0](https://creativecommons.org/licenses/by/4.0) | "
+authors = "Eclipse Contributors | [Vector art by Freepik](https://www.freepik.com)"
from_year = 2018
# User interface configuration
diff --git a/static/images/eclipse.foundation.logo.svg b/static/images/eclipse.foundation.logo.svg
new file mode 100644
index 0000000..7ce0d3e
--- /dev/null
+++ b/static/images/eclipse.foundation.logo.svg
@@ -0,0 +1,13 @@
+
diff --git a/static/images/edc.schematic.svg b/static/images/edc.schematic.svg
new file mode 100644
index 0000000..31180a9
--- /dev/null
+++ b/static/images/edc.schematic.svg
@@ -0,0 +1,1243 @@
+