> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guides

# Guides — Content Standards

> **Tier**: Guides | **Reader phase**: Configuring and Operating

***

## What This Tier Is For

The Guides tier covers the **Configuring and Operating** phase of the reader journey. Documents here answer: *How do I set this up, and how do I keep it running?*

Unlike the Concepts & Architectures tier (which explains what things are and why), and the Reference tier (which documents specifics), Guides are procedural — they take a reader from a defined start state to a defined end state, step by step.

***

## How the Two Types Relate

```
Configuration Guides ──► Operational Guides
(set it up)                (keep it running, fix it, upgrade it)
```

A reader who has followed a Configuration Guide to set up a feature will turn to an Operational Guide when they need to upgrade it, troubleshoot it, or perform routine maintenance on it.

***

## Document Types

| Type | One-line definition | File |
| - | - | - |
| **Configuration Guide** | Step-by-step procedure for configuring a feature via UI, Terraform, or API | [configuration-guide.md](configuration-guide.md) |
| **Operational Guide** | Procedure for upgrading, troubleshooting, or maintaining Aviatrix in production | [operational-guide.md](operational-guide.md) |

***

## Cross-Cutting Standards

The following standards apply to **all document types** in this tier.

### Prerequisites are mandatory

Every guide must open with a prerequisites section before any procedural steps. Configuration and Troubleshooting Guides use a **Prerequisites** heading. Upgrade Guides use **Before You Begin** to also cover backups, health checks, and rollback options. The label differs but the requirement does not — readers who arrive without the required context waste time, and may cause production incidents if they skip steps. Never assume the reader has what they need.

### Imperative mood for every action step

Every step that requires the reader to do something must use imperative mood: "Click **Save**", "Set the **Gateway Size** to...", "Run the following command:". Never describe an action as an observation ("The user should click Save").

### UI element names are always bold

Bold every UI label, button, field name, field value, toggle, and menu item exactly as it appears in the product. Use the `>` separator for navigation paths: `CoPilot > Cloud Fabric > Gateways`.

### Verification is required where possible

Every guide should tell the reader what success looks like. If there is a meaningful way to confirm the procedure worked — a UI state to check, a CLI output to verify, a Terraform plan to review — include it.

### Frontmatter

All documents require `title`, `description`, and `keywords` in frontmatter.

```yaml theme={null}
---
title: "[Verb] [Feature or Component]"
description: "How to [verb] [feature] in Aviatrix — covering prerequisites, procedure, and verification."
---
```

### What does NOT belong in this tier

| Content | Where it belongs |
| - | - |
| Explanations of what a feature does or why | Component docs (Concepts & Architectures tier) |
| Architecture design decisions and trade-offs | Architecture docs (Concepts & Architectures tier) |
| Field-level UI descriptions | CoPilot UI Reference (Reference tier) |
| Resource attribute reference | Terraform or API Reference (Reference tier) |
| Release change history | Release Notices (Reference tier) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.