add-source-instance

name

add-source-instance

description

Onboard a new data-source INSTANCE (a new database/warehouse of an already-supported engine kind) into the federation — introspect its schema, emit its CSI + R2RML via r2g, enforce single-owner concept ownership, wire it into from_env, and add a golden. Use when adding a source such as a second Snowflake/Postgres database, a Databricks/MySQL instance, or any new relational/warehouse source whose engine already has an executor. NOT for adding a new engine kind (no executor exists yet) — that is `add-source-kind`.

Add a Source Instance (CSI + mapping + concept ownership + golden)

Onboard a new source of an already-supported kind — data and configuration, not code. The worked reference is Sprint 2 / WP-S3 (Snowflake telemetry): see deploy/snowflake/, deploy/csi/snowflake-telemetry.json, deploy/r2rml/snowflake_telemetry.ttl, and the snowflake branch in src/cdf/service/app.py::FederationService.from_env.

If the engine has no executor yet (no cdf.adapters.<engine> and no from_env branch for its kind), stop — run add-source-kind first, then return here.

Purpose

A source instance is legible to the fabric only when: its schema is mapped to the shared conceptual vocabulary (urn:arango-sparql:concept#), every concept it contributes is owned by exactly one source, its executor is wired from the environment, and a golden proves the join. This skill makes that repeatable and encodes the traps that cost real time.

Preconditions

• The engine kind already has an executor + a from_env branch (else add-source-kind).
• r2g is runnable (, v0.2.0 pinned — matches the committed artifacts' ). For a non-Postgres kind, does NOT work (PG-only); introspect via the Python API instead (Phase 2).