Tonic.ai builds synthetic data for software tests and AI workflows

Tonic.ai supplies data tools for software development and AI: Fabricate generates synthetic datasets, Structural transforms structured production data for testing, and Textual handles sensitive information in unstructured material. The right starting point depends on what the team already has. Inventing data for a new feature is different from preserving the relationships in an existing database, and both differ from preparing support conversations for an AI workflow.

01 / ProductThree products serve three different starting conditions

The Tonic.ai overview presents data synthesis for application development, testing and AI model work. Fabricate uses a conversational Data Agent to create structured and unstructured data, with mock APIs and workflow features. This is useful when a new product needs a plausible test world before production examples exist.

Structural begins with existing databases and provides sensitive-data discovery, transformations and test-data provisioning. Preserving the shape of relationships matters: replacing customer names is not enough if orders no longer join to the right customer. A test dataset must exercise the application’s structure as well as hide or replace selected values.

Textual addresses text and other unstructured material through detection, redaction and synthesis of sensitive entities. The product also describes custom entity types. An organization-specific account reference may need different treatment from a common email address, and the team must check whether the transformed text still supports the intended AI task.

02 / AudienceChoose by the test problem before choosing a product

Fabricate is relevant to developers building a new feature, demonstration or simulated agent environment. Structural is relevant when bugs depend on the relationships and awkward cases already present in production. Textual is relevant when the useful signal lives in notes, documents or conversations that also contain sensitive information. A project can need more than one, but that does not make their plans or guarantees interchangeable.

A simple interface test may only need a few hand-authored fixtures. A complicated support agent may need a relational customer record, an order history and a conversation describing a failure. The latter needs consistency across sources. Start by specifying which relationships affect the expected outcome so the data effort supports the test instead of merely increasing its size.

The BigID blueprint provides adjacent context for finding and governing sensitive data across an estate. The Braintrust blueprint covers evaluation and tracing after an AI application receives its test inputs. Data preparation and evaluation complement one another: realistic inputs help expose failures, while a separate criterion decides whether the agent handled them correctly.

03 / WorkflowA proposed support-agent environment keeps records and messages consistent

Consider a proposed agent that reads order history and drafts a response to a delivery complaint. It must distinguish an order that is late from one that has been refunded, and it must not confuse two customers with similar names. Build a test environment with synthetic people, orders, shipments and messages. No production support account needs to be changed to exercise these decisions.

If the project is new, use Fabricate to describe the tables, relationships and cases required. Specify dates, statuses and constraints explicitly. Include a delivered order, a missing shipment, a partial refund and an order with incomplete tracking. Ask for a dataset that represents those scenarios, then verify it with ordinary database assertions rather than accepting plausibility as correctness.

If production structure is essential, evaluate Structural against an authorized source sample. Its sensitivity-scan documentation says it identifies built-in and custom sensitivity types, permits manual classification and ignores truncated tables. Review the actual detected columns and exclusions. A successful scan is evidence about the scanned material, not proof that every field in every database was considered.

Preserve the links the application uses. An order’s customer key, shipment reference and refund record should remain consistent after transformation. Also test repeated values that appear outside formal foreign keys, such as a reference embedded in a message. A dataset with correct individual tables can still fail the end-to-end journey if those references disagree.

Use Textual for the message corpus when there is a legitimate reason to transform source conversations. Define the entities whose treatment matters: names, emails, order references and any organization-specific codes. Inspect both missed detections and unnecessary substitutions. Removing every meaningful product or shipment reference could make the data less sensitive while also making the intended support evaluation impossible.

Connect the application to the resulting test data or mock API and evaluate the full behavior. Check which record was read, whether the agent chose the appropriate escalation and whether its response describes the actual order state. A fluent answer about the wrong customer is a failure even if the generated text looks realistic. Keep data-quality checks and agent-quality checks as separate results.

Version the schema, transformation configuration and generated scenario set. When a new application release fails, the team should be able to rerun against the same input conditions. Add deliberately constructed edge cases alongside statistically representative data; common patterns alone may omit the rare refund or ambiguous identity situation that produces a serious bug.

04 / PricingEach product uses a different commercial unit

Fabricate usage is token-based and grows with generation complexity and conversational iteration. The same page says generated data belongs to the user but reserves use of prompts and feedback to improve the Data Agent; confirm any applicable training opt-out and deployment terms before including sensitive material. Synthetic output does not make an uploaded prompt harmless.

For a pilot, budget generation, database preparation and text transformation separately. Record repeated runs and rejected outputs as well as the accepted dataset. Compare the cost of a reproducible scenario that exposes a failure, rather than the cheapest advertised subscription.

05 / DistinctionsThe useful distinction is controlled data across development stages

Tonic’s breadth connects two common engineering situations: needing data that does not yet exist and needing a safe version of data that already exists. The proposed support environment may begin with Fabricate and later require Structural as the production schema becomes more complicated. Textual addresses the free-text layer that a purely relational transformation can miss.

Fabricate’s mock APIs also give the team a way to exercise an application before its live dependencies are ready. A mock should reproduce the relevant response shape and failure conditions, however, not just return a successful sample. Include timeouts, missing records and unexpected status combinations in the test design where those conditions affect the agent’s decision.

For Structural, sensitive-data discovery and transformations are operational mechanisms rather than a universal privacy conclusion. For Textual, custom entity definitions offer a way to adapt detection to a company’s own vocabulary. The substantive evaluation question is whether the resulting data retains the signal needed for the test while removing the exposures identified for that specific use.

06 / QuestionsValidate fidelity, privacy and plan eligibility separately

Does the generated world contain the conditions that cause the real application to fail? Compare relationships, nulls, uncommon categories and time sequences, rather than checking only row counts. If every shipment is perfectly formed and every customer has a unique display name, the dataset may look attractive while missing the support agent’s hardest decisions.

What source material reaches hosted services during configuration or generation? A schema can contain revealing field names, and prompts may include examples copied from production. Confirm the chosen deployment and data-handling terms for the product actually used. Do not assume Structural’s deployment options apply automatically to an individual Fabricate subscription.

Can the team detect a transformation error independently? Use labeled samples for text detection and explicit integrity checks for tables. Inspect outputs as well as configuration screens. The product pages’ performance and compliance claims are vendor statements; this article does not establish a measured re-identification risk, a certified dataset or a reduction in production defects.

07 / DecisionStart with the smallest realistic environment that changes a decision

Tonic.ai is a useful candidate when engineering or AI work is blocked by unrealistic fixtures or uncontrolled copies of sensitive data. Select the product from the starting material, then define what a successful dataset must preserve and what it must replace. A small set of coherent customer journeys is often more useful than a large volume of unrelated synthetic records.

For the support agent, success means repeatable tests that distinguish late orders, refunds and ambiguous identities without using live customer accounts. Expand generation or source coverage after those journeys work and independent checks support the transformation. The decision rests on usable test evidence, not on synthetic data being inherently safe or automatically representative.