Doc: Update terminology for Arista AVD data models

Author: carlbuchmann

ansible_collections/arista/avd/examples/campus-fabric/README.md

@@ -152,7 +152,7 @@ mgmt_interface_vrf: default
 
 AVD Fabric Input Variables
 
-To apply AVD input variables to the nodes in the fabric, we make use of Ansible group_vars. How and where you define the variables is your choice. The group_vars table below is one example of AVD fabric variables.
+To apply AVD input data models to the nodes in the fabric, we make use of Ansible group_vars. How and where you define the variables is your choice. The group_vars table below is one example of AVD fabric variables.
 
 | group_vars/              | Description                                   |
 | ------------------------ | --------------------------------------------- |

ansible_collections/arista/avd/roles/cv_deploy/README.md

@@ -184,7 +184,7 @@ cv_devices: [ DC1-L3LEAF1A, DC1-L3LEAF1B ]
 
 The role will fail if a device is not found on CloudVision. Any workspace created will be abandoned automatically.
 
-Devices with `is_deployed: false` set as part of `eos_designs` inputs will automatically be ignored.
+Devices with `is_deployed: false` set as part of AVD inputs will automatically be ignored.
 
 It is possible to ignore other missing devices by simply skipping them and continue with the remaining devices.
 

ansible_collections/arista/avd/roles/eos_cli_config_gen/README.md

@@ -48,7 +48,7 @@ Requirements are located in the [collection installation guide](../../../../../d
 
 ## Input Variables
 
-The input variables are documented in the [Input Variables](docs/input-variables.md) section.
+The input variables are documented in the [Structured EOS configuration data models](docs/input-variables.md) section.
 
 ## Role Configuration
 

ansible_collections/arista/avd/roles/eos_cli_config_gen/docs/input-variables.md

@@ -1,25 +1,28 @@
 ---
 # This title is used for search results
-title: Input variables for eos_cli_config_gen
+title: Structured EOS configuration data models
 ---
 <!--
   ~ Copyright (c) 2023-2025 Arista Networks, Inc.
   ~ Use of this source code is governed by the Apache License 2.0
   ~ that can be found in the LICENSE file.
   -->
 
-# Input variables for eos_cli_config_gen
+# Structured EOS Configuration data models
 
-This document describes the supported input variables for the role `arista.avd.eos_cli_config_gen`.
+ The structured EOS configuration provides device-centric data models for expressing the Arista EOS device configurations syntax.
+
+!!! note
+    For Ansible users this document describes the supported input variables for the role `arista.avd.eos_cli_config_gen`.
 
 Since several data models have changed between AVD versions 5.x and 6.x, it is recommended to study the [Porting Guide for AVD 6.x.x](../../../../../../docs/porting-guides/6.x.x.md) for existing deployments.
 
-The input variables are documented below in tables and YAML.
+The data models are documented below in tables and YAML.
 
 All values are optional.
 
 !!! note
-    All input variables are validated by a schema. If additional custom keys are desired, a key starting with an underscore `_`, will be ignored.
+    All data models are validated by a schema. If additional custom keys are desired, a key starting with an underscore `_`, will be ignored.
 
 !!! warning
     Available features and variables may vary by platforms, refer to documentation on arista.com for specifics.

ansible_collections/arista/avd/roles/eos_designs/docs/how-to/custom-descriptions-names.md

@@ -22,7 +22,7 @@ It provides extra protection from malicious format strings and adds support for
 
 The following syntax is supported: `"{" [field_name] ["?"] ["<" prefix] [">" suffix] ["!" conversion] [":" format_spec] "}"`:
 
-- `[field_name]`: Template field or variable, as per `eos_designs` input variables documentation.
+- `[field_name]`: Template field or variable, as per AVD inputs variables documentation.
 - `["?"]`: The literal `?` signals that the field is optional and will not be printed if the value is missing or None.
 - `["<" prefix]`: Prefix string including spaces which will be inserted before the field value. Most useful in combination with `?`. Prefix should not contain `"<"`, `">"`, `"!"` or `":"`.
 - `[">" suffix]`: The suffix string including spaces which will be inserted after the field value. Most useful in combination with `?`. The suffix should not contain `"<"`, `">"`, `"!"` or `":"`.
@@ -56,8 +56,8 @@ results in: `SERVERS_server2`
 
 ## Default description or name values
 
-Below is a complete list of input variables and default values to facilitate customizing the description and names of values.
-Please consult the `eos_designs` input variables documentation to obtain the available template field(s) (`[field_name]`).
+Below is a complete list of data models and default values to facilitate customizing the description and names of values.
+Please consult the AVD inputs data model documentation to obtain the available template field(s) (`[field_name]`).
 
 ```yaml
 # Loopback interfaces description

ansible_collections/arista/avd/roles/eos_designs/docs/how-to/wan.md

@@ -50,7 +50,7 @@ Please familiarize yourself with the Arista WAN terminology before proceeding:
 
 ### Known limitations
 
-- Zones are not configurable for CV Pathfinder. All sites are being configured in a default zone `<region_name>-ZONE` with ID `1`. Hence, in `eos_designs`, the `transit` node type is always configured as `transit region`.
+- Zones are not configurable for CV Pathfinder. All sites are being configured in a default zone `<region_name>-ZONE` with ID `1`. Hence, with Arista AVD the `transit` node type is always configured as `transit region`.
 - All Pathfinders must be able to create a full mesh
 - No IPv6 support
 - Path-group ID is currently required under `wan_path_groups` until an algorithm is implemented to auto generate IDs.
@@ -85,7 +85,7 @@ Please familiarize yourself with the Arista WAN terminology before proceeding:
 !!! info
 
     `eos_cli_config_gen` schema should support all of the required keys to configure a WAN network, whether AutoVPN or Pathfinder except for the most recent features.
-    This means that any missing `eos_designs` feature should be supported using `custom_structured_configuration` functionality.
+    This means that any missing Arista AVD features should be supported using `custom_structured_configuration` functionality.
     If you find any missing functionality, please open an issue on Github.
 
 ## Getting started with WAN
@@ -103,7 +103,7 @@ Please familiarize yourself with the Arista WAN terminology before proceeding:
 
 #### Summary
 
-The following table list the `eos_designs` top level keys used for WAN and how they should be set:
+The following table list the AVD inputs top level keys used for WAN and how they should be set:
 
 | Key | Must be the same for all the WAN routers | Comment |
 | --- | ---------------------------------------- | ------- |

ansible_collections/arista/avd/roles/eos_designs/docs/input-variables.md

@@ -1,23 +1,26 @@
 ---
 # This title is used for search results
-title: Input variables for eos_designs
+title: AVD input data models
 ---
 <!--
   ~ Copyright (c) 2023-2025 Arista Networks, Inc.
   ~ Use of this source code is governed by the Apache License 2.0
   ~ that can be found in the LICENSE file.
   -->
 
-# Input variables for eos_designs
+# AVD input data models
 
-This document describes the supported input variables for the role `arista.avd.eos_designs`.
+AVD inputs provide opinionated yet flexible network-wide data models expressing the intent of your network design and configuration.
+
+!!! note
+    For Ansible users this document describes the supported input variables for the role `arista.avd.eos_designs`.
 
 Since several data models have changed between AVD versions 5.x and 6.x, it is recommended to study the [Porting Guide for AVD 6.x.x](../../../../../../docs/porting-guides/6.x.x.md) for existing deployments.
 
-The input variables are documented below in tables and YAML.
+The data models are documented below in tables and YAML.
 
 !!! note
-    All input variables are validated by a schema. If additional custom keys are desired, a key starting with an underscore `_`, will be ignored.
+    All AVD input data models are validated by a schema. If additional custom keys are desired, a key starting with an underscore `_`, will be ignored.
 
 !!! warning
     Available features and variables may vary by platforms, refer to documentation on arista.com for specifics.
@@ -27,11 +30,11 @@ The input variables are documented below in tables and YAML.
 
 ## Supported designs
 
-`eos_designs` supports multiple options such as L3LS-EVPN with 3-stage or 5-stage, L2LS, MPLS, AutoVPN and CV Pathfinder. The sections below highlight some of these topologies, but you can extend `eos_designs` to support your own topology by using [`node_type_keys`](#node-type-customization) to create your own node type.
+Arista AVD supports multiple network design types such as L3LS-EVPN with 3-stage, 5-stage, L2LS, MPLS, AutoVPN and CV Pathfinder. The sections below highlight some of these topologies, but you can extend Arista AVD to support your own topology by using [`node_type_keys`](#node-type-customization) to create your own node type.
 
 ### 3-stage clos topology support (Leaf & Spine)
 
-- The **eos_designs** role support various deployments with layer 3 leaf and spine (3-stage Clos) and optionally, with dedicated overlay controllers.
+- Arista AVD supports various deployments with layer 3 leaf and spine (3-stage Clos) and optionally, with dedicated overlay controllers.
 - 3 stage Clos fabric can be represented as spines, L3 leafs and L2 leafs, and also referred to as a "POD".
 
 See the following examples:
@@ -41,14 +44,14 @@ See the following examples:
 
 ### 5-stage clos topology support (Super Spine)
 
-- The **eos_designs** role support larger deployments with super-spines (5-stage Clos) and optionally, with dedicated overlay controllers.
+- Arista AVD supports larger deployments with super-spines (5-stage Clos) and optionally, with dedicated overlay controllers.
 - 5 stage Clos fabric can be represented as multiple leaf-spine structures (called PODs - Point of Delivery) interconnected by super-spines.
 - The logic to deploy every leaf-spine POD fabric remains unchanged.
 - Super-spines can be deployed as a single plane (typically chassis switches) or multiple planes.
 
 ### Layer 2 Leaf Spine
 
-- The **eos_designs** role support various deployments with layer 2 leaf and spine. For example, routing may terminate at the spine level or an external L3 device.
+- Arista AVD supports various deployments with layer 2 leaf and spine. For example, routing may terminate at the spine level or an external L3 device.
 - The Clos fabric can be represented as L3 spines, spines, and leafs.
 
 See the following examples:
@@ -58,7 +61,7 @@ See the following examples:
 
 ### MPLS
 
-The **eos_designs** role supports any arbitrary physical mesh topology by combining and interconnecting different node types with the `core_interfaces` settings.
+Arista AVD supports any arbitrary physical mesh topology by combining and interconnecting different node types with the `core_interfaces` settings.
 
 The following underlay routing protocols are supported:
 
@@ -87,7 +90,7 @@ See the following example:
 
 ### WAN - AutoVPN and CV Pathfinder
 
-The **eos_designs** role with the `l3ls-evpn` design type supports the node types `wan_rr` and `wan_router`.
+Arista AVD supports AutoVPN and CV Pathfinder deployments with the node types `wan_rr` and `wan_router`.
 The default underlay routing protocol is set to none but eBGP is supported as well.
 
 The following overlay routing protocols are supported:
@@ -177,7 +180,7 @@ The pool manager stores data in a YAML file per fabric. The default path is `<ro
 
 ## Node Type Variables
 
-The following tables provide information on the default node types that are pre-defined in `eos_designs`.
+The following tables provide information on the default node types that are pre-defined in AVD.
 
 To customize or create new node types, please refer to [node type customization](#node-type-customization) section.
 
@@ -882,7 +885,7 @@ The following overlay routing protocols are supported:
 - CVX (CloudVision eXchange)
 
 ¹ For use with design type "l2ls" or other designs where there is no requirement for a routing protocol for underlay and/or overlay on l3 devices.<br />
-² By setting `overlay_routing_protocol:HER`, `eos_designs` will configure static VXLAN flood-lists instead of using a dynamic overlay protocol.
+² By setting `overlay_routing_protocol:HER`, Arista AVD will configure static VXLAN flood-lists instead of using a dynamic overlay protocol.
 
 --8<--
 ansible_collections/arista/avd/roles/eos_designs/docs/tables/overlay-settings.md