What problem does it solve? Reconciling row counts between Google Cloud BigQuery (_kfkevh Bronze/Silver tables) and Azure Databricks Unity Catalog is error-prone because the two platforms use different timestamp semantics (broker enqueue time vs. payload StorageDate), causing false mismatches at hour boundaries and costly unpartitioned scans. ## Core Features & Use Cases - Canonical Parity Queries: Provides deduplicated BigQuery SQL templates using the 3-column _kfkevh key (_meta_namespace, _meta_partition_id, _meta_sequence_number) with mandatory partition pre-filtering and payload timestamp alignment. - Unity Catalog Mapping Matrix: Maps 61 canonical BigQuery tables to their Databricks counterparts, including the segregated Shiba tenant (bliplayer_shiba catalog). - CLI Tooling: Runs direct SQL against Databricks via OAuth2 U2M authentication and generates multi-table 3-hour comparative parity dashboards. - Use Case: Audit whether imt_notifications in BigQuery matches bliplayer.raw.notifications in Databricks for a given hour and EventHub namespace, producing an exact row-count comparison. ## Quick Start Ask the assistant to compare row counts between BigQuery imt_notifications and Databricks bliplayer.raw.notifications for a specific UTC hour and namespace.