Data Explorer

​

Overview

Data Explorer is the customer-facing workspace for browsing connected databases, inspecting schemas and tables, previewing rows, and working with recent or saved query results.

​

What the page supports

If a deep link names a connection the server no longer lists, Data Explorer returns to the base /data route after the connection list loads. Some saved results are computed by Genesis from other saved query results, rather than returned by a SQL statement. Their query text is a description: the viewer labels it Computed result, shows it as plain text, and does not offer a Run action or SQL lineage to trace. The tabular result remains available in the query-results viewer.

​

Migration verification

Use Migration verification when you need to prove a migration moved data intact under a compiled transition contract — or to browse, declare, and compare frozen estate measurements — not for everyday table browsing. Pipeline migrations are reviewed from the migration mission workspace rather than from the Data Explorer browser. When Launchpad is used to migrate a pipeline and its data, the workspace shows the immutable source files, the converted delivery, target execution, Prover verification, task dependencies, and the requested incremental or replay-without-new-input checks. Select a file to view only when its bytes still match the approved SHA-256; changed or unavailable repository copies are not presented as approved evidence. See Database migration blueprints for the Launchpad workflow. The pipeline migration proof walkthrough explains how to read the Prover result. The landing page is Overview at /data/verify/overview/. Phase-grouped navigation organizes the rest of the surface around the migration lifecycle: Every tab is a real route (not in-page state), so deep links, refresh, and long-running measurement runs keep their place. A Track phase (deviation ledger) is planned but not yet shipped — the nav omits empty placeholders.

​

Overview

The Overview home (/data/verify/overview/) answers “where does my migration stand?” before you open any list:

• Headline tiles — counts drawn only from lists other tabs already load (verification requests, runs, ratified rules). The latest-run tile shows the verbatim rollup token the backend recorded (PASS, FAIL, INDETERMINATE, UNVERIFIED, or the run status). Only a literal PASS is coloured green; INDETERMINATE is never shown as a pass.
• Pipeline explainer — prepare request → compile → execute → measure → qualify → approve, with a human badge on the approval gate.
• Lifecycle map — Prepare → Check → Track, matching the phase labels in the nav.

Tiles link into the Verification tab; they do not invent figures no list endpoint reports.

​

Verification tab

The Verification tab under Check (/data/verify/) has three sections:

1. Verification requests — transition objectives agents prepare (for example with transition_contract_tools). Each row shows the transition name, source → target estates, object and rule counts, and a Run verification button that compiles and executes the contract in one step.
2. Runs & reports — recent verification runs with honest verdict chips. The initial list is card-shaped: it loads identity, status, progress, and small summary values without the per-run report documents, so the workspace can show the shell before a run is opened. Select a run to load its per-obligation verdicts, closure (“nothing unexpected”) checks, and rendered cutover dossier. A measured empty population appears as Nothing to check (0 rows); if every declared check ends that way, the grade is not verified by checks. See how a grade reports an empty check for how this differs from a failure or a check that could not run. For claims that a sealed check did not test a clause, consult the seal’s clause ledger and the grade’s unchecked-clause list; a clause’s absence from that list alone does not show that it was tested. A rollup of INDETERMINATE is never shown as a pass. Obligation rows show row-identity columns when present — single-column keys appear in key_column; composite keys use key_columns. The key_source field distinguishes keys declared by the source estate from keys designated by a human operator. Data Vault proofs can show generated current-state and link-membership obligations from the sealed target model. When the target looks like a vault but no model was declared, the run detail explains the undeclared_target_shape guidance and the readings withheld from published findings; see Declared Data Vault target shapes for what to provide before rerunning.
3. Correspondence rules — the rule registry with derived status (proposed → qualified → ratified / revoked). Qualified rules with valid test evidence can be approved here when you hold the ratify_transition_contract permission. The approve modal shows a provenance ladder (proposed → qualified → ratified; only ratified is sealed/green) and a per-fixture verdict table for the qualification you are signing — one row per edge fixture with its own PASS/FAIL chip, so the evidence is in front of you rather than a pass count alone.

When compile or execute refuses (missing rule, insufficient read access, no logical key, and so on), Genesis shows the refusal reason and the next step inline — for example a link to review rules. The same guidance appears as an inline chat card (transition_contract_refusal) when an agent hits the license gate; chat never signs approvals — that happens only on this page.

​

Prepare and Check measurement tabs

Baselines, Relationships, Compare, and Qualifications browse frozen records, declarations, comparisons, and qualification reports produced by measurement_tools (for example characterize_and_freeze_estate). They require manage_all_connections — stricter than the Verification tab — because frozen records and qualification reports can carry per-column value evidence from customer estates.

​

Frozen-record provenance (baselines and pickers)

Baselines and every picker (relationship declaration, compare) offer every frozen record the server returns, each with a compact provenance tag — not a filtered “safe” subset. Provenance states what was positively established; none of them certify that a record is a genuine estate baseline: List pages disclose when total exceeds shown, when run_index_truncated is true, and when provenance_index_complete is false (a missing scratch-clone badge may be a lookup limit, not proof the record is clean).

​

Declarations and comparisons

A relationship (declaration) states how two frozen estates relate, on what evidence, and which schemas or renames it covers. Empty regions licenses the whole estate and requires an explicit estate-wide acknowledgement in the UI. Grade unverified licenses no comparison — covered objects come back indeterminate, and Compare surfaces that warning through to the result. Compare stays disabled until you acknowledge what the chosen declaration licenses. Read object_pairing on the result before the counts: if nothing paired, the counts are not evidence about the two estates.

​

Compare result styling

Comparison counts are an itemized list keyed by the exact classification token the backend returned — the UI performs no arithmetic, summation, or percentage on them. Each row carries a semantic colour and a solid or hatched texture: Colour is an outcome signal, separate from the orange brand accent used for navigation and primary actions. No classification row is green — agreement at disclosed grade is grey, not success-coloured. The only green on this surface is a binding PASS verdict on a run report or overview tile, never on a comparison classification.

​

Designating row-identity keys

When a content.identity obligation is unverified because no row key was declared, the run detail shows a Designate key action on that obligation. Use it to assert which columns identify rows on the source object. Key designation is an assertion, not a measurement — you are claiming these columns identify a row; neither estate’s characterization vouches for it. Genesis probes uniqueness at run time; duplicate keys downgrade the evidence rather than passing silently. Designated keys are disclosed in the cutover dossier as human-asserted identity. The modal lists every column on the obligation frame. Select one or more columns; selection order is significant — it becomes the comparison’s sort order. A single column is a simple key; multiple columns form a composite key. Designation does not edit the original verification request. Transition artifacts are immutable, so Genesis creates a successor objective that carries the designation alongside the parent. After designating, return to Verification requests, find the new objective, and run verification again. You must have view_connections and per-connection access to both estates named by the objective (source and target).

​

Typical workflow

1. Choose a connection.
2. Expand the database and schema tree.
3. Open a table to view sample rows and columns.
4. Move into query mode when you need a custom result.
5. Refresh, reset, or revisit saved query results later.

​

Notes for users

• Data Explorer is best for fast inspection and iterative exploration.
• If a live metadata request reports that a provider sign-in has expired, follow that connection’s reauthentication steps and retry. The metadata API returns a sign-in conflict rather than a server failure; see Connection metadata browsing endpoints.
• When the Launchpad setup checklist is enabled and you have not yet completed the database_connection item, Genesis shows a small connect banner above the browser with a link to Config → Connections. The banner is non-blocking — you can browse Data Explorer normally while the item is open.
• It works well alongside Datasets when you want to turn a useful query or table into a reusable fast-data layer.
• Connection and table lists are permission-aware, so you only see database connections you are allowed to use. Bundled demo connections removed from discovery after Delete all demo data in Config -> Advanced Settings are also omitted from the default Data Explorer list.
• When you run a custom query, Data Explorer keeps the original SQL you submitted available for review and reuse instead of exposing internal paging wrappers.
• Switching to a different table clears the active custom-query state and related query deep-link text so the new selection opens in a clean table context.
• Deep links use the path /data/{connection}/{database}/{schema}/{table}. The {connection} segment accepts either the fully qualified type.name form (for example databricks.my_conn) or the bare name stored for legacy connections (for example my_conn). When a link uses type.name for a legacy connection, Genesis resolves it to the bare name and updates the browser URL to match.
• Opening a deep link validates against your full authorized connection list, not the active connection-type filter. If a filter would hide the target connection, Genesis switches the filter to All so the link can open.
• Genesis matches database, schema, and table segments case-insensitively when opening from a URL, then selects the canonical identifier returned by the connection. This matters for Databricks, where Unity Catalog may report catalog, schema, and table names in a different case than the link you followed.
• BigQuery connections browse live metadata through the same tree as other databases. In the UI, the top level is the Google Cloud project bound to the connection (shown as the database), the next level lists datasets (shown as schemas), and tables and views appear under each dataset. Service-account and user-OAuth BigQuery connections are both supported.

​

Automation surface

Direct requests to the /api/data/... browsing and query-result endpoints return 403 Forbidden when the current user is not allowed to access the requested connection.

​

Related pages

• Datasets
• Connections