config-atlas/docs/ecosystem-boundaries.md

Ecosystem Boundaries & Reuse — config-atlas among its sister repos

How config-atlas should tighten its responsibility boundaries and reuse existing concepts/functionality from five sister repos rather than reinventing them. Drafted 2026-06-26. Companion to INTENT.md, SCOPE.md, ArchitectureBlueprint.md, and .claude/rules/repo-boundary.md.

---

1. The one-sentence boundary for each repo

Repo	Owns	config-atlas relationship
info-tech-canon	The shared vocabulary: canonical concepts, models (Governance, Data, DevSecOps, Landscape, Access), mappings, patterns. Markdown-first semantic operating layer.	Consume, don't redefine. Map config-atlas terms (surface, scope/layer, kind, mutability, effective config, evidence) to ITC concepts.
repo-scoping	Turning repos into source-linked maps via deterministic scanners + optional LLM candidates + human approval. Hierarchy Scope→Ability→Capability→Feature→Evidence→Fact.	Reuse the machinery. config-atlas "connectors" are repo-scoping's scanner→candidate→approval pipeline, specialized to config surfaces.
domain-tree	Organizational backbone: primary domain placement + secondary bindings for repos, services, users, datasets, policies. Identity-stable domains.	Reference for ownership/placement. A surface's owner/domain should resolve to domain-tree bindings.
reuse-surface	The capability registry model, entry schema, validation CLI, and federation hub. Maturity vectors (D/A/C/R).	Federate under it. config-atlas is a federated registry peer; its surface entry is a typed sibling of the capability entry. (Already reused.)
feature-control	The runtime feature-availability control plane: OpenFeature integration, multi-scope decisions, resolver, kill switches, audit.	Hard delegation boundary. config-atlas maps feature flags as one config kind and links to feature-control as the authority; it never resolves or controls them.

The clean north: config-atlas is read-first cartography across all config kinds; each adjacent repo owns one authoritative slice that config-atlas points at.

---

2. Overlap hotspots and how to resolve them

These are the places where config-atlas, as currently written, risks redefining or rebuilding something a sister repo already owns.

2.1 "Control plane" + scope model + resolver + kill switches — vs feature-control

The sharpest overlap. Both repos use control plane language, both define a scope model, both talk about effective decision / resolver and kill switches. feature-control already enumerates scopes (platform, installation, environment, deployment, vendor, tenant, domain, organization, group, user, service, repository, agent) and its own out-of-scope explicitly forbids "becoming a generic configuration database for unrelated application settings" — which is exactly config-atlas's job. The boundary is therefore mutually reinforcing if stated crisply:

• feature-control = runtime control plane for one kind (feature availability), write/runtime, OpenFeature-native, owns the feature resolver.
• config-atlas = read-only map/evidence atlas across all kinds, references feature-control's flags and resolver rather than re-deriving them.

Action: config-atlas must not ship a runtime resolver (already deferred in the blueprint — restate it as a hard boundary against feature-control specifically). The feature-flag kind entries should carry a sources[] link to the feature-control key, not duplicate its rules. Drop independent "kill switch" language from config-atlas — that is feature-control's Kill Switch concept.

2.2 The scope/layer taxonomy — vs feature-control + InfoTechCanon

config-atlas defines L0–L9 layers; feature-control defines its scope list; InfoTechCanon owns Governance/Landscape/Org concepts underneath both. Three independent scope vocabularies is exactly the "integration by interpretation" that InfoTechCanon exists to prevent.

Action: Adopt one shared scope vocabulary grounded in InfoTechCanon and already qualified by feature-control's EvaluationScope. Express config-atlas's L0–L9 as an ordering over that shared vocabulary, not a new set of names.

2.3 Concept ownership — vs InfoTechCanon

config-atlas's research/blueprint introduce kind, mutability class, merge semantics, security_class, effective configuration, evidence. Several of these already have ITC homes (Governance: policy/decision/evidence; DevSecOps: delivery/mutability; Data: schema/contract/classification).

Action: Add docs/canon-mapping.md mirroring feature-control's pattern — entity/relationship tables stating which terms config-atlas consumes from ITC (ITC-GOV, ITC-DATA, ITC-DEVSECOPS, ITC-LAND) vs owns (the configuration-surface entry, layering order, the cross-kind map itself). Propose any genuinely new terms (e.g. "configuration surface", "effective-config path") to ITC as extensions.

2.4 Discovery connectors — vs repo-scoping

The blueprint's §4 connectors (read-only scanners emitting candidate entries for PR review) reproduce repo-scoping's deterministic-scanner + candidate-graph + approve→registry-truth workflow and its source-linked evidence hierarchy.

Action: Reuse, don't rebuild. Two viable shapes:

• (a) Consume repo-scoping facts — config-atlas reads repo-scoping's observed facts/evidence as connector input, adding only the config-surface classification.
• (b) Extend repo-scoping with config-surface scanners, and have config-atlas curate/federate the results. Either way, the candidate→approval→truth state machine and the Evidence→Fact provenance model come from repo-scoping. config-atlas adds the config-kind + layer semantics on top.

2.5 Ownership & relationships — vs domain-tree + State Hub

config-atlas entries carry owner and cross-repo relations (consumed_by, depends_on_secret). domain-tree owns primary/secondary resource→domain bindings; the State Hub owns workstream/relationship records.

Action: owner/placement should resolve to domain-tree bindings (reference an identity, don't restate org structure). Config-typed edges go to the State Hub graph (already the blueprint's §5 decision). config-atlas stores the config semantics of the edge; domain-tree/State Hub store identity and topology.

2.6 Registry entry schema & federation — vs reuse-surface

Already reused (the surface-entry schema is modeled on the capability entry, and validation runs through reuse-surface validate). The open question is whether a configuration surface is its own federated entry type or a capability kind.

Action: Treat the configuration-surface entry as a typed sibling under reuse-surface's federation (its own schema, federated by the same hub), not a new federation mechanism. Confirm the entry id namespace (surface.*) is reserved in the reuse-surface federation roster so the two registries don't collide.

---

3. Tightened boundary statement (proposed for repo-boundary.md)

config-atlas owns the read-only, cross-kind configuration map and evidence layer. It does not own:

• the configuration vocabulary (→ info-tech-canon; map, don't redefine);
• repository scanning / candidate / approval machinery (→ repo-scoping; reuse);
• domain placement and ownership identity (→ domain-tree; reference);
• the registry schema & federation hub (→ reuse-surface; federate under it);
• the runtime resolution & control of feature availability, incl. resolver and kill switches (→ feature-control; link, never re-derive);
• secret values (→ OpenBao; reference only);
• the State Hub graph/identity store (→ State Hub; contribute config-typed edges).

---

4. Concrete reuse actions (maps onto the blueprint roadmap)

Action	Reuses	Blueprint phase
Add docs/canon-mapping.md (consumed vs owned terms)	info-tech-canon	Phase 0 (Canon)
Express L0–L9 as an ordering over the shared ITC/feature-control scope vocab	info-tech-canon, feature-control	Phase 0
Reserve surface.* id namespace + validate via reuse-surface	reuse-surface	Phase 0–1
Source connectors from repo-scoping facts (option a) instead of bespoke scanners	repo-scoping	Phase 2
Resolve owner to domain-tree bindings; push config edges to State Hub	domain-tree, State Hub	Phase 2–3
feature-flag entries link to feature-control keys; no local resolver/kill-switch	feature-control	Phase 3

Net effect: config-atlas keeps only its genuinely novel core — the cross-kind configuration-surface classification, the layering order, and the effective-config path rendering — and borrows vocabulary, scanning, ownership, schema/federation, and runtime control from the four repos that already own them.