generated from coulomb/repo-seed
tegwick
9b89fc4026
Harmonize the federated-registry framing with the now-articulated control-plane north star. Add a North star section scoping this repo to the map and evidence layers (not resolution/delivery/control), two core stances (effective-configuration goal, map-before-control), sharpen in/out of scope, and record the wiki mirror, research digest, and ATLAS-WP-0001 completion. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
88 lines
3.9 KiB
Markdown
88 lines
3.9 KiB
Markdown
# 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>
|