datasentry-demo is also available as a direct console alias.
The demo generates synthetic dirty data, runs the built-in detectors, exports JSON + HTML reports, applies one safe repair to a copy, re-scans the repaired copy, and prints a rollback command. It needs no dataset, cloud service, API key, or LLM.
The default path is intentionally low-commitment: scan first, inspect evidence, then decide whether a finding deserves a permanent rule or a repair.
Why DataSentry exists
Most data-quality tools are excellent once you already know the expectations, checks, or contracts you want to enforce. Real incidents often start one step earlier: you do not yet know what is wrong.
DataSentry is built around the complete remediation loop:
Find → Explain → Fix safely → Verify
Find — discover common quality problems without writing every rule first.
Explain — attach samples, affected counts/ratios, detector evidence, and confidence.
Fix safely — preview changes and apply repairs to a copy instead of mutating the source.
Verify — re-scan the repaired copy and surface persistent or newly introduced issues.
DataSentry fits best when you are looking at data you do not fully trust yet, want evidence before codifying checks, or need a conservative remediation path. It complements expectation- and contract-driven tools rather than requiring you to replace them.
What it catches automatically
DataSentry ships with 39 deterministic detectors covering common failure modes such as:
missing and placeholder values;
invalid emails, URLs, dates, and encodings;
duplicate identifiers and uniqueness violations;
inconsistent categories and cross-field contradictions;
foreign-key and referential-integrity problems;
numeric and statistical outliers;
schema, row-count, score, and issue-distribution drift.
Every scan produces an evidence-backed issue list and a six-dimension quality score across completeness, validity, uniqueness, consistency, integrity, and timeliness.
Safe repair, not blind mutation
# inspect the highest-severity findings
datasentry issues list --severity high
# propose a repair without changing data
datasentry repair propose <issue_id> --file orders.csv
# preview the exact effect
datasentry repair preview <issue_id> --file orders.csv
# apply to a repaired copy; the original is not overwritten
datasentry repair apply <issue_id> --file orders.csv
# re-scan the repaired copy and detect regressions
datasentry repair verify <run_id>
# inspect or undo the repair
datasentry repair diff <run_id>
datasentry repair rollback <run_id>
Repairs are fingerprinted, auditable, and reversible. AI-generated repair proposals remain human-approved state changes.
Quality gates for CI
datasentry scan orders.csv --fail-on high
For GitHub repositories, reuse DataSentry's maintained workflow_call gate instead of duplicating installation and exit-code handling:
jobs:
datasentry:
uses: Jackxiaozhiren/datasentry/.github/workflows/datasentry-quality-gate.yml@main
with:
path: data/orders.csv
fail_on: high
See docs/GITHUB_ACTIONS.md for inputs, artifacts, security boundaries, and version-pinning guidance.
Reports can be exported as JSON, Markdown, HTML, JUnit, and SARIF. The GitHub Actions example fails the workflow on severe findings while still uploading an HTML report for review.
Give AI agents deterministic data-quality tools
DataSentry includes an MCP stdio server:
datasentry mcp --project /path/to/project
MCP-capable clients can scan files, inspect evidence-backed issues, read quality scores and trends, compare drift, validate contracts, manage scheduled jobs, and call DataSentry tools without bypassing the same underlying safety rules used by the CLI and REST API.
Copy-paste setup recipes for VS Code and Claude Desktop are in docs/MCP.md.
Boundary: AI may propose; humans approve state-changing repairs.
Where it fits next to popular data-quality projects
This is a positioning guide, not a winner/loser feature scorecard. These projects solve overlapping but different jobs; check their upstream documentation for current capabilities.
Project
Core mental model
A strong fit when you want...
DataSentry
discover → explain → repair → verify
automatic issue discovery plus a controlled, reversible remediation loop
fast exploratory profiling and shareable analysis reports
DataSentry is intentionally not trying to replace a metadata catalog, lineage platform, or every validator. Its focus is narrower: find bad data, show why it was flagged, and close the repair loop without gambling on the source.
Local-first by design
deterministic detection and scoring run locally;
DuckDB powers core local execution;
OpenAI/Ollama assistance is optional;
PII redaction, encrypted mappings, and LLM audit records are available when AI is enabled;
the original source file is not overwritten by repair workflows.
Data sources
CSV, Parquet, JSONL, XLSX
DuckDB and SQLite
PostgreSQL and MySQL
s3://, gs://, and az:// objects
single files, batches, and globs
History and drift
Persist scans and compare data over time:
datasentry drift latest orders
datasentry score
Tracked signals include schema changes, row-count movement, quality-score changes, and issue-distribution drift.
uv sync
uv run python benchmarks/bench_scan.py 1000000 42
The benchmark generates synthetic dirty data and measures profiling, detection/fusion/scoring, numeric-outlier detection, JSONL reading, sampling, score drift, and memory high-water marks. See docs/BENCHMARKS.md.
Development
uv sync
make check # lint + mypy --strict + tests/coverage
make demo # exercise the public datasentry demo path
make bench # benchmark
make build # distributions
Contributing
Useful contributions include new detectors, connectors, integration examples, reproducible benchmark cases, documentation/translations, minimal bug reproductions, and CLI/TUI/Web usability improvements.