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 counterfirm folder inside the WordPress uploads directory, in a subfolder for that twin, under a filename with a timestamp and six random characters in front of it. It is never registered as a WordPress attachment.
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 | Requires the ZipArchive extension in PHP. Without it the file reads as empty and 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 self hosted install 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. If you self host and want uninstalling the plugin to remove the tables and the files too, there is a setting for that which ships switched off so an accidental deactivation 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.
Facts, assumptions, graph nodes, run results and briefs read back through the API as JSON, and the brief exports as a document. If you stop paying, export first, because after the retention window 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 in PHP. It makes no network calls and runs identically with no internet connection. |
| The graph, the ledger, the runs | No | Rows in your own database. |
| 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 to Stripe through Paid Memberships Pro 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. |
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 self hosted install, no. There is no remote access of any kind, no telemetry, and nothing reporting back.
On hosting operated by the person who built this, an administrator of that WordPress install can technically read everything in the database, the same as any WordPress plugin. 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.