SQLite (developer evaluation) test data, inside your network

What works today

SQLite database files read through the Generic SQL connector with a verified read-only session, for local developer evaluation of the full workflow.

Configure a Generic SQL source with a URL such as sqlite:///file:/data/estate.db?mode=ro&uri=true.

Authentication: file permissions.

Known limitations

• Intended for local developer evaluation, not for production sources.
• A SQLite file has no credentials, so there is no separate read-only login to verify; read-only access comes from the file mode and query_only.

Capability matrix

Each capability is tracked separately and shown at the level the recorded conformance evidence supports. A connector that only discovers metadata is never presented as equivalent to one that runs the whole workflow.

Read-only proof

Proven per connection: the file is opened with mode=ro and every session runs with PRAGMA query_only = ON, which the connector reads back before any work.

Conformance evidence

DataNivra runs every connector through a common conformance kit on synthetic data: no write statements, proven read-only access, secret redaction, schema and relationship discovery, bounded streaming, cancellation, clear reason codes, egress canaries and no raw values in logs, then the discover, mask, subset, certify and provision workflow. The published status is computed from those results.

Connector version 0.1.0, last verified 2026-09-30.

What crosses the boundary

Connectors run inside the agent in your network. Only metadata, aggregates and evidence reach DataNivra Cloud:

• Schema, table and column names and data types (for file sets, operator-declared or opaque table names — never data-derived file names).
• Aggregates such as row-count estimates, null and distinct ratios; counts from 1 to 10 are reported as 10 (small-cell protection).
• Classification findings (which column looks like which kind of sensitive data) and relationship metadata.
• Evidence metadata: checksums, gate outcomes, engine and policy versions, and templated error codes.

Never sent:

• Any cell value, row, sample, minimum/maximum or top-k value — masked or not.
• Credentials, connection strings or resolved secret values: DataNivra stores only the secret reference.
• Free text copied from your data, or exception messages that contain values.

See the customer-resident architecture and how to verify these claims yourself.

Setup outline

1. Choose a SQLAlchemy dialect whose driver is present in your agent image. The standard image includes the PostgreSQL and SQLite drivers only.
2. Grant the credential read access only. For dialects other than PostgreSQL and SQLite the agent cannot prove this, so set read_only_attested only after you have applied least-privilege grants.
3. Store the connection document (the SQLAlchemy URL as a secret reference) in your secret store.
4. In the console, register the source with the secret reference of that document (for example vault://tdm/source-connection) and the agent that can reach it, then run discovery.

Example connection document, stored in your secret store and resolved by the agent locally (DataNivra only ever sees its reference):

{
  "kind": "GENERIC_SQL",
  "url_ref": "vault://tdm/orders-db#sqlalchemy_url",
  "schemas": ["orders"],
  "read_only_attested": false
}

Next: install the agent, then follow the getting started guide.