> ## 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.

# Cnsf

# Doc Type: CNSF

> **Tier**: Concepts & Architectures | **Reader phase**: Understanding\
> **Back to tier overview**: [concepts-architectures/index.md](index.md)

***

## What it is

The CNSF (Cloud Native Security Fabric) document is the **single strategic anchor** for the entire Concepts & Architectures tier. It articulates the CNSF framework: the vision, the problem it addresses, how it works, and why it is different. There is **one CNSF document**, not a family of them.

This is not a product feature description and not a how-to guide. It is a conceptual framework document that establishes shared vocabulary and strategic context for every other document in the tier.

***

## Goal

After reading the CNSF document, the reader understands why Aviatrix exists as a platform, what business and operational problems it is designed to solve, and how it positions against the alternatives. They leave with the strategic context and shared vocabulary needed to evaluate Aviatrix, align stakeholders, and navigate the rest of the documentation with purpose.

***

## Primary personas

| Persona | How they use it |
| - | - |
| **Architect** | Understands the framework before designing solutions |
| **Technical Manager** | Builds the business case and alignment narrative |
| **Engineer** | Gains the conceptual foundation before diving into components |

***

## When to update (not create)

There is only one CNSF document. Create a new one only if the product strategy shifts significantly enough to warrant retiring the existing document. Otherwise, update it in place. A content update is warranted when:

* A new major capability changes the scope of the framework
* The strategic narrative evolves (e.g., a new accelerant like GenAI becomes central)
* Measurable outcomes or business positioning data needs refreshing

***

## Required sections

These sections must appear in every CNSF document, in this order:

1. **What is CNSF?** — A plain-language definition in 3–5 sentences. No jargon or assumed knowledge. Answer: what it is, what it does, and who it is for.
2. **The Vision** — The long-term strategic direction. What does success look like at scale? This section may be aspirational but must be grounded in product reality.
3. **The Problem CNSF Solves** — A clear articulation of the market/customer pain this addresses. Use concrete framing: what breaks, what costs what, what is at risk. Use a `<CardGroup>` to highlight 3–5 distinct problem dimensions.
4. **Why CNSF is Different** — How Aviatrix's approach differs from alternatives. Avoid vague superlatives. Use specific, verifiable differentiators.
5. **Core Capabilities** — A structured list of capabilities the framework delivers. Each capability gets its own H3 with a 2–4 sentence explanation. Avoid feature lists — explain what the capability *enables*, not what the product *does*.
6. **How CNSF Works** — A concise walkthrough of the operational model. Use a `<Steps>` component. This is conceptual, not a configuration guide.
7. **Measurable Outcomes** — Quantified business impact. Use a `<CardGroup>`. Metrics should be defensible — cite sources or note that figures are representative of customer results.
8. **Key Solutions** — A brief ordered list linking out to the Solution documents. This section is navigational.
9. **Learn More** — Navigation links aimed primarily at Solution documents. Secondary links to Architectures and Guides are appropriate when a reader is ready to go deeper on a specific pattern or workflow.

***

## Optional sections

* **CNSF in the Security Ecosystem** — Positioning within broader industry frameworks (e.g., Zero Trust, NIST, CNSF alignment)
* **The Technology Accelerants** — If external forces (e.g., AI adoption, Kubernetes proliferation) create urgency, a section articulating that urgency is appropriate
* **Zero Trust / Framework Alignment** — Cross-references to recognized security or networking frameworks

***

## Tone & voice

**Strategic and principled.** Write for a technically literate reader who may not yet know Aviatrix. Avoid assuming product knowledge. Use first principles reasoning. The tone should feel like a well-considered position paper — confident, clear, and non-promotional. Avoid marketing superlatives ("world-class," "industry-leading").

**Concrete over abstract.** Every claim should be supported by a specific consequence, outcome, or mechanism. "CNSF provides visibility" is too vague; "CNSF provides a unified control plane that gives operators visibility into traffic across all clouds from a single dashboard" is better.

***

## Length guidance

**200–350 lines.** Long enough to be substantive, short enough to read in one sitting. If the document grows beyond 400 lines, consider whether a section belongs in a separate Solution or Architecture document.

***

## Frontmatter

See [Frontmatter Standards](../frontmatter.md) for field definitions and formatting rules.

The title is fixed: `Cloud Native Security Fabric (CNSF)`.

```yaml theme={null}
---
title: "Cloud Native Security Fabric (CNSF)"
description: "An overview of Aviatrix's Cloud Native Security Fabric framework — the vision, core capabilities, and the problems it solves."
---
```

***

## Mintlify components

See [Style Guide](../style-guide.md) for component definitions and usage rules.

CNSF is primarily prose — minimize component use to keep the narrative linear. Use `<Note>` for strategic callouts the reader must not skip and `<Tip>` for navigational hints. Avoid `<Tabs>` and `<Accordion>`.

***

## Snippet usage

Content shared with enterprise documentation should be extracted into a snippet under `/snippets/enterprise/CNSF/`. The CNSF index page imports the snippet rather than containing the content directly. **Do not duplicate content** — edit the snippet, not the page.

***

## Dos and don'ts

| Do | Don't |
| - | - |
| Use concrete outcomes and metrics | Use vague superlatives without evidence |
| Link out to Solutions for specific problem scenarios | Explain how to configure anything |
| Keep the document narrative (prose-first) | Turn it into a feature list or bullet dump |
| Update in place when the strategy evolves | Create multiple CNSF documents |
| Validate metrics with PMM or Solutions Engineering before publishing | Invent or estimate customer impact figures |


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