Skip to main content

Data Catalog evidence

Evidence scope​

ItemValue
Realmgj76anadpsc
Workspacew-t5e2kcxjd
Kubernetes contextdev-north-alicloud
Evidence date2 September 2026
UI rolePlatform administrator; signed-in UI capture pending
Mutation policyRead-only assessment; no catalog, tag, description, permission, quality, or upload mutation performed

Verified inventory​

Deployed Trino catalogs​

The coordinator mounts these property files and connector names:

CatalogConnector
deltadelta_lake
hivehive
tpchtpch
tpcdstpcds

Reproduce without reading credentials:

kubectl --context dev-north-alicloud exec -n trino \
  deploy/trino-coordinator-defaultcluster -c trino-coordinator -- \
  ls -la /etc/trino/catalog

Then read only connector.name from each listed properties file. A direct unauthenticated SHOW CATALOGS attempt returned HTTP 403 because Trino does not allow authentication over HTTP; that rejection is expected and was not bypassed.

Deployed Superset registrations​

A read-only query through Superset's own application model returned:

['delta']

No connection secrets were printed. This confirms why the Cogrion Catalog page should expose only delta, even though Trino mounts four catalogs.

The retained SQL Lab history contained 230 queries. A read-only application model query found zero rows whose selected catalog was hive and zero SQL or executed-SQL fields containing a qualified hive.* or "hive".* reference. This covers Superset-originated queries only; direct Trino clients remain unverified.

Deployed DQ initialization state​

The dev-north-alicloud cluster has a Ready dq-watcher Deployment in qd-system, but no retained dq-init Job. The Job's configured ten-minute TTL explains why its completion record and logs are no longer available.

Recent watcher logs repeat approximately every 30 seconds:

No live files found for warehouse/cogrion_system/dq_tables/
Skipping malformed table_name in dq_tables: 'customers'
Discovered 0 tables from dq_tables: []
No tables discovered — waiting for dq-init or check DQ_TABLE_LIST

This is direct evidence that initialization did not produce the usable DQ state expected by the running consumer. It does not establish which statement inside setup_dq_v2.py failed because the init logs have expired.

Source evidence​

ClaimSource
Oqullus lists Superset databases as catalog nodesoqullus/src/context/catalog/CatalogContext.tsx
Quick Access hard-codes Last viewed and applies no Recents filteroqullus/src/context/catalog/CatalogContext.tsx; oqullus/src/pages/Dashboard/General/Catalog/CatalogList/index.tsx
Schema Owner and Created at are placeholder values; Catalog ownership is dormant local stateoqullus/src/context/catalog/CatalogContext.tsx; oqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/CatalogDetailView/index.tsx; oqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/MetadataSidebar.tsx
Catalog/schema descriptions are memory-only and their tag callbacks are absentoqullus/src/context/catalog/CatalogContext.tsx; oqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/CatalogDetailView/index.tsx; oqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/SchemaDetailView/index.tsx
DataHub metadata routes implement table and column scope onlybff-api/src/routes/datahubRoute.js
Ranger seeds public delta.information_schema access but no explicit cogrion_system policyplatform-stacks/kcl/applications/delta_spark_product_capabilities/main.k
BFF FAQ and data-quality paths query delta.cogrion_system with the caller's exchanged tokenbff-api/src/services/faqService.js; bff-api/src/services/catalogService.js
Catalog Settings shows a hard-coded inert metastore itemoqullus/src/pages/Dashboard/General/Catalog/CatalogMenu/index.tsx
BFF database, schema, table, and column routes proxy Supersetbff-api/src/routes/supersetRoute.js
Current KCL seeds only Superset deltaplatform-stacks/kcl/applications/superset/main.k
Current KCL configures Trino delta and hiveplatform-stacks/kcl/applications/trino_cluster/main.k
Delta and Hive share the Thrift HMS; the Glue-only hide property is not an HMS safeguardplatform-stacks/kcl/applications/trino_cluster/main.k; Trino Delta configuration
Trino 483 Delta listTables() returns HMS names without provider filtering, while table access verifies the Delta providertrinodb/trino@483: DeltaLakeMetadata.java; HiveMetastoreBackedDeltaLakeMetastore.java
Trino 379 changed information_schema.columns to ignore non-Delta HMS entries but did not filter listTables()Trino 379 release notes; Trino PR #12122
Metadata URNs use trino,catalog.schema.tablebff-api/src/services/datahubService.js
Lineage UI uses hive,schema.tableoqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/TableDetailView/index.tsx
DataHub client always uses the configured service tokenbff-api/src/clients/datahubClient.js
Ranger catalog routes require platform_adminbff-api/src/routes/rangerRoute.js
Superset assigns the effective Trino user and can fall back to a service-account JWTplatform-stacks/kcl/applications/superset/main.k
Trino configures Ranger as its system access controlplatform-stacks/kcl/applications/trino_cluster/main.k
Table Overview eagerly starts Sample, History, and DQ configuration readsoqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/TableDetailView/index.tsx
DQ load submits hard-coded SQL Lab payloads for default.dq_* using database ID 2 and no catalogoqullus/src/services/data-quality-service.ts
BFF DQ implementation locates its tables in delta.cogrion_systembff-api/src/services/catalogService.js; bff-api/src/routes/catalogRoute.js
Generic HTTP handling retries each 500 twiceoqullus/src/utils/httpTempUtils.ts
KCL runs and then expires the DQ init Job; watcher ordering checks Job completion only and defines no health probesplatform-stacks/kcl/applications/dataquality/main.k
Sample and History use synchronous SQL with row limits but no timeout or cancellationbff-api/src/services/catalogService.js; bff-api/src/utils/catalogUtils.js; bff-api/src/services/supersetService.js
Superset supports async SQL Lab and persistent results, but Catalog does not use themplatform-stacks/kcl/applications/superset/main.k
History timezone changes only non-persistent browser formattingoqullus/src/pages/Dashboard/General/Catalog/CatalogDetail/TableDetailView/index.tsx
Generic query caching excludes caller/access scope and is not used by Sample or Historybff-api/src/services/catalogService.js; bff-api/src/routes/catalogRoute.js
Delta $history exposes commit metadata and a timezone-aware timestampTrino Delta Lake connector: History table
Trino provides Bernoulli and system sampling with different execution semanticsTrino SELECT: TABLESAMPLE
Complete-lineage traversal synthesizes Consumes/Produces, infers jobs from URNs, and drops DataFlow contextbff-api/src/clients/datahubClient.js; bff-api/src/routes/lineageRoute.js
Lineage UI rebuilds its graph from flattened upstream/downstream relationshipsoqullus/src/components/commons/LineageExplorer/index.tsx

Reproduction scenarios​

CAT-S001 — Catalog authority and supported list​

  1. Sign in to https://platform.cogrion.com with realm gj76anadpsc.
  2. Select workspace w-t5e2kcxjd and open Catalog.
  3. Capture the top-level list and GET /superset/api/v1/database response.
  4. Compare names with /etc/trino/catalog/*.properties in dev-north-alicloud.

Expected: the UI and Superset list only delta; Trino also contains internal hive and synthetic tpch/tpcds. Any other UI entry is configuration drift and requires compatibility review, not automatic support.

CAT-S002 — Lazy discovery failure and recovery​

  1. Expand delta, a schema, and a table; record the database ID and requests.
  2. In a controlled test environment, fail one schema or table request with 503.
  3. Observe whether the node reports a dependency error or an empty result.
  4. Restore the dependency and retry the same node without reloading the page.

Source expectation: the failed node becomes childrenLoaded: true with an empty child list and no node-level error. Confirm this visibly before closing REL-CAT-001.

CAT-S003 — Rename persistence​

  1. Use a disposable catalog tree entry in a test environment.
  2. Double-click its tree label, enter a temporary name, and press Enter.
  3. Reload the page and reopen the same path.
  4. Confirm Superset, Trino, Hive Metastore, and DataHub names never changed.

Source expectation: only React state changes and refresh restores the original name. Do not perform this on a production-owned identifier.

CAT-S004 — Table detail request timing​

  1. Open a known delta table while the Overview tab is selected.
  2. Record requests and Trino/Superset query history before clicking other tabs.
  3. Confirm whether sample-data and table$history queries start immediately.
  4. Repeat with Ranger-denied data and a table without history support.

Expected from source: both queries start during table initialization. Record their UI errors, row limits, query identity, and audit entries.

CAT-S005 — Canonical DataHub identity and lineage​

  1. Choose a table with known DataHub metadata and lineage.
  2. Record the dataset URN returned by metadata details/schema calls.
  3. Open Lineage and record the URN sent to the lineage endpoint.
  4. Compare platform, qualified name, and fabric exactly.

The two URNs must identify the same entity. Current source predicts a mismatch: metadata uses urn:li:dataPlatform:trino plus catalog.schema.table, while lineage uses urn:li:dataPlatform:hive plus schema.table.

CAT-S006 — Metadata authorization and audit​

Use only disposable metadata and approved test actors.

  1. With a platform administrator, add and remove a temporary tag and edit a description; record HTTP status, DataHub audit actor, and final value.
  2. Repeat with each route-visible non-admin role.
  3. Attempt a resource outside the actor's data scope.
  4. Verify denial occurs before the shared DataHub credential is used.

Current source verifies JWT presence but no role or resource authorization on reviewed metadata mutation routes. Until this scenario proves an upstream control, treat the finding as open.

CAT-S007 — Permission enforcement​

  1. Open Permissions as platform_admin; record direct and inherited grants.
  2. With approval, grant and revoke a disposable table-level permission and verify the exact Ranger policy and Trino result.
  3. Open the same tab as every other Catalog-visible role.
  4. Confirm the UI hides or disables unavailable mutations and explains 403s.

CAT-S008 — Search scale​

  1. Record loaded nodes and request count before typing.
  2. Search for a table not yet expanded.
  3. Record schema/table requests, concurrency, completion time, cancellation, and browser memory.
  4. Repeat at representative maximum catalog/schema/table counts.

No supported scale boundary or server-side search path is documented.

CAT-S009 — Hive connector dependency and retirement​

  1. Inventory hive.information_schema.tables and classify every table format; distinguish actual non-Delta Hive tables from entries also served by delta.
  2. Search retained Trino query events across Superset, notebooks, jobs, service accounts, and external clients for catalog hive and qualified hive.* references.
  3. Inventory Ranger policies whose catalog resource includes hive.
  4. Identify an owner and supported journey, or run a monitored catalog-level deny or disable canary in gj76anadpsc.
  5. If no dependency appears during an agreed observation window, remove the connector from platform configuration and verify Delta, Spark, notebook, Catalog, and data-quality journeys.

Current evidence does not identify a consumer. It is insufficient to prove that removal is safe because Superset history excludes direct Trino clients.

CAT-S010 — Cross-surface object-type icons​

  1. In Catalog, expand delta and one schema containing a known table and view.
  2. Record the icon shown for each object type.
  3. Open SQL Lab and locate the exact same objects.
  4. Confirm that the table shown as a folder in Catalog uses a table glyph in SQL Lab, and compare view and column treatment.
  5. Repeat in light and dark themes and inspect accessible object-type names.

Source confirms that Catalog TreeItem.tsx explicitly maps catalog, schema, table, and view to FolderIcon, with the same folder as the unknown-type fallback. SQL Lab separately maps tables to IconTable and columns to IconColumns. Replace both mappings with one stable visual vocabulary: database/catalog, folder/schema, grid/table, and view-specific glyphs. Icons should supplement an accessible object-type label rather than become the only distinction.

CAT-S011 — Catalog and SQL Lab tree parity​

  1. Open Catalog, expand the same catalog and schema, and record object icons, expandable nodes, search results, loading/error states, and available actions.
  2. Open SQL Lab without reloading and inspect the same path.
  3. Compare whether shared search and expansion state carry between pages.
  4. Expand a table in both places and compare column discovery.
  5. Trigger each visible context action only against disposable test data and record whether it persists, is rejected, or displays a placeholder.

Source confirms one shared CatalogContext but two render implementations. Catalog restricts expansion to catalog and schema nodes and maps all object types to folders. SQL Lab uses distinct object icons, supports table-to-column expansion, and implements tree recursion inline while an additional unused SQLMenu/TreeItem.tsx remains in source. Its Rename, Add Schema, and Delete menu items display a placeholder alert rather than performing an operation.

Replace the forks with a shared accessible CatalogTree that owns node rendering, type icons, expansion, loading, errors, refresh, and search. Supply Catalog navigation/metadata actions and SQL Lab insert/copy actions through explicit mode capabilities.

CAT-S012 — Top-level “Warehouse” grouping​

  1. Open Catalog and SQL Lab and locate the top-level Warehouse section.
  2. Inspect its expansion and confirm all Superset database entries are placed beneath it.
  3. Verify that expanding or selecting it produces no backend request for a warehouse object and that it has no identifier or authorization state.
  4. Compare the term with the actual Delta Lake, Trino compute, and object storage boundaries.

Source creates exactly one section with the constant title Warehouse and defaults it open. It is only a collapsible presentation group. Remove that single group on the Catalog page and list catalogs directly. If SQL Lab needs a collapsible section header, use Data sources, while retaining catalog as the technical type of each entry. If further grouping becomes necessary, derive categories from connector metadata—for example Lakehouse, Databases, Streaming, and Synthetic. Do not treat a presentation group as a securable or queryable catalog level.

CAT-S013 — Disabled adjacent-product controls​

  1. Open the Catalog landing page as each Catalog-visible role.
  2. Inspect Delta Sharing, Clean Rooms, and External Data.
  3. Confirm each control is disabled and provides no reason, requirement, documentation link, or availability status.
  4. Compare the rendered state across workspaces and inspect feature flags and capability responses.

Source sets disabled unconditionally on all three buttons. Their click handlers only write a label to the frontend logger and cannot run while the buttons are disabled. No matching BFF route or platform-stack capability was identified. Hide these controls until a supported capability exists, or gate them through an explicit capability response and show a specific unavailable reason with product documentation. Do not imply that users can unlock them by changing roles or workspace configuration.

CAT-S014 — Duplicate file-upload entry points​

Use an approved disposable file and destination.

  1. Open the sidebar + menu and record its accessible name and menu wording.
  2. Open the landing-page Add Data menu and compare its available actions.
  3. Open CSV and Excel from each entry point and compare form, destination list, authorization, validation, errors, cancellation, and completion behavior.
  4. Complete one upload and confirm whether both the tree and landing-page list show the new object without a manual refresh.

Source confirms both entry points independently fetch the same Superset database list and render FileUploadForm. Copy changes from icon-only + to Add Data, Upload CSV or Upload CSV to Lakehouse, and finally Upload CSV Data; Excel follows the same pattern. Neither success callback refreshes its view.

Use one shared Upload data action and drawer. Its menu can identify CSV file and Excel file, while the form explicitly selects the destination catalog and schema. Avoid Lakehouse in action copy because future destinations may use other connector types. The compact sidebar control must retain an accessible Upload data name and tooltip, and successful upload must invalidate and reload affected discovery state.

CAT-S015 — Ranger-scoped discovery identity​

Use an approved test actor whose Ranger policy denies one known catalog, schema, or table while allowing access to the Catalog page.

  1. Record the actor's Superset roles and exact Ranger policies before testing.
  2. Open Catalog and capture GET /superset/api/v1/database; confirm whether the top-level delta registration remains visible despite the Ranger denial.
  3. Expand the denied schema or table and capture the schema, table, and column responses. Run one approved fully qualified SQL statement against the same resource and record its denial.
  4. Correlate every metadata and SQL request with Trino query logs and Ranger audit records. Record the Trino user, authenticated principal, groups, resource, policy, and authorization result.
  5. Repeat once with a valid session token and once through the controlled missing or expired-session-token path that invokes Superset's service-account JWT fallback.
  6. Confirm an authorized Trino catalog omitted from Superset registration can be queried by fully qualified name but does not appear in the Catalog tree.

Expected: the top level follows Superset registration and RBAC, while all Trino metadata and SQL operations are authorized as the intended end user by Ranger. Fail the scenario if a Ranger-denied resource is enumerated beyond the agreed disclosure policy, the fallback is authorized as the service account instead of the end user, or the UI represents top-level visibility as proof of data access.

Target behavior: populate the Trino catalog plane from a Ranger-filtered Trino catalog-listing operation, or explicitly label Superset entries as connections and list Ranger-filtered catalogs beneath them. Preserve and audit one end-user identity for catalog, schema, table, column, sample, history, and SQL requests.

CAT-S016 — Quick Access and Recents​

  1. Open /admin/catalog and record the rows under Recents, including every Last viewed value.
  2. Switch to Catalogs and compare row count, identities, order, and dates.
  3. Open one catalog, return to /admin/catalog, and repeat the comparison.
  4. Reload, sign in again, and repeat in another browser profile if durable recency is claimed.

Source expectation: Recents and Catalogs contain the same rows, Last viewed is always N/A, and opening a catalog changes neither list. CatalogContext creates the list directly from Superset database registrations, while selectCatalog only assigns current React state.

Required resolution: remove Quick Access, Recents, and Last viewed. With one authorized catalog, route directly to its explorer. With multiple catalogs, show a searchable Catalogs directory. Reintroduce Recents only after canonical catalog identity and server-side {user, workspace, catalog, lastViewedAt} tracking exist.

CAT-S017 — Schema fields and catalog/schema metadata controls​

  1. Open a catalog containing at least two schemas and compare Owner and Created at across all rows.
  2. Confirm Owner is N/A when the tree contains no owner and every Created at value is July 23, 2025, regardless of the actual schema lifecycle.
  3. Inspect the catalog detail for Owner and Created at. Confirm the active view does not render either field and no network-backed source supplies them.
  4. Edit the catalog description, navigate away and back, then reload the page.
  5. Repeat the description edit on a schema.
  6. On both catalog and schema pages, select Add tags and try to remove a tag if one is displayed. Record network requests and visible feedback.
  7. Compare with an approved table, whose description and tag operations use the DataHub-backed BFF routes; do not mutate production-owned metadata.

Source expectation: catalog/schema description changes survive only in the current React tree; reload removes them. Their tag sidebars always receive an empty array and no add/remove handlers, so Add tags is inert. No corresponding catalog/schema DataHub route exists. Remove these controls and the fabricated schema columns, and keep Catalog Owner/Created at hidden, until authoritative, persistent, authorized metadata is wired.

CAT-S018 — System-schema visibility and governance boundary​

  1. For each Catalog-visible role, expand every authorized catalog and record whether information_schema and cogrion_system appear in Catalog and SQL Editor.
  2. For information_schema, verify metadata listings contain only objects the actor may discover. Record the Trino identity, Ranger decision, and any hidden columns; do not attempt a mutation.
  3. Inspect catalog/schema/table detail routes for Description, Tags, Sample, History, Quality, Owner, and lifecycle actions on both reserved schemas.
  4. Call the corresponding mutation routes only with an approved non-production fixture and confirm the BFF rejects reserved-schema governance mutations even if a UI control is hidden.
  5. Exercise FAQ and data-quality read/write journeys as a non-admin user and correlate their Superset, Trino, and Ranger identities. Confirm they do not require broad direct access to cogrion_system.
  6. Compare a freshly bootstrapped workspace with an upgraded workspace. Export the effective information-schema-reader policy, including resources, principals, and accesses, and verify they are identical.

Required result: information_schema remains available for filtered read-only metadata but is hidden from normal governance navigation. cogrion_system is hidden and denied to direct users, while explicitly authorized product services retain only the table-level access they need. Bootstrap reconciliation must produce the same declared policy from clean and existing Ranger state.

CAT-S019 — Catalog Settings metastore item​

  1. In realm gj76anadpsc and workspace w-t5e2kcxjd, open the Catalog sidebar gear and record its accessible name and menu contents.
  2. Select the displayed metastore item and record navigation, state changes, and network requests.
  3. Compare the displayed provider and region with the deployed workspace context dev-north-alicloud and authoritative metastore configuration.

Source expectation: the menu always displays metastore_aws_ap_southeast_2, its handler performs no action, and opening or selecting it fetches no configuration or health data. Remove the gear. Any future metastore diagnostics belong in an admin-only operational view backed by live deployment and health information.

CAT-S020 — Overview request fan-out and repeated DQ failures​

  1. Open browser developer tools, clear the Network log, and keep Preserve log enabled.
  2. Open Catalog and select a table, but remain on Overview; do not select Sample Data, History, or Quality.
  3. Group requests by URL and payload. Confirm that Overview initiates columns, sample, history, two DataHub metadata reads, and two DQ SQL executions.
  4. Inspect the DQ mapping payload. The observed failure used database_id: 2, catalog: null, schema: "cogrion_system", and SQL SELECT rule_id, column_name FROM default.dq_rule_mapping ....
  5. Count attempts for one identical failed request by URL and payload. Source predicts three total attempts: the original plus two retries after 500 ms and 1 s.
  6. Open Sample Data, History, and Quality after the requests settle. Record whether each tab distinguishes loading, unsupported history, empty data, authorization denial, and dependency failure.
  7. Repeat on a table without Delta history support and with a restricted test user. Correlate browser attempts with BFF, Superset, and Trino query IDs.

Expected correction: Overview fetches only its own required metadata. Each other tab loads once on first activation and owns its error/retry state. DQ configuration uses a dedicated BFF resource endpoint; the request contains the canonical table identity but no Superset database ID, internal schema/table name, or SQL. Deterministic failures are not retried automatically.

CAT-S021 — DQ initialization readiness​

  1. In dev-north-alicloud, inspect the dq-init Job status and retain its pod logs before the configured TTL expires.
  2. Through the same authenticated Trino path used by the DQ service, verify the required tables and schemas in delta.cogrion_system, then perform a read-only query against each control table.
  3. Inspect dq-watcher logs and readiness. Confirm whether it finds live Delta files, accepts every seeded canonical table identifier, and discovers at least the intended configured tables.
  4. Restart the watcher and repeat to prove readiness survives pod replacement.
  5. Run the initialization again to prove it is idempotent and does not corrupt existing configuration.

Current result: failed. The watcher remains Ready while discovering zero tables and explicitly waiting for initialization; the init Job evidence has already expired. Keep OPS-CAT-001 open until initialization, Trino contract checks, pod readiness, restart, and idempotency all pass.

CAT-S022 — Sample and History performance boundaries​

Use approved tables representing small, large, wide/nested, highly partitioned, small-file-heavy, and long-commit-history cases.

  1. Open each table and remain on Overview to confirm COST-CAT-001, then repeat after on-demand loading is implemented.
  2. For Sample, record Trino query ID, planning time, queued time, execution time, processed rows/bytes/files, returned bytes, and largest serialized cell. Confirm that 10 returned rows are not presented as random.
  3. Compare first-row preview with explicit-column, partition-filtered, and TABLESAMPLE SYSTEM variants. Do not use Bernoulli sampling as a performance optimization because it independently evaluates rows across the input.
  4. For History, test tables with increasing Delta commit counts. Record log loading and execution time for the current timestamp sort, then for selected columns ordered and paged by version.
  5. Confirm the UI enters an operation-specific slow state, displays elapsed time, and provides Cancel. Verify in Superset and Trino that Cancel stops the upstream query rather than only hiding the loader.
  6. Cross the configured timeout and verify a distinct timeout state with Retry and Open query in SQL Editor. Confirm stale Sample or History rows are not displayed as the new result.
  7. Test any cache with two principals whose Ranger access differs, then update the table and repeat. A cached response must never cross the authorization scope and must follow its declared table-version/freshness contract.

No maximum supported table size, file count, column count, cell size, response bytes, Delta commit count, p95 latency, or timeout has been established. Keep those boundaries open until this matrix is measured in w-t5e2kcxjd.

CAT-S023 — Timestamp display semantics​

  1. Open History and capture the $history.timestamp value returned by the BFF.
  2. Switch UTC to Local and confirm the network response and Trino query do not change; only browser rendering changes.
  3. Reload and navigate away/back. Confirm the selection resets to UTC.
  4. In Sample and SQL results, compare known TIMESTAMP and TIMESTAMP WITH TIME ZONE columns around a daylight-saving transition.
  5. Confirm History uses fixed UTC with an explicit offset, while Sample and SQL results preserve Trino's typed returned values and leave plain timestamps unchanged.
  6. If configurable query timezone is later introduced, filter around a known offset and daylight-saving boundary. Verify the request carries explicit session/type semantics, sorting uses canonical typed values, and copied and exported values identify their zone. An unqualified predicate derived from a converted display value fails this scenario.

Current source result: the selector is History-only React state and formats only a field named timestamp. It neither changes Trino's session timezone nor persists a user preference. The approved interim contract is fixed UTC for History and no display-only conversion for table data.

CAT-S024 — Replace generic Consumes/Produces with typed lineage​

  1. Open /admin/catalog, select a table, and choose Lineage → Graph. Use a known fixture such as delta.raw.orders → daily_orders DataJob → delta.curated.orders, with daily_orders registered under daily_orders_flow.
  2. Compare the DataHub entities and complete lineage path with the BFF response from /lineage/explorer/entity/{urn}/complete-lineage and the rendered graph.
  3. Confirm every node retains its actual Dataset, DataJob, or DataFlow type and canonical URN; type inference from an URN substring fails this scenario.
  4. Verify the path remains Dataset → DataJob → Dataset, with Input and Output semantics and the job's DataFlow membership. It must not become a direct dataset relationship or two generic Consumes/Produces edges.
  5. Open dataset details and confirm separate Upstream datasets, Processing jobs, and Downstream datasets. Open the job and confirm Inputs, Outputs, and Part of flow.
  6. Repeat with direct object-to-object lineage and confirm no artificial job or flow is introduced.
  7. Open Impact Analysis and confirm downstream impact retains processing jobs in each path rather than drawing every affected dataset as an immediate dependency.

Current source result: failed. The adapter assigns Consumes/Produces solely from traversal direction and the frontend flattens DataHub's entity/path model.

CAT-S025 — Shared-HMS table-format discovery​

  1. Identify an existing non-Delta Hive table in a schema also used by delta. Do not create or mutate a fixture without approval.
  2. As the same restricted user, compare SHOW TABLES FROM hive.<schema> and SHOW TABLES FROM delta.<schema> with the Superset /api/v1/database/{deltaId}/tables response and the Catalog tree.
  3. For a non-Delta name returned under delta, request columns, preview, and Delta History. Record whether each operation succeeds, omits the object, or returns NOT_A_DELTA_LAKE_TABLE, TABLE_NOT_FOUND, or another error.
  4. Verify the BFF discovery response identifies the selected Trino catalog, relation type, authoritative table format, and supported capabilities. A generic table name/type response fails this scenario.
  5. Repeat with an Iceberg table when an Iceberg catalog is introduced against the same HMS. Confirm Delta-only controls are absent, Iceberg-specific capabilities are correct, and the object remains catalog-qualified.
  6. If table redirection is evaluated, repeat reads, metadata-table access, writes, views, and management operations. Do not treat one redirected SELECT as proof of capability parity.

Current source result: failed at the contract level. Trino 483 exposes an unfiltered HMS name list through Delta listTables(), while Oqullus consumes a generic Superset table response and has no authoritative format/capability field. Live mixed-format behavior in gj76anadpsc remains Unverified until an existing fixture is identified.

CAT-S026 — DataHub ingestion coverage​

  1. Export the authorized Trino catalog, schema, table, and view inventory for one approved workspace identity.
  2. Export the matching canonical DataHub Dataset identities and their last successful ingestion or producer update time.
  3. Compare coverage by canonical catalog.schema.relation identity; separate absent entities from entities that exist without descriptions, tags, or lineage.
  4. Inspect the deployed ingestion schedules and their most recent run status, scope, errors, retry, and deletion behavior.
  5. Add a disposable table through an approved path and verify when and how its DataHub entity appears. Remove it and verify the declared deletion or deprecation behavior.
  6. Fail one controlled ingestion run and confirm operators and Catalog users receive an actionable freshness or degraded-state signal.

Current source result: managed-ingestion capability exists, but no deployed source recipe was identified for the assessed workspace. Runtime coverage, freshness, recovery, and deletion behavior remain Unverified.

CAT-S027 — Catalog lifecycle placeholders​

Use only disposable test objects and do not invoke an authoritative destructive operation without separate approval.

  1. Inventory every visible Create Catalog, Add Schema, Set Owner, Rename, and Delete action in Catalog and SQL Editor.
  2. Invoke non-destructive placeholder actions and record visible feedback, network requests, browser state, and refresh behavior.
  3. For Rename, use a disposable entry, reload, and compare Trino, HMS, Superset, and DataHub identities.
  4. Confirm whether any action defines authorization, audit, conflict handling, partial failure, retry, and rollback.
  5. Remove actions that do not have a complete durable contract. Verify they are also unavailable through direct product API calls where appropriate.

Current source result: the reviewed actions either mutate browser state, show a placeholder message, or have no complete persisted backend contract. They must not be represented as supported lifecycle operations.

Evidence still required​

  • Signed-in screenshots/network evidence for CAT-S001 and normal tree expansion.
  • Empty, unauthorized, stale-metadata, Superset failure, Trino failure, DataHub failure, Ranger failure, and recovery states.
  • Restricted-user Ranger audit evidence for both normal Superset session-token propagation and the service-account-token fallback in CAT-S015.
  • Live confirmation of the identical Recents and Catalogs states in CAT-S016.
  • Live confirmation of placeholder fields and reload behavior in CAT-S017.
  • Role, Ranger-audit, reserved-mutation, internal-service, and clean-versus- upgrade bootstrap evidence for CAT-S018.
  • Live confirmation of the inert hard-coded gear menu in CAT-S019.
  • A clean Network capture and correlated BFF/Superset/Trino identifiers for CAT-S020, including the exact status and response body for each failed logical operation.
  • Preserved dq-init status/logs and successful contract, restart, and idempotency evidence for CAT-S021.
  • Measured preview/history scale matrix, cancellation propagation, timeout, slow-state, and authorization-scoped cache evidence for CAT-S022.
  • Cross-page and reload evidence for persisted timestamp semantics in CAT-S023.
  • DataHub inventory, ingestion-run, freshness, failure, and deletion evidence for CAT-S026.
  • Live inventory and refresh evidence for every lifecycle placeholder in CAT-S027.
  • Entity-type, complete-path, Spark DataJob/DataFlow, and direct dataset lineage evidence for CAT-S024.
  • DataHub producer inventory, ingestion coverage/freshness, lineage coverage, tag-sync lag, and mutation audit identity.
  • Upload collision, payload limits, partial failure, cleanup, and authorization.
  • Catalog, schema, table, column, lineage, tag, and search scale boundaries.
  • Product, data-platform, governance, security, and operations owner review.