Home · Quick start · Editor · charter.yaml · Sources · Agent · Guides · Evals · Audit · Policies · CLI · MCP · Workspace · Desktop · About · FAQ

Does DataCharter collect any telemetry?

No. There is zero telemetry and no phone-home of any kind. The server binds to 127.0.0.1 by default, so it is reachable only from your machine unless you opt in with an explicit --host.

Can I use it fully offline?

Yes, with one caveat about first use. The application, engine, and UI run locally with no network calls. DuckDB fetches source extensions (for example, the community BigQuery and SQL Server extensions, or the Iceberg and Delta core extensions) from its extension repository the first time they are used, which needs network access once. After that, and for sources that use bundled extensions or local files, no connection is required. The optional agent needs network access only if you point it at a hosted endpoint; with --local it stays on your machine.

Where does my data go? Is anything sent to a model?

Query results stay local. The natural-language agent is optional. If you do not configure an endpoint or run --local, no data is sent anywhere. When the agent is on, PII columns — both those you declare under pii in charter.yaml and those DataCharter auto-detects — are masked (•••) before results reach the model; you can adjust this per source, table, or column with agent_access or the explorer’s left-panel toggles. With --local the model runs on your own machine; with a hosted endpoint or Claude Code, only the questions and those masked results are sent.

Which model should I use?

You have three paths:

There is no bundled or fine-tuned model. Grounding (schema introspection, contract scoping, execution-feedback retry) does the heavy lifting, so a capable general model is usually enough. See Agent modes for details.

Is it free? Can my company use it?

Yes. DataCharter is released under the Apache-2.0 license, which permits commercial use.

Do I need Docker, an account, or a database to run it?

No. DataCharter is one Python package that runs as a single process. Docker is used only in the project’s own integration tests, never required of users. There is no account and no application database; local state is a DuckDB file inside the workspace.

Is the engine read-only?

Yes. A statement allowlist is enforced in the engine, so queries cannot modify your sources. The only write path is local.* DDL, used for snapshots into the workspace’s encrypted local catalog.

How do I make the agent smarter about my data?

Write guides. guides/*.md in the workspace holds the context you’d explain to a colleague (“revenue is net of refunds”, “exclude tier = ‘internal’”); the agent surface receives it automatically — including MCP clients, via the protocol’s instructions field. Per-table notes go in the charter’s context: mapping. Start from the example workspace.

How do I know the agent is getting my data right?

Write an eval suite. evals/*.yaml holds the questions you ask plus assertions on what a correct answer must contain; datacharter eval scores the agent against them, --compare-guides shows how much your guides help, and --threshold turns it into a CI gate. Runs persist locally so you can watch the trend and catch regressions.

How do I prove what an agent actually saw?

The flight recorder. Every agent data access is logged with dual attribution (OS user + the MCP client or model), hash-chained so edits and deletions are detectable, and exportable as an evidence pack. datacharter audit verify walks the chain; the Audit panel shows the timeline. Metadata and hashes only — the log never stores raw rows.

How would I know if masking ever failed?

Enable canary tripwires: canary: on plants synthetic honeytokens in a masked local table. If a token ever appears in agent output, masking provably failed — the alarm lands in the tamper-evident audit chain, and block mode withholds the response. datacharter canary drill proves the alarm path.

Is there a version that doesn’t need a terminal?

Yes — the desktop app (beta): a native macOS/Windows application wrapping the same local server. Pick a workspace folder and go; every governance layer applies identically. Downloads are on the latest GitHub release.

Do I have to write the guides myself?

Not from scratch. datacharter suggest mines your recent query history for repeated habits (filters you always apply, tables you always join) and turns them into guide suggestions with evidence — accept them in the CLI (--apply) or one-click in the Guides editor. Deterministic and offline; no model needed.

Can I stop an agent from ever seeing individual rows?

Yes — policies: aggregates only restricts a relation to aggregate queries, groups of at least k suppresses any group smaller than k (the clean-room control), and no joins to … blocks re-identification via joins. Written in plain English in the charter, compiled deterministically, enforced fail-closed at the agent surface.

How does it compare to other tools?

At a high level, and without disparaging any of them (they are good tools):

The short version: DataCharter’s angle is contract-governed, local-first exploration across many sources, where the agent is a bonus rather than the point.

Why “charter”?

Your charter.yaml is the contract that charters the workspace: it declares the sources, the tables, and the sensitive fields. Charter your data, then explore it.