Limitations

Written from testing our own output. If another page seems to say otherwise, this page wins.

What is exact, and what is not#

• Exact: every number you state (a total, a balance, a rate, a share, an average, by month), every foreign key, every declared rule, and the identities in the answer key. Each is read back in SQL on the certificate.
• Realistic, not stated: seasons, hours and weekdays, concentration (a few customers buying most), repeat behaviour, waits between steps. They come from the business's mechanics and are reported as observations, not guarantees.
• Anything that cannot hold is said, not bent. If two of your numbers cannot both hold, or one cannot be reached, it is listed as not met, with why. Some requests come back with an honest gap.

Numbers#

• Rates round to whole rows. 2% of 4,824 rows is 96 or 97 rows: 1.99% or 2.01%. The certificate shows the figure reached.
• A drawn curve sets totals, not rates. Draw monthly revenue or volume; state a changing rate in words ("2%, spiking to 5% in Q3").
• Not yet held as stated numbers: retention cohorts (day 1, day 7, day 30), and on your own tables, revenue computed from a catalogue-price formula. Both are generated, not held.
• Correlations exist only where something puts them there: a built-in shape's mechanics, a rule you state (a total that moves with income), or the realism pass. Misata does not learn from real data, so subtler real-world dependence is absent unless one of those sets it.

Businesses#

• Strongest: B2B SaaS, e-commerce, banking and payments, health systems. Built-in shapes with a full answer key (standard metrics, their SQL and their usual misreadings).
• Strong, smaller key: schools, anti-money laundering, machines and sensors, clinical trials, CRO finance.
• Any other business: designed from your description or your tables. Stated numbers still hold exactly and integrity still holds, but the answer key is thinner (the numbers you stated, plus the standard metrics proposed for your schema that run on the rows), and results vary more between builds. Read the plan before building.
• Known gaps in the SaaS shape: sales reps' territories do not follow where their accounts are, and a segment named for a size ("SMB agencies") does not set headcount.

Content#

• Text is assembled. Reviews, notes and ticket bodies are built from lines a model writes for your business, chosen to fit each row (a low rating reads as a complaint). In large tables the same lines return.
• The expert review is a model's opinion. It reads the finished data and flags what looks wrong; code checks every fix before it is applied. It catches a great deal, not everything.
• Research can bring in a fact that does not belong. Facts from the web are kept only when their quoted words appear on the source page, and every source is listed on the dataset, but relevance is judged by a model.

The answer key and the checker#

• The key's SQL is DuckDB's. The checker reads Postgres to_char and MySQL date_format where they mean the same as DuckDB's strftime; other dialect-specific functions are left as written, with what to change.
• The checker names the misreadings it knows. A query that is wrong in a way no known misreading explains is reported as not matching, with the closest metric, but without a named cause.

Speed and size#

• A build takes about one to two minutes. The rows take seconds. The rest is the models writing the business's content and the expert review. A rebuild, an adjustment or a tune runs by code alone, in seconds.
• Size: Studio builds up to about 10 million rows per dataset, in parts with totals still exact across them; star-schema and single-table layouts stop at about 3 million. The MCP server caps a dataset at 25,000 rows unsigned and 100,000 signed in.
• Repeatable per engine version. The same request and seed rebuild the same data while the engine version and the stored model answers are unchanged. An upgrade can change individual values; the stated numbers, keys and rules still hold.

Files and connections#

• Files are kept for a limited time (up to 14 days); the recipe is kept with your account, so an expired dataset rebuilds exactly with one click. The MCP server keeps a dataset for two hours.
• Loading a database: the platform API loads Postgres and ClickHouse directly, over an encrypted connection to a host on the public internet; private networks are refused. Studio itself hands over files and ready-made load scripts.
• A build on your own model key stops if the server restarts. Builds on the platform's model are taken up again under the same id; a build on your own key is not, since the key is never stored.

Out of scope#

Anonymising or copying real data, training data for text-to-SQL models, images, and live streaming data.