Doc: Update terminology for Arista AVD data models

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

@@ -121,7 +121,7 @@ leaf:
     inband_mgmt_vlan: 10
 ```
 
-Details on this feature can be found [here](../../roles/eos_designs/docs/input-variables.md#node-type-inband-management).
+Details on this feature can be found [here](../../roles/eos_designs/docs/data-models.md#node-type-inband-management).
 
 | Node | Management0 | Vlan10 |
 | ---- | ----------- | ------ |
@@ -243,7 +243,7 @@ AVD provides a way to standardize and reuse port profiles through a compact data
 
 ![Figure: 3](images/dot1x_ports.svg)
 
-The above sample port configuration is easily produced with `port_profiles` and `network_ports` data models. Each port has similar configuration items defined in `port_profiles`, while `network_ports` defines which switches and port ranges are to be applied. The `network_ports` data model allows regex to match switches and an `expand_range` filter to cover a range of ports. For details, see the documentation for [`port_profiles`](../../roles/eos_designs/docs/input-variables.md#port-profiles-settings) and [`network_ports`](../../roles/eos_designs/docs/input-variables.md#network-ports-settings).
+The above sample port configuration is easily produced with `port_profiles` and `network_ports` data models. Each port has similar configuration items defined in `port_profiles`, while `network_ports` defines which switches and port ranges are to be applied. The `network_ports` data model allows regex to match switches and an `expand_range` filter to cover a range of ports. For details, see the documentation for [`port_profiles`](../../roles/eos_designs/docs/data-models.md#port-profiles-settings) and [`network_ports`](../../roles/eos_designs/docs/data-models.md#network-ports-settings).
 
 ## WAN/Core Edge
 
@@ -270,7 +270,7 @@ core_interfaces:
 
 ### The Playbooks
 
-Now that we have defined all of our Ansible variables (AVD inputs), it is time to generate some configurations. To make things simple, we provide two playbooks. One playbook will allow you to build and view EOS CLI intended configurations per device. The second playbook has an additional task to deploy the configurations to your switches. The playbooks are provided in the tabs below. The playbook is straightforward as it imports two AVD roles: `eos_designs` and `eos_cli_config_gen`, which do all the heavy lifting. Combining these two roles produces recommended configurations that follow Arista Design Guides.
+Now that we have defined all of our input variables according to AVD Design data models, it is time to generate some configurations. To make things simple, we provide two playbooks. One playbook will allow you to build and view EOS CLI intended configurations per device. The second playbook has an additional task to deploy the configurations to your switches. The playbooks are provided in the tabs below. The playbook is straightforward as it imports two AVD roles: `eos_designs` and `eos_cli_config_gen`, which do all the heavy lifting. Combining these two roles produces recommended configurations that follow Arista Design Guides.
 
 === "build.yml"
 

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

@@ -193,7 +193,7 @@ The tabs below show the Ansible **group_vars** used in this example.
 
 ## The Playbooks
 
-Now that we have defined all of our Ansible variables (AVD inputs), it is time to generate some configs. To make things simple, we provide two playbooks. One playbook will allow you to build and view EOS CLI intended configurations per device. The second playbook has an additional task to deploy the configurations to your switches. The playbooks are provided in the tabs below. The playbook is straightforward as it imports two AVD roles: eos_designs and eos_cli_config_gen, which do all the heavy lifting. Combining these two roles produces recommended configurations that follow Arista Design Guides.
+Now that we have defined all of our input variables according to AVD Design data models, it is time to generate some configs. To make things simple, we provide two playbooks. One playbook will allow you to build and view EOS CLI intended configurations per device. The second playbook has an additional task to deploy the configurations to your switches. The playbooks are provided in the tabs below. The playbook is straightforward as it imports two AVD roles: eos_designs and eos_cli_config_gen, which do all the heavy lifting. Combining these two roles produces recommended configurations that follow Arista Design Guides.
 
 === "build.yml"
 

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 Design inputs will 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

@@ -29,7 +29,7 @@ Figure 1 below provides a visualization of the roles inputs, and outputs and tas
 
 **Inputs:**
 
-- Structured EOS configuration according to supported data models.
+- [EOS Config](./docs/data-models.md) inputs according to supported data models.
 
 **Outputs:**
 
@@ -46,9 +46,9 @@ Figure 1 below provides a visualization of the roles inputs, and outputs and tas
 
 Requirements are located in the [collection installation guide](../../../../../docs/installation/collection-installation.md)
 
-## Input Variables
+## Data models
 
-The input variables are documented in the [Input Variables](docs/input-variables.md) section.
+The data models are documented in the [EOS Config data models](docs/data-models.md) section.
 
 ## Role Configuration
 

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

@@ -1,20 +1,22 @@
 ---
 # This title is used for search results
-title: Input variables for eos_cli_config_gen
+title: EOS Config data models (eos_cli_config_gen)
 ---
 <!--
   ~ Copyright (c) 2023-2026 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
+# EOS Config data models (eos_cli_config_gen)
 
-This document describes the supported input variables for the role `arista.avd.eos_cli_config_gen`.
+The EOS Config provides device-centric data models for expressing the Arista EOS device configurations syntax. These data models are also referred to as "structured config" within the AVD Design data models and can be leveraged with [custom structured configuration](../../eos_designs/docs/how-to/custom-structured-configuration.md) to extend or override the behaviour of Arista AVD.
+
+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.
 

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

@@ -35,6 +35,7 @@ Figure 1 below provides a visualization of the role's inputs, outputs, and tasks
 
 **Inputs:**
 
+- [AVD Design](./docs/data-models.md) inputs according to supported data models.
 - Desired variables are defined in: role defaults, group_vars, and host_vars variables.
 - If desired, the role can be extended to leverage data from dynamic sources such as an IPAM or CMDB.
 
@@ -152,7 +153,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 [Input Variables](docs/data-models.md) section.
 
 Input variables are grouped by configuration elements and are typically stored in different group_vars files.
 

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

@@ -1,23 +1,25 @@
 ---
 # This title is used for search results
-title: Input variables for eos_designs
+title: AVD Design data models (eos_designs)
 ---
 <!--
   ~ Copyright (c) 2023-2026 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 Design data models (eos_designs)
 
-This document describes the supported input variables for the role `arista.avd.eos_designs`.
+AVD Design data models provide opinionated yet flexible network-wide data models expressing the intent of your network design and configuration. AVD Design data models are transformed by the Arista AVD framework to generate configuration, documentation and tests. You can extend or override Arista AVD's behaviour by leveraging "structured config" or [custom structured configuration](../../eos_designs/docs/how-to/custom-structured-configuration.md) with data models described in [EOS Config](../../eos_cli_config_gen/docs/data-models.md).
+
+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 Design 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 +29,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 +43,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 +60,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 +89,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 +179,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.
 
@@ -865,7 +867,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

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

@@ -13,7 +13,7 @@ title: Custom descriptions and names
 The `eos_designs` role provides the capability to customize various field descriptions and names leveraging the following methods:
 
 - [AVD string formatter syntax](#avd-string-formatter-syntax) (Recommended).
-- [Node type customization](../input-variables.md#node-type-customization) with custom Jinja2 template or Python class.
+- [Node type customization](../data-models.md#node-type-customization) with custom Jinja2 template or Python class.
 
 ## AVD string formatter syntax
 
@@ -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 Design data model 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 Design 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.
@@ -82,12 +82,6 @@ Please familiarize yourself with the Arista WAN terminology before proceeding:
 - Increase test coverage in `anta_runner` support for AutoVPN and CV-Pathfinder
 - WAN HA for AutoVPN
 
-!!! 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.
-    If you find any missing functionality, please open an issue on Github.
-
 ## Getting started with WAN
 
 ### Global settings
@@ -103,7 +97,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 Design top level keys used for WAN and how they should be set:
 
 | Key | Must be the same for all the WAN routers | Comment |
 | --- | ---------------------------------------- | ------- |