Skip to main content
Start with a local DuckDB warehouse that contains deliberate data defects. By the end, you will have a map of its tables and evidence about a key and a join that cannot be trusted. You need a terminal and uv. Installation downloads packages; the demo and exploration run locally afterwards.

1. Install the CLI

Already using the Dex skills? Ask your agent to run the commands below through its installed wrapper. The wrapper and the CLI use the same engine.

2. Create the demo

Use a new directory outside an existing Dex project so the demo can create its own configuration.
The command creates dex_demo.duckdb and .dex/config.yml. The warehouse has seven tables and 29,512 rows. It refuses to replace an existing warehouse file.

3. Map the warehouse

Read data.objects for each table’s grain, candidate key, and findings, then data.edges for the inferred joins. A candidate key is a measurement; a shared column name alone is not proof of a join. Every command prints a JSON envelope. Start with these fields:

4. Investigate the findings

The demo’s order_item_id has duplicates, so it is not a valid grain. The web_events.customer_id join also fails verification: its values do not match the customer keys. These are intentional defects, not installation failures. To ask a data question, use Dex’s query command:
This returns 5,000 orders. Queries go through the same profiling and PII checks as the rest of exploration.
This query is expected to be refused. The email column is flagged as personal data. Do not clear a flag just to make an example run; see the PII policy for how flags are reviewed.

Next steps

Connect your own data

Choose a connector, verify access, and set the scope for exploration.

Explore with your agent

Turn the map into a focused investigation and verify the joins it needs.