DataNivra — Realistic test data for humans, CI/CD pipelines, and autonomous AI agents. Production data stays home.

What Test Data Management (TDM) is — and what DataNivra already does

Test Data Management prepares the data that development, QA, SIT, UAT, performance and compliance testing run on. DataNivra is a full, human-operated TDM system: data discovery and classification, subsetting with referential integrity, consistent masking, synthetic generation, certification against your policy gates, provisioning, refresh, industry scenarios, audit, security and governance — with every row-level step inside your environment.

• Available

  Manage test data in the console

  Discovery, classification, subsetting, masking, synthesis, certification, provisioning, refresh, approvals and audit — run by your TDM team.

  Explore TDM Platform

• Available · works with GitHub Actions

  Automate with the Test Data API

  Approved profiles that developers, CI/CD pipelines and AI agents invoke through REST, the CLI, YAML/JSON manifests and Python/TypeScript helpers.

  Build with Test Data API

• Synthetic data only

  Explore runnable examples

  Synthetic scenarios across healthcare, banking, insurance, retail, SaaS and manufacturing, with CI recipes and expected output.

  View runnable examples

From production to a policy-certified test dataset

Teams copy production into DEV, QA and UAT because tests need realistic, connected data — and every copy spreads sensitive records into places they were never meant to be. DataNivra replaces those copies with right-sized, masked or synthetic datasets that keep relationships intact, are certified against your configured policy gates before use and refresh on a schedule.

1. 1

   Connect

   Register sources by secret reference. The agent resolves credentials from your own secret store and connects out — never in.

2. 2

   Discover

   Profile schemas and classify sensitive columns locally. Findings are column names, classes and counts — never sample values.

3. 3

   Subset

   Choose business entities; DataNivra follows relationships across tables and systems so no key dangles.

4. 4

   Mask / Synthesize

   Deterministic, keyed masking keeps joins working. Synthesize the records and edge cases production does not have.

5. 5

   Certify

   Gates check policy coverage, masking, referential integrity, schema and provenance. A failed dataset is never provisioned.

6. 6

   Provision

   Deliver to DEV, QA, SIT, UAT and performance targets, refresh on schedule and expire by retention policy.

All six steps run in your environment DataNivra Cloud coordinates: approvals, requests, job state and evidence references

One engine, two ways in: the architecture

1. How DataNivra protects and processes data

2. How humans, CI pipelines and agents consume the same service

Profiles and requests in YAML, JSON, TypeScript, Python, CLI, CI and MCP

A TestDataProfile is the reviewed, privileged definition; a TestDataRequest is the low-privilege invocation that pins one approved version. Every example below uses the real field names, routes and flags.

# yaml-language-server: $schema=https://www.datanivra.com/schemas/v1/manifests/test-data-profile.schema.json
apiVersion: datanivra.io/v1alpha1
kind: TestDataProfile
metadata:
  name: healthcare-integration
  description: Masked patients with synthetic appointments for integration tests
spec:
  fulfilment: BUILD_DATASET
  build:
    business_domain: patient appointments
    pack_id: healthcare
    dataset_kind: HYBRID
    source_ids: [00000000-0000-4000-8000-000000000011]   # approved PostgreSQL source (synthetic id)
    subset:
      id: 00000000-0000-4000-8000-000000000021
      name: patients-with-appointments
      root_entity: {schema_name: clinic, table_name: patients}
      strategy: FIXED_COUNT
      fixed_count: 500                                    # relationships are preserved by closure
    masking_policy:
      policy_id: 00000000-0000-4000-8000-000000000031
      kind: MASKING
      version: 3
      checksum: 2c9f7a1e0b8d6c4f3e2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e
    target_environment_id: 00000000-0000-4000-8000-000000000041   # the approved QA target
    retention_days: 1
    max_total_records: 2500
    scenarios:                                            # real healthcare-pack scenarios
      - {pack_id: healthcare, scenario_code: HC_ROUTINE_CARE, kind: NORMAL, default_count: 500, max_count: 500}
      - {pack_id: healthcare, scenario_code: HC_CHRONIC_CARE, kind: HIGH_VOLUME, default_count: 2000, max_count: 2000}
  automation:                                             # used only if automatic approval is enabled
    workload_identity_ids: [00000000-0000-4000-8000-0000000000a1]
    max_live_requests: 10
    escalate_out_of_envelope: true
  audit_tags: [HEALTHCARE_CI]

Built for CI/CD: a policy-certified dataset per build

# A pipeline step on a runner inside your network
datanivra datasets request create ci/dataset-request.json \
  --idempotency-key "ci-$BUILD_ID" -o json
# exit 0 only if the job succeeded; then check the certification report
datanivra jobs wait "$JOB_ID" --timeout 1800
datanivra certify reports --dataset-id "$DATASET_ID" -o json
# …run your tests, then revoke: the agent deprovisions the data

Two ways to work, kept apart

Start in the synthetic playground with no data at all. Move to customer-resident workflows on your own systems when you are ready — the same steps, run inside your network.

Questions and limitations

Is DataNivra still a Test Data Management system?

Yes. The console, agent, connectors, policies, certification and industry packs stay the product. The Test Data API is a second way to use the same customer-resident engine.

Does DataNivra run our tests?

No. Your QA tools and runners execute tests. DataNivra prepares and governs the data and the approved targets those tests use.

Can a pipeline or AI agent give itself access?

No. People define and approve profiles and envelopes with separation of duties; a request can only choose within an approved profile, and the server enforces it.

Do production rows or database credentials reach CI logs or DataNivra Cloud?

No. Row-level work runs in your network, targets are secret references resolved by your agent, and API responses carry metadata only.

Can any hosted runner reach our databases?

Not by default. Tests must run on a runner that can reach the approved target, such as a self-hosted or network-connected runner.

Are the SDKs on npm and PyPI?

Yes. pip install datanivra-sdk (and datanivra-cli, datanivra-mcp) from PyPI, and npm install @datanivra/sdk from npm, under the DataNivra proprietary licence.