diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 810aa068f8..b82a29ccc9 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -138,6 +138,16 @@ Add the doc id to the appropriate section of [sidebars.js](../sidebars.js). Do *
   - *router* — an SSR data-plane node (lowercase).
   - *authority* — the top-level config domain.
   - *PCLI* — the SSR command-line interface.
+- **Punctuation in lists and tables:**
+  - If **any** entry in a bulleted list or table column contains internal punctuation (comma, colon, semi-colon), **every** entry in that list or column must end with a period.
+  - Exception: entries that are only one or two words, or are names/categories (e.g., column headers, labels) do not require a closing period.
+  - *Good:* `| Prevents generation for that neighbor. |` (other rows have commas)
+  - *Bad:* `| Prevents generation for that neighbor |` (missing period when siblings have punctuation)
+- **Capitalization after colons:** If what follows a colon is a complete sentence, capitalize the first word. *Good:* `generates two sets: The _peer_ objects that form…`. *Bad:* `generates two sets: the _peer_ objects that form…`.
+- **No empty table headers:** Do not use tables with empty header cells (e.g., `| | |`) for visual separation. Every table must have meaningful column headers. If you need a key-value layout, use a definition list or a two-column table with headers like `Property` / `Value` or `Field` / `Description`.
+- **Horizontal rules (`---`):** Do not insert `---` between subsections within the same heading level purely for visual spacing. Use them only to separate fundamentally different major sections (e.g., between "User-Facing Configuration" and "Infrastructure Configuration"). Markdown headings already provide visual separation.
+- **Voice consistency:** Always use "you" (second person) when addressing the reader — not "users" or "the user." *Good:* `configuration that you typically interact with`. *Bad:* `configuration that users typically interact with`.
+- **Avoid exposing internals unnecessarily:** Do not describe implementation details (e.g., "hidden metadata list") unless the reader needs that information to perform a task. If an internal mechanism is relevant (e.g., for import/export behavior), introduce it where it is actionable, not in overviews.
 - **Admonitions:** use Docusaurus syntax — `:::note`, `:::tip`, `:::caution`, `:::important`, `:::danger`. Close with `:::`.
 - **Code blocks:** always specify the language hint (`text`, `bash`, `yaml`, `json`, `python`).
 - **Avoid jargon** unless defined on first use; link to a concept page if one exists.
diff --git a/docs/config_autogenerated.md b/docs/config_autogenerated.md
new file mode 100644
index 0000000000..811aeea427
--- /dev/null
+++ b/docs/config_autogenerated.md
@@ -0,0 +1,498 @@
+---
+title: Auto-Generated Configuration
+sidebar_label: Auto-Generated Configuration
+---
+
+During every `commit`, the SSR platform automatically generates certain configuration elements based on the current topology and feature configuration. These elements are removed and re-created on each commit by default, meaning any manual edits to them are lost unless you take explicit ownership first.
+
+This document covers what gets generated, what triggers it, how to prevent or customize it, and the internal mechanisms that control the lifecycle.
+
+## The Auto-Generation Lifecycle
+
+On every commit, the system runs a three-phase cycle:
+
+1. **Removal** — The system deletes all previously auto-generated elements so they can be rebuilt from scratch. There are two independent removal paths:
+   - **Element-level:** All services, service-routes, peers, adjacencies, tenants, and service-policies where `generated` is set to `true` are collected and removed.
+   - **Metadata-level:** An authority metadata list (`authority > generated`) tracks elements created by certain subsystems (plugins, DHCP server KNI, port-forwarding, software-update). All paths recorded in that list are removed, and the metadata entries are cleared.
+
+2. **Generation** — Each subsystem builder runs and creates fresh elements. Before creating an element, the builder checks whether a matching element already exists with `generated` set to `false`. If it does, that element is treated as user-provisioned and generation is skipped.
+
+3. **Metadata update** — Newly generated elements from metadata-tracking subsystems are recorded in the authority metadata list for the next cycle.
+
+### Two Categories of Subsystem
+
+Not all subsystems use both removal paths. This distinction determines how to override elements:
+
+| Category | Subsystems | Removal Path | Override Method |
+|----------|-----------|-------------|-----------------|
+| **Leaf-only** | Peer Topology builder, conductor services, BGP services, DHCP relay, PIM/MSDP, alarm shelving, internal tenants. | Element-level (`generated` leaf) only | Set `generated` to `false` directly |
+| **Leaf + metadata** | Plugin builder, DHCP server (KNI), software-update, port-forwarding. | Both element-level and metadata-level | Use `override-generated true` |
+
+:::tip
+The PCLI automatically presents the correct command based on the element's category. Always use `override-generated` when it appears on the element. Only set `generated` to `false` directly when `override-generated` is not available (i.e., the `generated` leaf is visible instead).
+:::
+
+### How To Identify Auto-Generated Elements
+
+Any element that the system auto-generates carries `generated true` in the configuration. You can inspect this field in the PCLI to determine whether an element is system-managed or user-provisioned. For a complete list of all auto-generated element types and their override methods, see the [Quick Reference](#quick-reference) at the end of this page.
+
+## Taking Ownership of Auto-Generated Elements
+
+### Recommended: The `create config autogenerated` Single-Commit Workflow
+
+The most practical approach uses the `create config autogenerated` command to avoid a two-commit cycle:
+
+```
+admin@conductor> create config autogenerated
+```
+
+This runs the same generation logic as `commit` but **stages the results into the candidate configuration without committing**. You can then review, override, and customize elements before committing once.
+
+**Workflow:**
+
+1. Configure your triggers (neighborhoods, conductor-address, BGP neighbors, etc.).
+2. Run `create config autogenerated` — auto-generated elements appear in the candidate.
+3. Enter config editing mode and navigate to elements you want to customize.
+4. Override those elements (see below).
+5. Make your modifications.
+6. Commit **once** — the removal phase skips your overridden elements, and the generation phase sees them as user-provisioned.
+
+During the commit, elements with `generated` set to `false` survive the removal phase and are skipped during regeneration, preserving your customizations in a single commit.
+
+:::note
+If the underlying changes (e.g., new neighborhoods, new conductor addresses) trigger configuration updates, re-run `create config autogenerated` to preview newly generated elements before committing.
+:::
+
+### Overriding Leaf-Only Elements
+
+For elements generated by the Peer Topology builder, conductor services, BGP, DHCP relay, PIM, or MSDP — the `generated` leaf is directly visible in the PCLI:
+
+```
+config
+    authority
+        router  <router>
+            service-route  <auto-generated-route>
+                generated  false
+            exit
+        exit
+    exit
+exit
+```
+
+Setting `generated` to `false` is sufficient. These subsystems only check the leaf on the element and do not use metadata tracking.
+
+### Overriding Metadata-Tracked Elements
+
+For elements generated by plugins, DHCP server (KNI), port-forwarding, or software-update — the PCLI shows the `override-generated` command instead of the `generated` leaf:
+
+```
+*admin@conductor# config
+*admin@conductor (config)# authority
+*admin@conductor (authority)# router <router>
+*admin@conductor (router)# node <node>
+*admin@conductor (node)# device-interface <kni-interface>
+*admin@conductor (device-interface)# override-generated true
+Are you sure you want to make '<kni-interface>' persistent?
+It will no longer be auto-generated. [y/N]:
+```
+
+This performs two simultaneous actions:
+1. Sets `persistent` to `true` in the metadata tracking entry — prevents metadata-based removal
+2. Sets `generated` to `false` on the element — prevents element-level removal and causes the builder to skip regeneration
+
+:::warning
+Both flags are required for full protection on metadata-tracked elements. Setting only `generated` to `false` is **unsafe** — the metadata removal path would still delete the element on the next commit.
+:::
+
+**To revert** any override and re-enable auto-generation, run `override-generated false` (or set `generated` to `true` for leaf-only elements). On the next commit the element will be removed and re-generated by the system.
+
+### Pre-Provisioning Elements
+
+If you create an element with the **same name** that auto-generation would use before generation runs, the system detects it and skips generation. The manually created element has `generated` set to `false` by default, so it is treated as user-provisioned.
+
+This works for adjacencies, service-routes, and services.
+
+## Auto-Generated Configuration Reference
+
+### User-Facing Configuration
+
+This section covers auto-generated configuration that you typically interact with and may need to customize or override.
+
+#### Peer Topology Builder
+
+The Peer Topology builder automatically establishes the inter-router topology and distributes service reachability information across peer routers, enabling dynamic topology discovery and service mesh capabilities without manual configuration. It generates two related sets of elements: The _peer_ and _adjacency_ objects that form the inter-router topology, and the peer-type _service-route_ objects that distribute service reachability across that topology.
+
+**Peers and Adjacencies**
+
+| Field | Description |
+|---|---|
+| **Trigger** | _neighborhood_ configured on a forwarding _network-interface_. |
+| **What is generated** | _peer_ objects between routers sharing the same neighborhood; _adjacency_ objects on both sides. |
+| **Category** | Leaf-only |
+
+Conditions for generation:
+- The _network-interface_ must have `forwarding` set to `true` (default) and at least one _neighborhood_ entry.
+- Topology matching: `mesh` ↔ `mesh`/`hub`/`spoke`; `hub` ↔ `spoke`/`mesh`; `spoke` ↔ `hub`/`mesh`.
+- `peer-connectivity` must not be `outbound-only` on **both** sides.
+- `inter-router-security` must be set on any interface with a neighborhood.
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Remove _neighborhood_ from the interface | Per-interface | No adjacencies generated for that interface |
+| Set `peer-connectivity` to `outbound-only` on both sides | Per-adjacency pair | Prevents that specific adjacency |
+| Set `generated` to `false` on an adjacency or peer | Per-element | Takes ownership of that element |
+| Pre-provision the adjacency before commit | Per-element | System detects it and skips generation |
+
+:::note
+There is no global toggle. If neighborhoods are configured, peers and adjacencies **will** be generated unless overridden per-element.
+:::
+
+**Service-routes**
+
+| Field | Description |
+|---|---|
+| **Trigger** | A router has a non-peer _service-route_ for a shared service, and peer routers exist. |
+| **What is generated** | Peer-type _service-route_ objects on remote routers pointing back to the source. |
+| **Category** | Leaf-only |
+
+Conditions for generation:
+1. Service has `share-service-routes` set to `true` (default).
+2. Source router has at least one non-peer service-route (e.g., next-hop) for the service.
+3. Service `application-type` is `generic`.
+4. Service `applies-to` allows the peer router.
+5. Authority is not using a Peer Topology repository.
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Set `share-service-routes` to `false` | Per-service | Prevents Peer Topology builder route generation for that service |
+| Configure `applies-to` restrictions | Per-service | Limits which routers receive generated routes |
+| Set `generated` to `false` on a service-route | Per-element | Takes ownership of that route |
+| Pre-provision a service-route with the same name | Per-element | System skips generation for that route |
+
+
+#### Conductor Services
+
+The Conductor Services subsystem provides automatic connectivity from managed routers back to the conductor system, enabling centralized configuration, monitoring, and software updates. Generation is unconditional when any `conductor-address` is configured. There is no way to fully disable this category, but there are customization options and per-element overrides:
+
+| Field | Description |
+|---|---|
+| **Trigger** | `conductor-address` is configured on the authority. |
+| **What is generated** | Conductor reachability _service_, _service-policy_, _service-route_, and related _tenant_ objects. |
+| **Category** | Leaf-only |
+
+| Method | Level | Effect |
+|--------|-------|--------|
+| `management-service-generation > service-route-type` | Authority or Router | Choose `paths-as-next-hop` (default) or `paths-as-service-route` |
+| `management-service-generation > service-policy` | Authority or Router | Use a custom _service-policy_ instead of the auto-generated one |
+| `management-service-generation > proxy` | Router only | Enable/disable proxy of public-to-private conductor addresses |
+| Set `generated` to `false` on a conductor service or route | Per-element | Takes ownership of that element |
+
+
+#### Management Over Forwarding Interface (MOFI) Services
+
+The MOFI builder automatically provisions management services for various network management and operational functions, enabling these services to be delivered over forwarding interfaces (data plane) when management interfaces are not available. This provides management connectivity through active data paths.
+
+| Field | Description |
+|---|---|
+| **Trigger** | A _network-interface_ configured with `management: true` on a forwarding interface. |
+| **What is generated** | Services and service-routes for NTP, DNS, SNMP, Syslog, IPFIX, HTTP-HTTPS (package updates), and Audit functions. |
+| **Category** | Leaf-only |
+
+The builder generates services for the following management traffic types:
+
+| Service Type | Purpose |
+|---|---|
+| NTP | Network Time Protocol for clock synchronization |
+| DNS | Domain Name System for name resolution |
+| SNMP | Simple Network Management Protocol for device management |
+| Syslog | System logging for centralized log collection |
+| IPFIX | IP Flow Information Export for flow telemetry |
+| HTTP-HTTPS | Software package downloads for system updates |
+| Audit | Audit event forwarding for compliance logging |
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Remove `management: true` from the interface | Per-interface | Prevents MOFI service generation for that interface |
+| Disable management services in authority config | Authority | Prevents generation globally (if supported) |
+| Set `generated` to `false` on a MOFI service or route | Per-element | Takes ownership of that element |
+
+:::note
+MOFI services are generated with the lowest priority to ensure they don't override user-configured services with the same names. Pre-provisioning a service with the same name before generation will prevent the auto-generated version from being created.
+:::
+
+
+#### BGP Services and Service-Routes
+
+The BGP subsystem automatically establishes reachability to BGP peers, enabling dynamic routing protocol operation and network convergence without manual service definition.
+
+| Field | Description |
+|---|---|
+| **Trigger** | BGP neighbor transport configuration |
+| **What is generated** | BGP peering _service_ and _service-route_ objects for BGP neighbor reachability |
+| **Category** | Leaf-only |
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Set `bgp-service-generation > disabled` | Per-BGP-neighbor | Fully prevents generation for that neighbor |
+| Set `bgp-service-generation > service-policy` | Per-BGP-neighbor | Override the generated _service-policy_ |
+| Set `bgp-service-generation > security-policy` | Per-BGP-neighbor | Override the generated security policy |
+| Set `bgp-service-generation > route-reflector-client-mesh` | Authority | Generate service-route mesh for route reflector clients |
+| Set `generated` to `false` on a BGP service | Per-element | Takes ownership of that service |
+
+You can fully disable BGP service generation on a per-neighbor basis using the `disabled` option.
+
+
+#### DHCP Server KNI Device-Interfaces
+
+The DHCP server subsystem automatically provisions kernel network interfaces required for DHCP server operation, handling the internal networking plumbing transparently.
+
+| Field | Description |
+|---|---|
+| **Trigger** | `host-service` of type `dhcp-server` configured on a _network-interface_ |
+| **What is generated** | KNI _device-interface_ objects for DHCP server operation |
+| **Category** | Leaf + metadata |
+
+| Setting | Level | Effect |
+|---------|-------|--------|
+| `dhcp-server-generated-address-pool` | Authority (`application-identification`) | Changes the address pool for generated KNI interfaces (default: `169.254.130.0/24`). |
+| `override-generated true` on the KNI interface | Per-element | Takes ownership of that element. |
+
+There is no flag to fully disable DHCP KNI generation. Remove the `dhcp-server` host-service to prevent generation.
+
+
+#### DHCP Relay Services and Routes
+
+The DHCP relay subsystem automatically provisions the DHCP relay service and reachability paths to DHCP servers, enabling DHCP client support on networks without a local DHCP server.
+
+| Field | Description |
+|---|---|
+| **Trigger** | DHCP relay agent configured on a _network-interface_ |
+| **What is generated** | DHCP relay _service_ and _service-route_ objects |
+| **Category** | Leaf-only |
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Remove DHCP relay configuration | Per-interface | Prevents generation |
+| Set `generated` to `false` on the service or route | Per-element | Takes ownership of that element |
+
+
+#### Application Identification (App-ID) Services
+
+The App-ID subsystem automatically creates granular service categories for application identification, allowing fine-grained traffic classification and policy enforcement without manual service creation.
+
+| Field | Description |
+|---|---|
+| **Trigger** | `generate-categories` set to `true` on a _service_ |
+| **What is generated** | Category-based child _service_ objects under the parent service |
+| **Category** | Leaf-only |
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Set `generate-categories` to `false` (default) | Per-service | Prevents category-based child service generation |
+| Set `application-identification` to `disabled` | Per-service | Disables app-id entirely for that service |
+
+The default is `false` (disabled). Category services are only generated when explicitly opted-in.
+
+
+#### PIM Multicast Services and Routes
+
+The PIM subsystem automatically establishes reachability for Protocol Independent Multicast (PIM) control traffic, enabling multicast routing operation across the network.
+
+| Field | Description |
+|---|---|
+| **Trigger** | PIM routing configured on a router |
+| **What is generated** | PIM multicast _service_ and _service-route_ objects |
+| **Category** | Leaf-only |
+
+No independent disable flag. Remove the PIM configuration to prevent generation. Set `generated` to `false` per-element to take ownership.
+
+
+#### MSDP Services and Routes
+
+The MSDP subsystem automatically provisions Multicast Source Discovery Protocol (MSDP) peering connectivity, enabling inter-domain multicast source discovery and reachability.
+
+| Field | Description |
+|---|---|
+| **Trigger** | MSDP routing configured |
+| **What is generated** | MSDP peering _service_ and _service-route_ objects |
+| **Category** | Leaf-only |
+
+No independent disable flag. Remove the MSDP configuration to prevent generation. Set `generated` to `false` per-element to take ownership.
+
+
+#### Plugin-Generated Elements
+
+Plugins extend the platform by automatically generating plugin-specific services, routes, and configuration elements as needed.
+
+| Field | Description |
+|---|---|
+| **Trigger** | Varies by plugin. |
+| **What is generated** | Plugin-specific services, routes, and other configuration. |
+| **Category** | Leaf + metadata. |
+
+Use `override-generated true` on any plugin-generated element to take ownership.
+
+---
+
+### Infrastructure and System Configuration
+
+This section covers auto-generated configuration managed by the platform for internal operations. Most users do not need to interact with or override these settings.
+
+#### Software Update Proxy
+
+The software update subsystem automatically configures internal proxy settings for software updates on managed routers, ensuring seamless update delivery without manual configuration. This is a hidden, internally managed setting. It is unconditionally set when managed routers exist. There is no opt-out mechanism and no override is available.
+
+
+#### Secure Conductor Onboarding (SCO)
+
+The SCO subsystem automatically manages the secure onboarding mode for routers and configures pre-shared keys (PSK) required for secure conductor communication. This enables secure, automated onboarding of managed routers without manual key management.
+
+| Field | Description |
+|---|---|
+| **Trigger** | Routers with `system/secure-conductor-onboarding/mode` configured |
+| **What is generated** | SCO operating mode (EXCLUSIVE or DISABLED) and pre-shared keys for routers |
+| **Category** | Leaf-only |
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Set `secure-conductor-onboarding > mode` to `disabled` | Per-router | Disables SCO for that router |
+| Set `secure-conductor-onboarding > mode` to `exclusive` | Per-router | Enables SCO and triggers PSK generation |
+
+:::note
+SCO operates at the system level and is automatically managed based on the configured operating mode. PSKs are only generated when SCO is enabled and are required for the conductor to authenticate the router.
+:::
+
+
+#### Resource Groups
+
+The Resource Groups subsystem automatically associates configuration resources (routers, services, tenants, security profiles, etc.) with role-based access control (RBAC) resource groups. This enables policy enforcement for resource group-scoped access controls without manual resource enumeration.
+
+| Field | Description |
+|---|---|
+| **Trigger** | Configuration resources exist in the authority; roles define resource groups. |
+| **What is generated** | Resource entries in roles linking to configuration objects. |
+| **Category** | Leaf-only |
+
+Supported resource types include:
+- Network elements (routers, districts).
+- Services and traffic policies (services, service-classes, traffic-profiles).
+- Security and access (tenants, security profiles, LDAP servers).
+- Operational configuration (alarm shelves, performance profiles, DSCP maps, IPFIX collectors).
+- Extensibility (STEP repos, PCLI aliases, session-types).
+
+| Method | Scope | Effect |
+|--------|-------|--------|
+| Pre-provision resources with specific names | Per-resource | System detects them and skips auto-generation |
+| Set `generated` to `false` on a resource entry | Per-element | Takes ownership of that resource entry |
+
+:::note
+Resource groups are generated with lowest priority; user-provisioned resources with matching names prevent auto-generation. This enables administrators to define custom resource mappings when needed.
+:::
+
+
+#### Alarm Shelving
+
+The alarm shelving subsystem automatically manages alarm suppression (shelving) based on internal platform logic, suppressing non-critical alarms during expected operational conditions.
+
+| Field | Description |
+|---|---|
+| **Trigger** | Internal alarm shelving logic |
+| **What is generated** | Alarm shelf entries |
+| **Category** | Leaf-only |
+
+Set `generated` to `false` per-element to take ownership.
+
+
+#### Internal Tenants
+
+The platform automatically provisions internal logical containers (tenants) for services and features that require tenant isolation without burdening users with these internal details.
+
+| Field | Description |
+|---|---|
+| **Trigger** | Conductor services, BGP, or other internal features are active. |
+| **What is generated** | Internal tenants such as `_internal_`, `_bgp_speaker_`. |
+| **Category** | Leaf-only |
+
+:::warning
+These tenants are required for the platform to function. Setting `generated` to `false` is technically possible but **not recommended** — it may impact platform functionality.
+:::
+
+
+#### Auto-Generated IDs
+
+The platform automatically assigns unique identifiers to configuration elements when not explicitly provided, ensuring all config elements have required IDs without manual assignment. This is a fundamental platform requirement. It cannot be disabled or overridden.
+
+---
+
+## Protection Mechanisms in Detail
+
+This section provides deeper technical detail on how the two mechanisms interact. Most users can rely on the guidance above — the PCLI shows the correct command automatically.
+
+### The `generated` Leaf
+
+Every auto-generated element has a `generated` boolean:
+- `generated true` — element is collected for removal during commit and regenerated
+- `generated false` — element is skipped during both removal and regeneration
+
+### The Authority Metadata Tracking List
+
+A hidden list at `authority > generated` tracks elements created by certain subsystems. Each entry has a `persistent` flag:
+- `persistent false` (default) — the element's path is collected for removal
+- `persistent true` — the path is retained and NOT collected for removal
+
+### Interaction Matrix
+
+| State | Removed? | Regenerated? | Assessment |
+|-------|:--------:|:------------:|------------|
+| `generated true`, no metadata. | Yes (leaf) | Yes | Normal leaf-only behavior |
+| `generated false`, no metadata. | No | No | **Safe** — fully protected |
+| `generated true`, metadata `persistent false`. | Yes (both paths) | Yes | Normal metadata-tracked behavior |
+| `generated false`, metadata `persistent false`. | Yes (metadata) | May be | **Unsafe** — metadata removal still deletes it |
+| `generated false`, metadata `persistent true`. | No | No | **Safe** — what `override-generated true` sets |
+| `generated true`, metadata `persistent true`. | Yes (leaf) | Yes | **Unsafe** — leaf removal still deletes it |
+
+### PCLI Visibility
+
+The `generated` leaf and `override-generated` command are mutually exclusive in the PCLI:
+- If a metadata entry exists → `generated` leaf is hidden; `override-generated` is shown.
+- If no metadata entry exists → `generated` leaf is visible; `override-generated` is hidden.
+
+## Import/Export Behavior
+
+The `export config` and `import config` PCLI commands save and restore the full configuration to/from a GZIP-compressed XML file on disk (stored in `/etc/128technology/config-exports/`).
+
+Both the `generated` leaf on individual elements **and** the `authority > generated` metadata list are **fully preserved** during export and import. The export serializes the entire configuration tree without filtering.
+
+This means:
+- All auto-generated elements, their `generated` boolean values, and any `override-generated` state survive a round-trip export/import.
+- The `authority > generated` metadata entries (including `persistent` flags) are included.
+- The configuration behaves identically after import — the same PCLI commands are available, and the same override protections are in effect.
+- Elements with `generated true` will still be removed and re-generated on the next commit after import.
+- Elements previously overridden (`generated false` or `persistent true`) remain protected.
+
+## Quick Reference
+
+### User-Facing Configuration
+
+| Element | Dedicated Disable Option | Per-Element Override |
+|---------|-------------------------|---------------------|
+| Peer Topology builder service-routes. | `share-service-routes false` | `generated false` |
+| Peer Topology builder peers/adjacencies. | Remove _neighborhood_ | `generated false` |
+| Conductor services | No (customization knobs only) | `generated false` |
+| MOFI services (NTP, DNS, SNMP, etc.). | Remove `management: true` from interface | `generated false` |
+| BGP services | `bgp-service-generation > disabled` | `generated false` |
+| DHCP relay services. | Remove relay config | `generated false` |
+| DHCP server KNI interfaces. | Remove `dhcp-server` host-service | `override-generated true` |
+| App-ID category services. | `generate-categories false` (default) | `generated false` |
+| PIM/MSDP services | Remove routing config | `generated false` |
+| Plugin-generated elements | Varies by plugin | `override-generated true` |
+
+### Infrastructure and System Configuration
+
+| Element | Dedicated Disable Option | Per-Element Override |
+|---------|-------------------------|---------------------|
+| Secure Conductor Onboarding (SCO) | Set `mode` to `disabled` | Not typically overridden |
+| Resource Groups | Pre-provision resources | `generated false` |
+| Internal tenants | No | `generated false` (not recommended) |
+| Software-update proxy | No | Not available |
+| Auto-generated IDs | No | Not available |
diff --git a/sidebars.js b/sidebars.js
index 2448b5b239..aab0d8075e 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -125,7 +125,7 @@ module.exports = {
       "initialize_u-iso_device",
       "initialize_u-iso_adv_workflow",
       "sec-ztp-web-proxy",
-      "sec-conductor-onboard", 
+      "sec-conductor-onboard",
     ],
     "Cloud / Hypervisor Installations": [
       "supported_cloud_platforms",
@@ -232,6 +232,7 @@ module.exports = {
         "label": "Administration",
         "items": [
           "config_basics",
+          "config_autogenerated",
           "config_templates",
           "howto_local_config_override",
           "config_RBAC",
@@ -376,10 +377,10 @@ module.exports = {
           "sec_hardening_guidelines",
           "sec_security_policy",
           "sec_adaptive_encrypt",
-          "sec_firewall_filtering",  
-          "concepts_tpm",        
-          "sec-config-seim-syslog",          
-          "sec-ddos-resilience",          
+          "sec_firewall_filtering",
+          "concepts_tpm",
+          "sec-config-seim-syslog",
+          "sec-ddos-resilience",
           "sec-usb-security",
           "sec-secure-boot",
           "concepts_config_integrity",
@@ -388,8 +389,8 @@ module.exports = {
           "config_custom_certs",
           "sec-cert-based-encrypt",
           "cert_validation_requirements",
-          "sec_enhanced_key_mgmt", 
-          "config_factory_reset",         
+          "sec_enhanced_key_mgmt",
+          "config_factory_reset",
         ],
       },
       {