# INTENT — config-atlas

> Repository purpose and boundary. Governance file for agents and contributors.

## One-liner

Federated configuration atlas for the Coulomb ecosystem — cataloging configuration
surfaces, schemas, defaults, ownership, and cross-repo relationships, and the
research backing a **Configuration Control Plane**.

## Purpose

`config-atlas` exists because configuration knowledge is scattered across repos,
deployment manifests, environment variables, feature flags, policy files, and
operator runbooks. Without a shared atlas, agents and humans rediscover the same
configuration surfaces repeatedly and cannot reason confidently about defaults,
precedence, or ownership.

The atlas treats each **configuration surface** as a first-class, registry-backed
entry: what it configures, where it lives, who owns it, how it is validated, and
which capabilities or repos consume it.

## North star

The registry is the near-term, concrete expression of a larger thesis: configuration
is *distributed control information* — the live mechanism that changes how systems
behave — and a company needs to **see** that surface before it can govern it. The
guiding product framing (`wiki/`) is a **Configuration Control Plane**:

> ConfigAtlas is not where all configuration must live. It is where configuration
> becomes visible, explainable, governable, and safe to change.

The pipeline that vision implies — Canon → Registry → Resolver → Policy → Delivery →
Evidence — is documented in `research/configuration-control-plane.md`. This repo
owns the **map and evidence layers** (registry, relationships, research). It does
not own resolution, delivery, or control execution.

## Core stance

- **Discoverable over tribal knowledge** — if a configuration surface matters to
  reuse or operations, it should be indexed here or linked from here.
- **Source-linked** — atlas entries point at canonical files or APIs; the atlas
  does not become a second source of truth for live config values.
- **Effective configuration is the goal** — the registry exists to make the
  resolved, layered value discoverable and explainable, not just to list files.
- **Map before control** — read-first configuration intelligence (discover,
  classify, attribute ownership) precedes any write-first control ambition.
- **Agent-friendly** — markdown and YAML registry formats that coding agents can
  orient from without bespoke tooling.
- **Federated** — downstream repos remain authoritative for their own config; this
  repo aggregates indexes, relationships, and documentation.

## In Scope

- Configuration surface registry (schemas, indexes, capability entries)
- Cross-repo configuration relationship maps (consumes, overrides, extends)
- The scope, precedence, and merge-semantics model for layered configuration
- Research and competitive analysis backing the control-plane thesis (`research/`,
  `wiki/`)
- Documentation of discovery, contribution, and validation workflows
- State Hub workplans and agent instructions for atlas maintenance

## Out of Scope

- Storing secret values or live environment-specific configuration
- A runtime configuration resolver, delivery engine, or control/push-pull plane
- Owning application runtime or deployment execution
- Replacing repo-local configuration files or secret stores (OpenBao, etc.)
- Acting as the canonical repo template (`repo-seed` owns that)

## Current State

- Bootstrapped from `repo-seed` on 2026-06-26; State Hub registration complete.
- Identity files customized; bootstrap workplan ATLAS-WP-0001 complete.
- Gitea wiki mirrored into `wiki/`; control-plane research digest added in
  `research/` (2026-06-26).
- Registry still carries inherited template artifacts — see ATLAS-WP-0002.

## Getting Oriented

- Boundary: `SCOPE.md`
- Product framing: `wiki/ProductVision.md`, `wiki/ConfigLayering.md`
- Research: `research/configuration-control-plane.md`
- Agent instructions: `AGENTS.md`
- Workplans: `workplans/`
- Registry: `registry/`
</content>