config-atlas/INTENT.md

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/