Profile & AI analysis

Get a statistical overview of a table with profile_table, or run LLM-backed analysis (Magic Dust) with your own provider keys.

Two ways to understand a table beyond reading rows: profile_table for a fast statistical overview, and Magic Dust for LLM-backed analysis that runs with your own provider keys.

Profile a table

profile_table returns a statistical overview: the overall row count, plus nulls, distinct counts, and value ranges per column. It's the fastest way to understand unfamiliar data and to spot quality issues.

profile_table(table="eddytor.cfg_xxx.<uuid>_products")

AI analysis (Magic Dust)

Magic Dust sends a sample of a table to an LLM you configure and returns a structured analysis - from a plain-language summary to golden-record merge proposals. Eddytor never ships its own model access: you bring your own provider key, and analysis runs on a bounded sample, not the full table.

Before you start

An AI credential for your org: PUT /v1/ai/credentials with provider, api_key, and optional base_url (Builder or Admin). List available models per provider with GET /v1/ai/models.
Pick a model valid for that provider (e.g. claude-sonnet-5, gpt-5.6) - a model from another provider's catalog is rejected before anything is sent.

Actions

Action	What it does
`summary`	Plain-language description of the table's content and shape
`detect_anomalies`	Flag outliers and suspicious values in the sample
`find_duplicates`	Spot likely duplicate records
`fix_nulls`	Detect missing values and suggest replacements
`standardize_values`	Find inconsistent representations of the same value and propose a canonical form
`suggest_domain`	Propose a column domain (allowed values, pattern, or range) ready for enforcement
`merge_records`	Propose golden-record merges for duplicate clusters with field-level survivorship
`explain_changes`	Narrate what changed between two table versions from a version diff
`suggest_constraints`	Mine data-quality rules and emit them as Delta CHECK constraint suggestions
`classify_columns`	Assign semantic types and PII flags to columns
`suggest_mapping`	Map source columns from an import file onto the table's schema
`explain_rows`	Explain specific rows in context (also its own endpoint)

Run an analysis

POST /v1/tables/eddytor/cfg_xxx/<uuid>_orders/magic-dust
Authorization: Bearer edd_live_…

{ "provider": "anthropic", "action": "standardize_values",
  "model": "claude-sonnet-5", "sample_size": 200,
  "filters": [ { "column": "status", "operator": "=", "values": ["Active"] } ] }

CLI: eddytor magic-dust <catalog> <schema> <table> --action <action> ….

Useful request fields beyond action / model:

filters - column filters applied before sampling, so the analysis runs on the same filtered view you see. Same operators as structured queries, ANDed. Not applicable to explain_changes, which reads a version diff.
missing_values - placeholder strings fix_nulls treats as missing alongside NULL (e.g. ["N/A", "Currently Unknown"]).
version_from / version_to - required by explain_changes.
source_columns / source_sample - required/optional inputs for suggest_mapping (the import file's column names, plus raw sample lines).

Gotchas

Heads up

Sampled, not exhaustive. Actions see up to sample_size rows (after filters) - treat duplicate/anomaly output as leads to verify with SQL or validation, not as a complete audit. explain_changes truncates very large diffs; the change counts stay complete.

Suggestions never auto-apply: suggest_domain output goes through set a domain, suggest_constraints through create constraint, merge_records through merge - each with their normal validation.