CHAT WITH MARTIN
Meet Martin — he greets you when a chat opens, and he answers from your live data. Martin writes the SQL, DVT guards it and executes it through the federation engine — the same virtualization path as the API portal, so nothing ever reads a stale table. The SQL that ran is always one click away: what we claim is what you can read.
Starting
dvt serve # the suite, chat included dvt chat # just chat (46104) dvt kill -s chat # stop it
Chat needs a compiled project (dvt compile) and gets column-aware after dvt docs generate.
One AI outlet: AI-Proxy
- the gateway, not key sprawl — Martin speaks to AI-Proxy (aiproxy.meta-thinking.net) — a self-hosted OpenAI-compatible gateway over the subscriptions you already own, with local Ollama routing for air-gapped floors. DVT never takes per-token API keys.
- on-prem by design — one connected (or Ollama-only) box runs the gateway; every desk reaches models over the internal network through one base URL. The credential lives in hub → Settings → AI CREDENTIALS — a card with a TEST button that asks the gateway for its model list.
- /model — pick the exact AI model your gateway serves — the palette lists what it actually reports, and your pick rides every question.
- grounded, not improvising — Martin's system prompt carries DVT's code-verified expert corpus (shipped inside the wheel) plus this project's own models, columns and sources. Where general dbt knowledge disagrees, the corpus wins.
Martin investigates — agentic, with DVT's own tools
- tools belong to DVT, not the model — Martin can call run_sql (the same guard and live federation — he literally cannot write), get_columns and list_relations (the profiler's catalog, live-discovered when stale), and save_asset (only when you ask). The model plans; DVT's governed machinery acts.
- a careful analyst, not a guesser — ask him to double-check and he will: peek at columns, sample values, verify a join — a few calls at most, budget-capped — then compose the final answer, whose SQL runs fresh and is what you see.
- @ references, CLI-agent style — type @ and the palette lists your project's files; the mention lands in the question and Martin reads the file (read-only, jailed to the project, credentials refused). He learns YOUR structure and follows YOUR conventions — medallion is DVT's recommendation for fresh projects, never a rule he imposes.
- MARTIN'S WORK, shown — every answer that used tools carries a collapsible trace: each call, what it touched, and its one-line outcome — ✓ or ✗ with the real reason. What we claim is what you can read, investigation included.
Martin develops — propose, you APPLY
- /generate-sources — the kick-start — pick a connection and DVT introspects it live: every schema, every table, rendered into a doctrine-correct sources.yml (meta.connection on every source) as one APPLY-able file. Every database adapter supported; the fastest way from empty project to declared sources. Martin can do it from natural language too.
- plan mode, shift+tab — the CLI-agent rhythm: flip to ◔ PLAN and Martin can investigate but not touch — proposals, saves and runs are locked server-side; he answers with a step-by-step plan of the files, configs and commands. Review the approach, flip back to ⏵ EXECUTE, say go.
- he proposes, you click — ask for a model or a yml and Martin renders a proposal card — full content, ✓ APPLY, DISMISS. He never writes a file himself; applying is your click, confined to models/ with a timestamped backup on overwrite.
- every config, taught — his build_model_config tool knows every option a DVT model can carry — and refuses illegal combinations with the reason (target= on a standard materialization, strategies Sling can't apply), so what he proposes compiles the DVT way.
- yml with detail levels — sources.yml and schema yml from structured specs at the level you ask: minimal (names), documented (+ table and column descriptions), tested (+ yml data tests like unique and not_null). meta.connection is enforced on every source — one rule, no exceptions, even for Martin.
- execution waits for you — dvt run / test / build are proposals too — verb-whitelisted, never a shell, and the output lands on the card after YOUR click. Only compile he runs himself, to validate.
The guard — every query, no exceptions
- SELECT-only — exactly one statement; writes, DDL, ATTACH and friends are refused on sight.
- no file access — read_parquet, read_csv and every other filesystem-reading function is blocked — chat queries touch your declared models and sources, nothing else.
- always bounded — a LIMIT is enforced on every query and capped at 1000 rows.
- /sql for the direct lane — run raw SQL through the same guard with no LLM in the loop — badged DIRECT, useful when you already know the query.
If a generated query fails, the error goes back to the model exactly once for a repair; a second failure is reported honestly, SQL included.
Working in it
- the / palette — type / and your models (with columns), sources and commands autocomplete into the question. ENTER sends, SHIFT+ENTER breaks a line.
- sessions — conversations persist per project in the sidebar, auto-titled and restored in full — tables and charts included.
- rich answers — markdown answers, results tables, and theme-aware canvas charts (bar / line / pie / scatter) drawn from the real result — downloadable as PNG, tables as CSV, the SQL one COPY away.
- assets — SAVE ASSET keeps the query + chart spec in the project (.dvt/chat_saved.json); RERUN LIVE executes it fresh through federation. Saved assets are the seed of DVT Dashboards.
Security posture
Chat binds 127.0.0.1 by default, and every POST — asking (which spends your tokens and touches live sources), saving, deleting — answers only on loopback regardless of --host. Credentials are read from the local key store and never appear in a response, a log, or an error.