### 2.1 Integration Health The platform's integration layer is currently non-functional: **zero of 74 defined relationships** are join-viable, leaving every table operationally isolated despite a schema that anticipates extensive cross-table analysis. All 74 relationships suffer from broken foreign keys or insufficient coverage, blocking fundamental telemetry workflows such as tracing LLM call costs back to specific analysis runs, linking column profiling results in `columns_catalog` to their parent datasets in `datasets`, or connecting job execution logs in `job_logs` to batch processing records in `batches`. While five relationships—including `analysis_run_llm_usage.jobs_id → analysis_runs.jobs_id` and `tables_catalog.dataset_id → datasets.dataset_id`—have been validated as structurally sound, none meet the coverage or integrity thresholds required for production analytics, effectively preventing end-to-end visibility across the telemetry pipeline. ### 2.2 Key Integration Points | Source Table | Target Table | Relationship | Status | |--------------|--------------|--------------|--------| | *No viable joins detected* | — | — | — | The absence of reliable integration points means that even validated relationships remain unusable for business intelligence. Critical telemetry questions—such as "What is the total LLM cost per dataset profiled?" or "Which batches generated the most column classification candidates?"—cannot be answered without manual data stitching, as the 1.5 million rows in `columns_catalog` cannot be reliably joined to the 43,853 classification tags in `column_tags` or upstream dataset metadata. ### 2.3 Risks & Recommendations The primary risk is **analytical blindness**: with no functioning joins, the platform cannot aggregate costs across `llm_calls` and `analysis_run_llm_usage`, trace lineage through `tag_lineage_edges`, or reconcile job execution state between `job_logs` and `analysis_runs`. The data team should immediately audit the five validated relationships to diagnose why coverage or integrity falls below thresholds—common culprits include orphaned records from incomplete batch processing, missing cascade deletes when jobs fail, or stale references in the 303,822-row `job_logs` table. Prioritize restoring the `datasets` hub first, as it anchors relationships for `tables_catalog`, `batches`, and `classification_overrides`, unlocking the majority of blocked telemetry workflows.