Are the Telecommunications records on this page real?

No. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine. The masking example uses a fixed public sample key; your own data is masked with a key from your secret store.

How long does a first certified Telecommunications dataset take?

Estimates, not guarantees — try the synthetic sandbox: minutes; install (or reuse) the agent: under an hour; connect a source: under an hour; review and approve policies: under an hour; first certified dataset: minutes.

Which test scenarios does the Telecommunications pack include?

10 runnable scenarios (everyday usage, roaming spike, port in, port out and more), plus 1 negative-test scenario kept apart from valid data.

Do Telecommunications rows leave my network?

No. The DataNivra agent runs inside your environment: it reads the source, masks, subsets, generates and certifies there, and sends only metadata, aggregate counts and evidence to the DataNivra control plane (customer-resident processing, zero raw-production-data egress).

Industry packs

Telecommunications industry pack

Synthetic subscriber, line, usage and billing test data with linked masking

Preview only · not activatable yet Version 2.0.0 · Complete

Try with synthetic data Notify me — tell us you need it

Everything on this page works without an account. Prefer a conversation? Request a demo (optional). Missing something? Request a feature.

This pack is installed and passes DataNivra’s pack conformance kit through the real engine, but it cannot be activated yet: no plan includes it yet, the standard agent image does not ship it, the control-plane catalogue does not list it and the hosted sandbox has no synthetic estate for it. You can explore its synthetic records, masking and scenarios on this page and in the browser demo. Tell us if you need it: demand decides which packs become activatable next.

Problems this pack solves

Masked data that still joins across 5 systems

6 cross-system relationships link billing, care, crm, network and provisioning; the pack's masking keeps one pseudonym per identity on every side. For example, crm.subscribers.subscriber_id and provisioning.service_lines.subscriber_ref get the same pseudonym.

The cases production samples rarely contain

8 ready-made scenarios generate them on demand, for example: A burst of data sessions on visited networks within two days; numbers ported in from other operators, most completed; numbers ported out to other operators; their lines end as PORTED_OUT.

Sensitive fields found and masked before anyone sees them

32 columns across 10 entities are classified (credential, direct identifier, financial, PII, quasi identifier and sensitive) and covered by 3 masking templates you review and approve.

Evidence that each dataset is fit to use

2 certification presets check masking coverage, referential integrity, orphans and row counts before a dataset can be provisioned; a failed dataset is never provisioned.

Entities and relationships

10 entities across 5 source systems, generated from the pack’s own entity model.

Arrows point from the referencing entity to the one it references. Solid: a foreign key inside one system. Dashed: a cross-system relationship — the pack keeps the same pseudonym on both sides, so masked data still joins.

All 11 relationships as a table

Relationships of the Telecommunications pack
Entity	References	Columns	Kind
BillingAccount	Subscriber	`subscriber_id` → `subscriber_id`	Within a system
Sim	ServiceLine	`line_id` → `line_id`	Within a system
Device	ServiceLine	`line_id` → `line_id`	Within a system
PortRequest	ServiceLine	`line_id` → `line_id`	Within a system
BillPayment	Bill	`bill_id` → `bill_id`	Within a system
ServiceLine	Subscriber	`subscriber_ref` → `subscriber_id`	Across systems (pack relationship template)
ServiceLine	BillingAccount	`billing_account_ref` → `billing_account_id`	Across systems (pack relationship template)
UsageRecord	ServiceLine	`msisdn_ref` → `msisdn`	Across systems (pack relationship template)
Bill	BillingAccount	`billing_account_ref` → `billing_account_id`	Across systems (pack relationship template)
TroubleTicket	Subscriber	`subscriber_ref` → `subscriber_id`	Across systems (pack relationship template)
TroubleTicket	ServiceLine	`line_ref` → `line_id`	Across systems (pack relationship template)

Realistic synthetic records

Synthetic data. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine.

Entity

Subscriber — `crm.subscribers` (synthetic)
`subscriber_id` sensitive	`given_name` sensitive	`family_name` sensitive	`birth_date` sensitive	`national_id` sensitive	`email` sensitive	`phone` sensitive	`street_address` sensitive	`city` sensitive	`postal_code` sensitive	`country_code`	`segment`	`customer_since`
SUB000000001	Rosel	Zephridge	1974-02-05	NID-ZZ-2340640	rosel.caldton4039@example.org	—	5087 Cobalt Lane	Mirelhaven	88277	ZZ	CONSUMER	2013-01-03
SUB000000002	Iris	Oakstead	1984-01-02	NID-ZZ-4384645	—	—	1233 Silverlark Avenue	Neskwick	16767	ZZ	CONSUMER	2022-06-17

Masking: before and after

Template Linked telecom test data (TEL_LINKED_TEST_DATA) applied to a synthetic Subscriber record from crm.subscribers.

Synthetic record

Synthetic Subscriber record before and after masking
Column	Classified as	Before (synthetic)	After masking
`subscriber_id`	Direct identifier	`SUB000000001`	`SUB098977906`
`given_name`	PII, Direct identifier	`Rosel`	`Dorel`
`family_name`	PII, Direct identifier	`Zephridge`	`Caldbrook`
`birth_date`	PII, Quasi identifier	`1974-02-05`	`1974-01-24`
`national_id`	PII, Direct identifier	`NID-ZZ-2340640`	`KEU-WG-2378994`
`email`	PII, Direct identifier	`rosel.caldton4039@example.org`	`quinara.caldfield7853@example.com`
`phone`	PII, Direct identifier	`—`	`—` (same value after masking)
`street_address`	PII, Quasi identifier	`5087 Cobalt Lane`	`7613 Cobalt Drive`
`city`	Quasi identifier	`Mirelhaven`	`Quellmere`
`postal_code`	PII, Quasi identifier	`88277`	`36628`

Same pseudonym in two systems. The identifier SUB000000001 appears in crm.subscribers.subscriber_id and in provisioning.service_lines.subscriber_ref. Both become SUB098977906, so the masked systems still join (relationship TEL_LINE_SUBSCRIBER).

Masked with a fixed public sample key so this example is reproducible; your data is masked with your own key, referenced from your secret store.

Synthetic scenarios you can run

10 runnable scenarios. Preview them in your browser without an account; the hosted sandbox opens when the pack becomes activatable.

Everyday usage

Normal TEL_EVERYDAY_USAGE

Ordinary subscribers, lines, SIMs, handsets, usage, bills and care tickets

Everyday, valid records: the baseline most tests expect. Children per parent record: 1–3.

Preview in the browser demo: Everyday usage

Roaming spike

Rare TEL_ROAMING_SPIKE

A burst of data sessions on visited networks within two days

Valid but uncommon business situations that production samples often miss. Children per parent record: 3–8.

Preview in the browser demo: Roaming spike

Port in

Rare TEL_PORT_IN

Numbers ported in from other operators, most completed

Valid but uncommon business situations that production samples often miss. Children per parent record: 1–2.

Preview in the browser demo: Port in

Port out

Rare TEL_PORT_OUT

Numbers ported out to other operators; their lines end as PORTED_OUT

Valid but uncommon business situations that production samples often miss. Children per parent record: 1–2.

Preview in the browser demo: Port out

Disputed bills

Rare TEL_DISPUTED_BILLS

Disputed bills with a reason, and billing tickets raised by the subscriber

Valid but uncommon business situations that production samples often miss. Children per parent record: 1–3.

Preview in the browser demo: Disputed bills

Device swaps

Rare TEL_DEVICE_SWAPS

Several handsets per line: older ones swapped out, one in use

Valid but uncommon business situations that production samples often miss. Children per parent record: 2–4.

Preview in the browser demo: Device swaps

Network outage

Rare TEL_NETWORK_OUTAGE

No-service tickets and very short calls concentrated in one cell over a few hours

Valid but uncommon business situations that production samples often miss. Children per parent record: 2–5.

Preview in the browser demo: Network outage

Heavy data usage

Boundary TEL_HEAVY_DATA_USAGE

Data sessions at or above the heavy-usage threshold (exactly at it for every tenth row)

Values at the edges of valid ranges (limits, thresholds, extremes). Children per parent record: 1–3.

Preview in the browser demo: Heavy data usage

Duplicate cdrs

Duplicate TEL_DUPLICATE_CDRS

Usage records delivered twice by mediation with identical content under new ids

Records that repeat others under new keys (clean-up and matching tests). Children per parent record: 2–5.

Preview in the browser demo: Duplicate cdrs

Subscriber histories

Historical TEL_SUBSCRIBER_HISTORIES

Multi-year, referentially intact subscriber, usage and billing histories without gaps

Old records for archive, migration and retention tests. Children per parent record: 2–4.

Preview in the browser demo: Subscriber histories

Negative tests, kept apart. This scenario produces deliberately broken data for error handling and never passes certification as valid data:

TEL_BROKEN_REFERENCES — Dangling cross-system references and invalid values for error-handling tests

Sample schemas and representative outputs

The schema the pack expects in each system (also as CREATE TABLE DDL in the downloads). A run produces a masked or synthetic dataset with the same tables, a certification report with the gates of the chosen preset, and an evidence manifest with checksums — the rows stay in your environment.

Subscriber — crm.subscribers · 13 columns

A person or small business with one or more service lines (the natural subset root).

Column	Type	Required	Sensitive classes
`subscriber_id` (key)	`VARCHAR(12)`	Yes	Direct identifier
`given_name`	`VARCHAR(64)`	Yes	PII, Direct identifier
`family_name`	`VARCHAR(64)`	Yes	PII, Direct identifier
`birth_date`	`DATE`	No	PII, Quasi identifier
`national_id`	`VARCHAR(16)`	No	PII, Direct identifier
`email`	`VARCHAR(128)`	No	PII, Direct identifier
`phone`	`VARCHAR(32)`	No	PII, Direct identifier
`street_address`	`VARCHAR(128)`	No	PII, Quasi identifier
`city`	`VARCHAR(64)`	No	Quasi identifier
`postal_code`	`VARCHAR(10)`	No	PII, Quasi identifier
`country_code`	`VARCHAR(2)`	Yes	—
`segment`	`VARCHAR(16)`	Yes	—
`customer_since`	`DATE`	Yes	—

BillingAccount — crm.billing_accounts · 8 columns

The account a subscriber's lines are billed to.

Column	Type	Required	Sensitive classes
`billing_account_id` (key)	`VARCHAR(12)`	Yes	Direct identifier
`subscriber_id`	`VARCHAR(12)`	Yes	Direct identifier
`bill_cycle_day`	`INT`	Yes	—
`payment_method`	`VARCHAR(16)`	Yes	—
`payer_iban`	`VARCHAR(34)`	No	Financial, Direct identifier
`mandate_reference`	`VARCHAR(20)`	No	Financial, Direct identifier
`credit_class`	`VARCHAR(2)`	Yes	—
`status`	`VARCHAR(12)`	Yes	—

ServiceLine — provisioning.service_lines · 8 columns

A subscription with a phone number (MSISDN), billed to one of the subscriber's accounts.

Column	Type	Required	Sensitive classes
`line_id` (key)	`BIGINT`	Yes	—
`msisdn`	`VARCHAR(16)`	Yes	PII, Direct identifier
`subscriber_ref`	`VARCHAR(12)`	Yes	Direct identifier
`billing_account_ref`	`VARCHAR(12)`	Yes	Direct identifier
`plan_code`	`VARCHAR(16)`	Yes	—
`status`	`VARCHAR(12)`	Yes	—
`activated_on`	`DATE`	Yes	—
`roaming_enabled`	`BOOLEAN`	Yes	—

Sim — provisioning.sims · 5 columns

A SIM card issued for a line (a line can have a replaced SIM in its history).

Column	Type	Required	Sensitive classes
`iccid` (key)	`VARCHAR(20)`	Yes	Direct identifier
`line_id`	`BIGINT`	Yes	—
`imsi`	`VARCHAR(15)`	Yes	PII, Direct identifier
`status`	`VARCHAR(10)`	Yes	—
`issued_on`	`DATE`	Yes	—

Device — provisioning.devices · 6 columns

A handset observed on a line (swaps leave the old handset as SWAPPED_OUT).

Column	Type	Required	Sensitive classes
`handset_id` (key)	`BIGINT`	Yes	—
`line_id`	`BIGINT`	Yes	—
`imei`	`VARCHAR(15)`	Yes	Direct identifier
`make_model`	`VARCHAR(32)`	Yes	—
`status`	`VARCHAR(12)`	Yes	—
`first_seen`	`DATE`	Yes	—

PortRequest — provisioning.port_requests · 7 columns

A number-porting request moving a number into or out of the operator.

Column	Type	Required	Sensitive classes
`port_id` (key)	`BIGINT`	Yes	—
`line_id`	`BIGINT`	Yes	—
`direction`	`VARCHAR(8)`	Yes	—
`other_operator`	`VARCHAR(12)`	Yes	—
`port_auth_code`	`VARCHAR(10)`	No	Credential
`status`	`VARCHAR(10)`	Yes	—
`requested_at`	`TIMESTAMP`	Yes	—

UsageRecord — network.usage_records · 11 columns

A call detail record: one voice call, SMS or data session of a line.

Column	Type	Required	Sensitive classes
`record_id` (key)	`BIGINT`	Yes	—
`msisdn_ref`	`VARCHAR(16)`	Yes	PII, Direct identifier
`record_type`	`VARCHAR(8)`	Yes	—
`counterparty_number`	`VARCHAR(16)`	No	PII, Direct identifier
`event_start`	`TIMESTAMP`	Yes	Quasi identifier
`duration_seconds`	`INT`	Yes	—
`data_kb`	`BIGINT`	Yes	—
`cell_id`	`VARCHAR(12)`	Yes	Quasi identifier
`roaming`	`BOOLEAN`	Yes	—
`visited_network`	`VARCHAR(12)`	No	—
`charge_amount`	`DECIMAL(10,2)`	Yes	—

Bill — billing.bills · 7 columns

A monthly bill of a billing account.

Column	Type	Required	Sensitive classes
`bill_id` (key)	`BIGINT`	Yes	—
`billing_account_ref`	`VARCHAR(12)`	Yes	Direct identifier
`period_start`	`DATE`	Yes	—
`due_date`	`DATE`	Yes	—
`amount_due`	`DECIMAL(12,2)`	Yes	Financial
`status`	`VARCHAR(10)`	Yes	—
`dispute_reason`	`VARCHAR(20)`	No	—

BillPayment — billing.bill_payments · 8 columns

A payment (or failed collection) against a bill.

Column	Type	Required	Sensitive classes
`payment_id` (key)	`BIGINT`	Yes	—
`bill_id`	`BIGINT`	Yes	—
`amount`	`DECIMAL(12,2)`	Yes	Financial
`paid_at`	`TIMESTAMP`	Yes	—
`method`	`VARCHAR(16)`	Yes	—
`payer_iban`	`VARCHAR(34)`	No	Financial, Direct identifier
`payment_reference`	`VARCHAR(20)`	Yes	Financial, Direct identifier
`status`	`VARCHAR(10)`	Yes	—

TroubleTicket — care.trouble_tickets · 7 columns

A customer-care ticket about service, billing, a device or porting.

Column	Type	Required	Sensitive classes
`ticket_id` (key)	`BIGINT`	Yes	—
`subscriber_ref`	`VARCHAR(12)`	Yes	Direct identifier
`line_ref`	`BIGINT`	No	—
`category`	`VARCHAR(12)`	Yes	—
`status`	`VARCHAR(10)`	Yes	—
`opened_at`	`TIMESTAMP`	Yes	—
`description`	`VARCHAR(400)`	No	Sensitive

Compatible connectors

Verified with this pack version: PostgreSQL and Local files (Parquet / CSV). 17 more connectors are compatible by capability: they support what the pack needs, but have not been verified with this pack yet.

Connector	Status with Telecommunications
Local files (Parquet / CSV)	Verified with this pack
PostgreSQL	Verified with this pack
Amazon S3 / S3-compatible storage	Compatible by capability (not yet verified with this pack)
Apache Kafka (connector in preview)	Compatible by capability (not yet verified with this pack)
Azure Blob Storage / Data Lake Storage	Compatible by capability (not yet verified with this pack)
Databricks	Compatible by capability (not yet verified with this pack)
Generic SQL (SQLAlchemy)	Compatible by capability (not yet verified with this pack)
Google BigQuery	Compatible by capability (not yet verified with this pack)
HTTP APIs (connector in preview)	Compatible by capability (not yet verified with this pack)
IBM Db2 (connector in preview)	Compatible by capability (not yet verified with this pack)
Mainframe files (EBCDIC / copybook) (connector in preview)	Compatible by capability (not yet verified with this pack)
MariaDB	Compatible by capability (not yet verified with this pack)
Microsoft SQL Server	Compatible by capability (not yet verified with this pack)
MongoDB (connector in preview)	Compatible by capability (not yet verified with this pack)
MySQL	Compatible by capability (not yet verified with this pack)
Oracle Database	Compatible by capability (not yet verified with this pack)
Parquet files	Compatible by capability (not yet verified with this pack)
Snowflake	Compatible by capability (not yet verified with this pack)
SQLite (developer evaluation) (connector in preview)	Compatible by capability (not yet verified with this pack)

Prerequisites and expected setup effort

You need

This pack is not in any plan yet.
One DataNivra agent inside your network (outbound HTTPS only) that ships Telecommunications 2.0.0.
Read-only access to a compatible source (verified with this pack: PostgreSQL, Local files (Parquet / CSV)).
A non-production target environment the agent may write test data to.
A masking key in your own secret store, referenced as vault://…, azure-kv://… or env://… (DataNivra only ever sees the reference).
For production sources, a second person who approves policies (separation of duties).

A DataNivra agent that reports its installed industry packs (releases after agent 0.3.0); the control plane runs a pack job only on an agent holding the exact active pack version with the catalogued integrity digest.

Expected setup effort (estimates)

Step	Estimate
Try the synthetic sandbox No install: sign up and open the sandbox.	Minutes (estimate)
Install (or reuse) the agent One Docker command or a Helm chart; outbound HTTPS only.	Under an hour (estimate)
Connect a source Register a read-only source through the existing connector workflow.	Under an hour (estimate)
Review and approve policies Create drafts from the Telecommunications templates, review and approve them.	Under an hour (estimate)
First certified dataset Run the first job; certification and evidence are produced automatically.	Minutes (estimate)

Certification presets in plain language

`TEL_STRICT`

Every gate; full masking coverage; zero orphaned lines, SIMs, handsets, usage records, bills, payments or tickets; exact row counts. Default for masked telecom test data.

Masking coverage of at least 100% of sensitive columns
No orphaned child records
Empty-value ratio may rise by at most 5%
Row counts must match exactly

16 gates it requires

POLICY_COVERAGE: every sensitive column is covered by an approved policy
MASKING_COMPLETION: masking finished on every covered column
REFERENTIAL_INTEGRITY: every reference still points at an existing record
SCHEMA_VALIDATION: the output schema matches the source schema
DATA_QUALITY: empty-value ratios stay within the preset’s drift limit
ROW_COUNT_RECONCILIATION: row counts match the plan within the tolerance
ORPHAN_DETECTION: no child record lost its parent
PROVENANCE: every row is tagged masked or synthetic
MANIFEST: a manifest lists every output table with checksums
POLICY_VERSION: the exact approved policy versions are recorded
ENGINE_VERSION: the engine version is recorded
CHECKSUMS: output checksums are recorded for later verification
IDENTITY_CONSISTENCY: linked identifiers got the same pseudonym in every system
SOURCE_READ_ONLY: the source was only read, never written
EGRESS_GUARD: no row-level data left the agent
CONNECTOR_HEALTH: the connectors stayed healthy during the run

`TEL_SCENARIO_TESTING`

Every gate, with slightly relaxed NULL-ratio drift for scenario datasets whose business states (ported-out lines, data-only sessions without counterparties) leave optional fields empty.

Masking coverage of at least 100% of sensitive columns
No orphaned child records
Empty-value ratio may rise by at most 15%
Row counts must match exactly

16 gates it requires

POLICY_COVERAGE: every sensitive column is covered by an approved policy
MASKING_COMPLETION: masking finished on every covered column
REFERENTIAL_INTEGRITY: every reference still points at an existing record
SCHEMA_VALIDATION: the output schema matches the source schema
DATA_QUALITY: empty-value ratios stay within the preset’s drift limit
ROW_COUNT_RECONCILIATION: row counts match the plan within the tolerance
ORPHAN_DETECTION: no child record lost its parent
PROVENANCE: every row is tagged masked or synthetic
MANIFEST: a manifest lists every output table with checksums
POLICY_VERSION: the exact approved policy versions are recorded
ENGINE_VERSION: the engine version is recorded
CHECKSUMS: output checksums are recorded for later verification
IDENTITY_CONSISTENCY: linked identifiers got the same pseudonym in every system
SOURCE_READ_ONLY: the source was only read, never written
EGRESS_GUARD: no row-level data left the agent
CONNECTOR_HEALTH: the connectors stayed healthy during the run

Activation status

What is missing before you can activate the Telecommunications pack yourself:

no plan includes it yet
the standard agent image does not ship it
the control-plane catalogue does not list it
the hosted sandbox has no synthetic estate for it

Until then, preview it in the browser demo and download its synthetic asset bundle below.

Tell us you need the Telecommunications pack or request a feature for it.

Downloads

Version 2.0.0, 62 files (202.4 KB), all synthetic and generated from the pack itself. Every file’s SHA-256 is listed in MANIFEST.json.

Start here (2)

QUICKSTART.md 2.8 KB · SHA-256 442cf940f9d7…
TROUBLESHOOTING.md 4.7 KB · SHA-256 5c9c33cd5215…

Entity–relationship diagram (2)

er-diagram.mmd 4.0 KB · SHA-256 d98f231d0dd3…
er-diagram.svg 7.2 KB · SHA-256 5c7dadcc750c…

Sample schemas (6)

schema/billing.sql 1.2 KB · SHA-256 52b447972641…
schema/care.sql 735 B · SHA-256 225e9b6a64bd…
schema/crm.sql 1.9 KB · SHA-256 155185442a10…
schema/entities.json 25.5 KB · SHA-256 4b22ae2e3f3a…
schema/network.sql 976 B · SHA-256 3b6c1c13613a…
schema/provisioning.sql 2.2 KB · SHA-256 f5de8f449cfb…

Policy templates (9)

policies/README.md 1.3 KB · SHA-256 b3896785eeb3…
policies/TEL_ANALYTICS_UNLINKED.json 15.8 KB · SHA-256 20c874b7703c…
policies/TEL_CLASSIFICATION.json 203 B · SHA-256 17934ac5cf27…
policies/TEL_LINKED_TEST_DATA.json 17.0 KB · SHA-256 04fcd00894fc…
policies/TEL_REFRESH_WEEKLY.json 190 B · SHA-256 e54930bed540…
policies/TEL_SCENARIO_TESTING.json 549 B · SHA-256 a0728ad1a443…
policies/TEL_STRICT.json 549 B · SHA-256 df479db4f4bb…
policies/TEL_SUBSET_DEFAULT.json 112 B · SHA-256 d46c49c10d7c…
policies/TEL_TRAFFIC_MINIMISED.json 17.3 KB · SHA-256 6006af5c3174…

API, CLI, SDK and CI/CD examples (10)

api/curl.sh 2.5 KB · SHA-256 09b3bbf7f2ff…
api/dataset-request.json 1.5 KB · SHA-256 196a4ea41c78…
api/policy-approval.json 155 B · SHA-256 d55e632a5036…
api/policy-drafts.json 162 B · SHA-256 1e25229c4597…
api/provision.json 63 B · SHA-256 7f02a6a87792…
api/sandbox.json 35 B · SHA-256 caa1595e2a13…
ci/README.md 497 B · SHA-256 6cb0437fa704…
ci/github-actions.yml 1.8 KB · SHA-256 6bc591155531…
cli.md 1.7 KB · SHA-256 2b977d472625…
sdk_example.py 1.6 KB · SHA-256 074be09c2cef…

Synthetic sample data (CSV, JSON, Parquet) (31)

synthetic/SYNTHETIC_MANIFEST.json 2.3 KB · SHA-256 5cef74425910…
synthetic/billing.bill_payments.csv 1.8 KB · SHA-256 a728b1ca4e62…
synthetic/billing.bill_payments.json 5.2 KB · SHA-256 dc770d998b7b…
synthetic/billing.bill_payments.parquet 3.7 KB · SHA-256 54a2f714cab8…
synthetic/billing.bills.csv 1.5 KB · SHA-256 0016713d553d…
synthetic/billing.bills.json 5.8 KB · SHA-256 ebb25383d0b3…
synthetic/billing.bills.parquet 2.8 KB · SHA-256 cd7e710c94ae…
synthetic/care.trouble_tickets.csv 860 B · SHA-256 1bc688fd9978…
synthetic/care.trouble_tickets.json 1.8 KB · SHA-256 e0441d2157ee…
synthetic/care.trouble_tickets.parquet 3.1 KB · SHA-256 342d0646779e…
synthetic/crm.billing_accounts.csv 679 B · SHA-256 321be2be1867…
synthetic/crm.billing_accounts.json 2.1 KB · SHA-256 97553f0baf86…
synthetic/crm.billing_accounts.parquet 2.9 KB · SHA-256 0aa20f953845…
synthetic/crm.subscribers.csv 905 B · SHA-256 b949500dda0c…
synthetic/crm.subscribers.json 2.2 KB · SHA-256 fd65df2cfaa0…
synthetic/crm.subscribers.parquet 4.5 KB · SHA-256 a2f8667a0b26…
synthetic/network.usage_records.csv 4.5 KB · SHA-256 8f664d3123a9…
synthetic/network.usage_records.json 18.0 KB · SHA-256 bf275204fd76…
synthetic/network.usage_records.parquet 5.2 KB · SHA-256 b9d8b83f09e3…
synthetic/provisioning.devices.csv 538 B · SHA-256 015aa1ac3137…
synthetic/provisioning.devices.json 1.6 KB · SHA-256 5bd01182a5f4…
synthetic/provisioning.devices.parquet 2.3 KB · SHA-256 0e8ed8e7492a…
synthetic/provisioning.port_requests.csv 370 B · SHA-256 b105f8ff18c4…
synthetic/provisioning.port_requests.json 982 B · SHA-256 4f1062be21c8…
synthetic/provisioning.port_requests.parquet 2.5 KB · SHA-256 c178fee89acc…
synthetic/provisioning.service_lines.csv 790 B · SHA-256 fc2c16f25e0e…
synthetic/provisioning.service_lines.json 2.3 KB · SHA-256 8ab38808325c…
synthetic/provisioning.service_lines.parquet 2.7 KB · SHA-256 bf3fbb9a7dbc…
synthetic/provisioning.sims.csv 579 B · SHA-256 bcca630e5841…
synthetic/provisioning.sims.json 1.4 KB · SHA-256 8d03e3ffa47f…
synthetic/provisioning.sims.parquet 1.9 KB · SHA-256 86a21ca45630…

Troubleshooting

The reason codes you can meet on the way, with the recovery step. Every code is also in the error-code catalog.

SANDBOX_PACK_NOT_OFFERED — Synthetic estate not offered: A requested synthetic estate (industry pack) is not available in the hosted sandbox. What to do: Start the sandbox with the default estates.
ENTITLEMENT_REQUIRED — Plan does not include this: Your plan does not include this feature or industry pack. What to do: Upgrade in Billing & Plan.
PACK_INTEGRITY_UNVERIFIED — Pack integrity not verified: This pack version was registered without an integrity digest, so it cannot be activated (fail closed). What to do: Ask your operator to re-register the pack catalogue with the current control-plane image (register-pack), then activate again.
PACK_DEPENDENCY_INACTIVE — Required pack not active: This pack depends on another industry pack that is not active for your organization. What to do: Activate the packs this pack depends on first, then activate it again.
AGENT_PACK_MISSING — No agent can run this industry pack: The job's agent does not report the pack (older agents report no packs at all), so the job was not sent. What to do: Upgrade the agent to a release that reports its installed packs and ships this pack, then run the request again.
AGENT_PACK_VERSION_INCOMPATIBLE — Industry pack version differs on the agent: The agent holds a different version of the pack than the one the job was approved for. What to do: Deploy an agent with the pack's active version, or roll the pack back in Industry packs.
AGENT_PACK_INTEGRITY_MISMATCH — Agent pack differs from the catalogue: The agent reports the pack's version with a different integrity digest than the catalogued one, so the job was not sent. What to do: Redeploy the agent from the official signed image for this release, then run the request again.
PACK_TEMPLATES_UNAVAILABLE — Pack templates not registered: This pack version was registered without its policy templates. What to do: Ask your operator to re-register the pack catalogue (register-pack); create policies manually meanwhile.
PACK_TEMPLATE_KEY_REF_REQUIRED — Masking key reference required: A selected template keeps identities linked across systems and needs your masking key reference. What to do: Provide key_ref, e.g. vault://your-vault/tdm-masking-key, then create the drafts again.
PACK_NOT_ENABLED — Industry pack not enabled: The industry pack is not enabled for this tenant. What to do: Enable the pack (if your plan includes it).

Frequently asked questions

Are the Telecommunications records on this page real?: No. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine. The masking example uses a fixed public sample key; your own data is masked with a key from your secret store.
Can I activate the Telecommunications pack myself?: This pack is installed and passes DataNivra’s pack conformance kit through the real engine, but it cannot be activated yet: no plan includes it yet, the standard agent image does not ship it, the control-plane catalogue does not list it and the hosted sandbox has no synthetic estate for it. You can explore its synthetic records, masking and scenarios on this page and in the browser demo. Tell us if you need it: demand decides which packs become activatable next.
Which databases and files does the Telecommunications pack work with?: Verified with this pack version: PostgreSQL and Local files (Parquet / CSV). 17 more connectors are compatible by capability: they support what the pack needs, but have not been verified with this pack yet.
How long does a first certified Telecommunications dataset take?: Estimates, not guarantees — try the synthetic sandbox: minutes; install (or reuse) the agent: under an hour; connect a source: under an hour; review and approve policies: under an hour; first certified dataset: minutes.
Which test scenarios does the Telecommunications pack include?: 10 runnable scenarios (everyday usage, roaming spike, port in, port out and more), plus 1 negative-test scenario kept apart from valid data.
Do Telecommunications rows leave my network?: No. The DataNivra agent runs inside your environment: it reads the source, masks, subsets, generates and certifies there, and sends only metadata, aggregate counts and evidence to the DataNivra control plane (customer-resident processing, zero raw-production-data egress).

Learn the concepts, then come back to activate

Regulatory context

The Telecommunications pack covers data that laws and industry rules often treat as sensitive. It supports your privacy and governance programmes by keeping those records inside your environment and producing certification evidence; it does not, by itself, make any system or organisation compliant with any law, regulation or standard.

Try with synthetic data Notify me — tell us you need it

Everything on this page works without an account. Prefer a conversation? Request a demo (optional). Missing something? Request a feature.