{
  "id": "page:docs-user-guide-ecosystem-atlas",
  "_kind": "Page",
  "_file": "wiki/docs/user-guide/ecosystem/atlas.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/user-guide/ecosystem/atlas.md",
    "sourceKind": "repo-docs",
    "title": "atlas — the catalog & knowledge graph",
    "displayName": "atlas — the catalog & knowledge graph",
    "slug": "docs/user-guide/ecosystem/atlas",
    "articlePath": "wiki/docs/user-guide/ecosystem/atlas.md",
    "article": "\n[Docs](../index.md) › [Ecosystem](./overview.md) › atlas\n\n# atlas — the catalog & knowledge graph\n\n**Package:** `@a5c-ai/atlas` · **CLI:** `atlas` (alias `a5c-atlas`) · **Version:** 6.0.0 · **Maturity:** GA\n\n**Atlas is the unified knowledge graph and catalog for the ecosystem. It is the single source of truth for harness metadata, discovery snapshots, plugin targets, host detection, and package/process topology — and it is what lets you add a harness as a *data change* rather than a code change.**\n\n---\n\n## On this page\n\n- [What it is](#what-it-is)\n- [How it works](#how-it-works)\n- [Why it matters for obedience](#why-it-matters-for-obedience)\n- [Entrypoints](#entrypoints)\n- [Who uses it](#who-uses-it)\n- [Next steps](#next-steps)\n\n---\n\n## What it is\n\nAtlas is described in its own package as the \"Atlas catalog graph data, SDK, and CLI.\" It is the unified knowledge graph / ontology / catalog that the rest of the stack reads from. Rather than hand-wiring harness facts into the runtime, those facts live in Atlas as data and are generated into types and snapshots.\n\n---\n\n## How it works\n\nThe pipeline is data-first:\n\n```\nYAML graph definitions  →  generated TypeScript types  →  JSON snapshots consumed at runtime\n```\n\n- **YAML graph definitions** describe the catalog (harnesses, plugin targets, topology).\n- Those compile to **generated TS types** so consumers get type safety.\n- And to **JSON snapshots** that the runtime reads directly.\n\nThe catalog runtime surface is exposed at `@a5c-ai/atlas/catalog`, with additional subpaths `./indexer` and `./graph-index`. An MCP endpoint is exposed through the Atlas WebUI (`/api/mcp`, Streamable HTTP).\n\n---\n\n## Why it matters for obedience\n\nA core v6 design principle is that \"every integration surface is defined once in a central catalog and multiplexed to N adapters or targets through generated code.\" Atlas *is* that central catalog. Because harness/plugin/discovery metadata is generated data, the [adapters](./adapters.md) family and the hooks lifecycle don't have to be re-coded per harness — they read Atlas. That keeps the enforcement layer consistent across every supported harness.\n\n---\n\n## Entrypoints\n\n| Surface | Detail |\n|---------|--------|\n| Bins | `atlas`, `a5c-atlas` |\n| Subpaths | `./catalog`, `./indexer`, `./graph-index` |\n| MCP | Exposed via the Atlas WebUI at `/api/mcp` (Streamable HTTP) |\n\nA quick taste of the CLI:\n\n```bash\n# Inspect the catalog the runtime will read\natlas --help\n```\n\n> Atlas CLI subcommands and flags are governed by the repository's CLI allowlist; consult `atlas --help` on your installed version for the authoritative, version-matched surface.\n\n---\n\n## Who uses it\n\nThe SDK, the adapters family, the hooks lifecycle, plugin tooling, and the Atlas WebUI all consume the catalog. In the [architecture](../architecture.md), Atlas sits beside the SDK and feeds the adapters/hooks/plugins layer with the metadata they need.\n\n---\n\n## Next steps\n\n- **See where it sits:** [Architecture & How It Fits Together](../architecture.md)\n- **See what it feeds:** [Adapters overview](./adapters.md) and the [Adapter Types reference](../reference/adapter-types.md)\n- **Ecosystem map:** [Ecosystem Overview](./overview.md)\n",
    "documents": []
  },
  "outgoingEdges": [],
  "incomingEdges": [
    {
      "from": "page:docs-user-guide",
      "to": "page:docs-user-guide-ecosystem-atlas",
      "kind": "contains_page"
    }
  ]
}