What teams use DataNivra for

A use case is a job a team needs done, not a feature list. The pages below start from the problem — flaky pipelines, environments nobody cleans up, defects that only appear with real records — and then describe exactly which DataNivra capabilities address it, which commands and API calls are involved, and where the limits are. Every page names the repository tests and examples its claims rest on and carries the date it was last reviewed. For the concepts behind them, start in the learning center or browse the topic hubs.

• Available now

  Test data for CI/CD pipelines

  How a build pipeline gets its own copy of a policy-certified dataset for each run, cleans it up afterwards and keeps value-free evidence - without the pipeline touching production.

• Available now

  Ephemeral test environments

  Short-lived, customer-controlled test environments hydrated with one certified dataset version and torn down on release or expiry - what works today and which targets are supported.

• Preview — usable, with documented limitations

  Reproducing production issues with masked data

  Recreate the records behind a production incident as a small, masked and certified dataset - seed lists stay in your network. A Preview that needs a newer agent release.

• Preview — usable, with documented limitations

  Unstructured and AI test data

  Mask documents, chat and ticket exports inside your network and generate synthetic RAG evaluation sets - a Preview with rule-based detection and its limits stated.

• Preview — usable, with documented limitations

  Detecting policy drift in lower environments

  Scan registered DEV, QA and UAT environments inside your network for unmasked copies and policy drift - a Preview that reports evidence, never values, and needs a newer agent.

Runnable scenarios

Each scenario below comes with a short script you can run yourself against synthetic files published on this site, the exact output it prints, the schema involved and its limits. DataNivra's test suite runs every script and compares the output, so the pages stay true as the downloads change. No account is needed.

• Runnable scenario

  Masked subsets or synthetic data — choosing per test

  When a test should run on synthetic data and when it needs a masked subset of real data, with a runnable check of the markers that make synthetic rows unmistakable.

• Runnable scenario

  Deterministic masking that keeps joins working

  A runnable example that pseudonymizes member ids in two synthetic healthcare tables with a keyed hash and proves every claim still joins to its member afterwards.

• Runnable scenario

  Relational subsetting without orphan rows

  A runnable comparison of naive row sampling and an entity-driven subset on synthetic claims data, counting the dangling references each one leaves behind.

• Runnable scenario

  Planning a test-data refresh cadence

  Read a pack's weekly refresh policy, compute the next refresh windows and see which settings stop needless rebuilds — a runnable example on a published policy template.

• Runnable scenario

  A synthetic PostgreSQL test database in foreign-key order

  Generate a psql load script for a synthetic multi-schema bundle — schemas, DDL and copies in foreign-key order — checked by a test that loads it into a real PostgreSQL server.

• Runnable scenario

  Synthetic test tables in a Databricks development catalog

  Turn a synthetic retail bundle into Delta table definitions and COPY INTO statements for a development catalog, and see where the Databricks connector fits for real sources.

• Runnable scenario

  Healthcare test scenarios from synthetic claims and clinical data

  Inventory the denials, pended claims, out-of-range labs, encounter types and refills present in a synthetic healthcare bundle, and map them to the pack's named scenarios.

• Runnable scenario

  Banking test scenarios — failed payments, chargebacks and frozen accounts

  Count the payment failures, chargebacks, fraud cases and account states in a synthetic banking bundle and check that every fraud case points at a real transaction.

• Runnable scenario

  Verified synthetic fixtures in GitHub Actions

  A GitHub Actions job that downloads synthetic fixtures, verifies each file against the bundle's published SHA-256 manifest, loads them into SQLite and checks relationships before tests run.

• Runnable scenario

  Customer-resident processing — verify the agent you run

  Check a published agent release against its SHA-256 list and confirm the Helm values pin the exact image digest, before the component that touches your data runs in your network.