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

# How Root Works

> The Root adoption journey - from discovering what you use to continuously consuming secured artifacts.

Root's adoption model is designed to be easy to start and easy to maintain. There are no complex migrations and no breaking changes. The journey follows four stages.

## The Adoption Journey

<Steps>
  <Step title="Discovery">
    Root identifies which images and libraries your organization is currently using. This gives you a complete picture of your open source footprint and its current vulnerability exposure before you change anything.
  </Step>

  <Step title="Subscription">
    You subscribe to Root's secured equivalents for the images and packages in your inventory. Subscriptions are per-project - you choose what Root secures, and you stay in control.
  </Step>

  <Step title="Consumption">
    Point your Dockerfiles and package managers at Root's registries. Pull and install exactly as you do today - the difference is that every artifact has already been through Root's AVR pipeline.
  </Step>

  <Step title="Maintenance">
    Root monitors every subscribed artifact continuously. When a new CVE is published, AVR kicks in automatically - research, patch, test, deliver - and a patched version is available at Root's registries before your next pull or install.
  </Step>
</Steps>

## Root's Two Registries

| Registry             | Endpoint      | What it serves                |
| -------------------- | ------------- | ----------------------------- |
| Root Image Catalog   | `cr.root.io`  | Patched container base images |
| Root Library Catalog | `pkg.root.io` | Patched application packages  |

Both registries are fully compatible with their upstream equivalents. No tooling changes are required.

## The AVR Pipeline

Every artifact in Root's registries has passed through AVR - Root's Agentic Vulnerability Remediation pipeline. When a new CVE is published, AVR automatically:

1. **Scans and detects** - ingests the CVE within seconds, identifies affected components
2. **Builds a remediation plan** - research agents analyze the vulnerability, locate upstream fixes, and assess compatibility
3. **Applies the fix** - patching agents backport the fix to the exact version you're running, preserving compatibility
4. **Tests and validates** - the patch is verified against package tests, functional tests, and CVE-specific regression tests
5. **Delivers** - the secured artifact is published to Root's registries with updated SBOM, VEX, and provenance attestation

See [AVR](/concepts/avr) for the full technical breakdown.

## No Code Changes Required

Root acts as a transparent registry. Package names, version numbers, tags, and APIs are identical to their upstream equivalents. You don't update dependency files, lockfiles, or application code.

## Transparency by Default

Every artifact Root delivers includes:

* **SBOM** - a complete inventory of all components, including what was patched
* **VEX statement** - which vulnerabilities were fixed and why the fix can be trusted
* **Provenance attestation** - cryptographic proof of how and when Root built the artifact

These are available via the Root platform, the API, and as OCI annotations on images.

<CardGroup cols={2}>
  <Card title="Root Image Catalog" icon="container-storage" href="/ric/overview">
    Get started with secure container images.
  </Card>

  <Card title="Root Library Catalog" icon="package" href="/rlc/overview">
    Get started with secure application packages.
  </Card>
</CardGroup>