Data handling
You are being asked to upload financial statements and a customer list to software you have never used. This page is the whole path that file takes, in order, with the parts that are permanent marked as permanent.
Where a language model is usedSecurity
Nothing is shared between accounts. No customer data is used to train anything, ever.
The path
There is no fifth step where the file is copied somewhere for analysis. This is the complete list.
The extension is checked against the allowed list, which ships as csv, tsv, txt, md, json, docx, pdf and xlsx. The size is checked against the limit, which ships at 25 megabytes. It is then moved into a private folder that belongs to your account, in a subfolder for that twin, under a filename with a timestamp and six random characters in front of it. It is never published, never given a public address and never previewed.
A spreadsheet or CSV is cut into blocks of forty rows, and every block carries the header row again at the top, so a chunk read on its own still says what its columns mean. Prose is cut on blank lines into pieces of up to about 1,400 characters, each tagged with the nearest heading above it. Chunks are rows in the database, in order, with the character count kept.
Rules run first and run every time. They read tables by their column headings and prose by the shapes numbers take in business writing. Each fact records the source, the chunk, the quoted span and how it was found. A language model runs afterwards only if a key is configured, only over chunks the rules produced nothing from, and its output is marked separately with a wider band.
From there the original file is not needed again unless you ask for a re-parse. It stays on disk so you can re-parse, so the quote can be shown in context, and so you can download what you gave it. If you would rather it did not, delete the source and the whole chain goes with it.
The chunk
A summary throws away the sentence. Once the sentence is gone, a number in a model is an assertion with nothing behind it, and there is no way for you to check it in less time than it would take to rebuild the analysis yourself.
Chunks keep the sentence. When the ledger says gross margin is 31 percent, the entry carries the source file, the chunk it came from and the exact span of text that said so. You click it and read the line. That is the single most useful property of the whole design and it only works because nothing is thrown away.
File types
| Type | How it is read | What can go wrong |
|---|---|---|
| CSV and TSV | Read directly and treated as a table | A summary or total row is read as another data row. Delete those before uploading. |
| Text and Markdown | Read directly, cut on blank lines, headings kept | Nothing much. This is the most reliable format. |
| JSON | Flattened into key and value lines, then treated as prose | Deeply nested structures flatten into long keys that are harder to read back. |
| Word, .docx | The document body is unzipped and the text pulled out | If the file cannot be unzipped it reads as empty and the file report says so. |
| Excel, .xlsx | The first six sheets are unzipped and read into comma separated rows | Also requires ZipArchive. Formulas are read as their stored values. Merged cells and pivot layouts read badly. |
| PDF with a text layer | Content streams are decompressed and the text operators read | Heavily formatted PDFs can come out with the reading order scrambled. Check the parse preview. |
| PDF that is a scan | Not read | The source is marked as needing text and you are told plainly, with a suggestion to paste the numbers or upload the spreadsheet behind it. There is no OCR in the product today. |
| Pasted text | Stored as a small text source with no file behind it | Nothing. This is often the fastest way to fix a gap the ledger has flagged. |
The allowed list and the size limit are settings, so a private deployment can change both. The reading behaviour above is what the code does in either case.
Deletion
One action removes four things: the file is unlinked from disk, its chunks are deleted, the facts extracted from it are deleted, and the source row itself is deleted. There is no archive copy, no trash, and no flag that hides it while keeping it.
What survives, and should, is anything already written into the assumption ledger, because a number you have since confirmed or edited by hand is yours rather than the file's. Rebuild the twin after deleting a source and the ledger is recomputed from what is left, so a deleted file stops influencing the model at that point.
Deleting a twin removes its sources, chunks, facts, assumptions, scenarios, runs and questions together. Closing your account removes your twins. On a private deployment, a setting decides whether removing the application removes the data and the files too; it ships switched off so an accidental removal does not destroy anything.
Standing commitments
There is no cross account query in the application. Your twin is not compared to anybody else's, your numbers do not contribute to a benchmark, and no aggregate of customer data is computed or sold. The industry priors in the product are fixed starting values in a file in the source code, not learned from anybody who has used it.
Nothing you upload is used to train, fine tune or evaluate any model. This is not a setting you have to find and switch off. The product has no training pipeline at all, and the only outbound calls it can make are the three described on the language model page.
You keep every right in what you upload. The licence you give is the narrow one needed to run the service for you: store it, parse it, and show it back to you. The terms say this in the same words.
Download everything, on the account screen, gives you one file with your profile and every twin you own: the record, the ledger, the graph, the agents, the scenarios, the runs, the questions and the log. Each file you uploaded downloads from The record as you gave it. Close the account and there are thirty days to change your mind, after which the data is gone rather than archived.
The boundary
| Thing | Does it leave the server | Detail |
|---|---|---|
| Your uploaded files | No | Files are never transmitted anywhere. No file is uploaded to a model provider as a file. |
| The simulation | No | Pure arithmetic on the server. It makes no network calls and runs identically with no internet connection. |
| The graph, the ledger, the runs | No | Rows in the application database, scoped to your twin. |
| Chunk text, during extraction | Only if a language model key is configured | Up to about 4,000 characters of a chunk, with the document kind, file title and section heading. Only for chunks the rules read nothing from, and capped per pass. |
| A finished analysis, during brief rewriting | Only if a key is configured and you press the button | The company name, the question and the finished numbers as JSON. The numbers are already decided before this call happens. |
| A question and its context, in Ask | Only if a key is configured | Your question plus the graph rows, ledger rows and run results the feature retrieved for it. |
| Billing details | Yes, to the payment processor | Card details go straight to Stripe and are never held by this software. |
| Email, when a form is sent | Yes, to the mail provider | Contact and walkthrough forms store a row and send one email to the operator. |
| A connection you make | Requests only, to the system you connected | The key or sign in you gave it and the reports it asks for, such as the profit and loss for the last twelve months. It reads and never writes, and nothing from your twin is sent. |
| Company sign in | Yes, to your own identity provider | The sign in request, and back from it your email address and name. Nothing about any twin. |
| A hook you add | Yes, to the address you gave it | The event body listed on the integrations page, signed, and only to that address. |
With no key configured, the first three outbound rows never happen and the product still does everything except rewrite briefs and phrase Ask answers in prose.
One profit and loss covering the last twelve months and one customer list with a revenue column. That gives real revenue, real margin, a real customer count and real concentration, which is most of what the interesting questions turn on. Everything else narrows bands rather than enabling answers.
Yes, and it usually costs nothing. The model works on sizes and relationships, so customer names can be Account A through Account X and the concentration analysis is unchanged. Replace names, keep the numbers.
Delete it. The file, its chunks and its facts go together, then rebuild the twin so the ledger is recomputed from what is left.
On a private deployment, no. There is no remote access of any kind, no telemetry, and nothing reporting back.
On the hosted service, the operator can technically read the database, the same as the operator of any hosted software. Nobody looks at customer files as a matter of course, and support will ask you for what it needs rather than going and reading it. That is a commitment from a person, not a technical control, and you should weigh it accordingly.
Yes. Facts from both copies are merged on the normalised name of the thing they describe, so the graph does not double up, but you are holding two files against your plan limit. Delete one.
A twin built from one profit and loss and a customer list is already more useful than an argument in a meeting. You can add the rest later, and the ledger will tell you which file is worth adding next.