Skip to main content

Aviatrix Documentation Content Standards

Status: In Progress — April 2026
Maintained by: Aviatrix Documentation Team

What This Is

This folder contains the content standards for the Aviatrix documentation platform. Standards are organized to mirror the documentation landscape: one subfolder per tier, one file per document type. Use these standards when:
  • Creating a new document and deciding what type it should be
  • Reviewing or editing existing content for structural consistency
  • Onboarding a new writer or contributing engineer
  • Evaluating whether content belongs in this tier or another

Documentation Landscape

The diagram below shows the three tiers and how documents link to each other. Solid arrows indicate primary reading paths. Dashed arrows indicate optional or reference links. Gray arrows indicate cross-tier navigation paths. Aviatrix documentation landscape diagram showing three tiers — Concepts & Architectures, Guides, and Reference — and the linking relationships between document types

Documentation Landscape Tiers


Start here

→ Which doc type should I use? — Decision table, question flow, and common mistakes. Start here if you are not sure which type fits your content. → Documentation Triggers — Reference table showing which documents are required or optional for each type of product change, including lifecycle stage modifiers (EA, Preview, GA).

Central standards

These documents apply to all doc types. Individual doc type definitions reference them rather than duplicating the content.

How doc type definitions are structured

Each document type definition answers the same set of questions:
  • What it is — a precise, scope-bounded definition of the type, including what it is not
  • Goal — what the reader should be able to do or decide after reading a document of this type
  • Primary personas — who reads this type and why
  • When to create one — explicit criteria to prevent doc sprawl
  • Required sections — ordered, with rationale for each
  • Optional sections — named patterns with conditions for including them
  • Tone & voice — guidance specific to the audience and purpose of the type
  • Length guidance — target ranges based on existing content
  • Frontmatter — doc-specific title format and template (see Frontmatter Standards for full field guidance)
  • Style notes — doc-specific component usage and restrictions (see Style Guide for full definitions)
  • Linking rules — inbound and outbound connections to maintain navigability
  • Dos and don’ts — quick-reference table for writers

Governance

  • Standards files are owned by the Documentation Team
  • Propose changes via PR against this folder
  • Significant changes (e.g., adding a new doc type, changing required sections) require review from at least one Solutions Engineer and one Technical Writer
  • Standards should be reviewed quarterly or after major product releases