What Treecode keeps of what you upload, what it does with it, and how it goes away.
The statement at the top of this page is the one printed on the upload form and in the documentation. The sections below say the same thing in detail: what you upload, where it is stored, what it is used for and by whom, how it is deleted, how long anything is kept, and the laptop package, which uploads nothing.
What you upload
One table of scored samples per grader or per checkpoint: for each candidate, the prompt id, the candidate id, the grader’s score, whether the candidate was right, and optionally its token count; for step graders also the step index, the node id and whether the parent was right. The table carries no prompt text, no model output text and no grader internals unless you put them in the id columns, and nothing in the product needs them there: an opaque id per prompt and per candidate is all the engine reads. Use opaque ids if the prompts themselves are confidential.
With the table you give a grader a name, the group size it is used with, where the labels come from, and optionally the model and checkpoint the samples came from and free notes. Those are printed on the report so that a measurement is never separated from what it measured.
Where it is stored
| what | where | how long |
|---|---|---|
| the sample table, normalized to JSON lines | the platform’s private object store, encrypted at rest, under product/<organization>/<grader>/<sample set>.jsonl; readable only by the service |
until you delete the grader; copies in the store’s backups expire within thirty days of that |
| the reports (the computed numbers, bands and sentences), the budgets’ inputs and the decisions you log | the platform’s database, in your organization’s rows | for the life of the account; reports are kept when a grader is deleted, so that the decision log keeps its context |
| usage events (prompts ingested, calibrations queued, checkpoints uploaded) | the database | for the life of the account; they are the statement |
| API keys | the database, as a SHA-256 hash and a 12-character prefix; the key itself is shown once and never stored | until revoked; a revoked key’s row stays for the audit trail |
| your account (name, work email, company) and session | the database | for the life of the account |
The service runs in one cloud region in the United States. The bucket and the database are not reachable from the public internet; the application and the API reach them through the service’s own role.
What it is used for
The samples are read by the calibration worker to compute your report, by the budget pages to compute the Rollout Budget and the Cost per Solved Task from that report, and by the checkpoint series when they belong to a training run. That is all. In particular:
- Nothing is trained on your data. Treecode trains no model on uploaded samples, builds no cross-customer index from them, and does not read them to tune the engine. The engine’s own tests run on synthetic tables and on Treecode’s own Milestone 1 sample.
- Nothing is shared across organizations. A grader, its samples, its reports and its decisions are visible to the members of the organization that uploaded them. The two demo graders of the sample project are the only objects every organization can see, and they are Treecode’s own data.
- A share link exposes the report, not the samples. When you turn sharing on, the link shows the latest report (the numbers, the figures, the grader’s name and settings, your organization’s name). It never serves the sample rows. Turn it off and the link stops working at once.
- Aggregate operating numbers (how many calibrations ran, how long they took) are kept without reference to any sample table.
Deletion
Delete a grader from its page in the application or with DELETE /graders/{id}. Its sample files are removed from the object store at that moment (the response says how many), it leaves every list and answers 404 afterwards, and its reports and the decisions logged against them stay in the database so that your decision log keeps its context. Deleting a training run’s grader deletes its checkpoint tables too. Copies of deleted files in the store’s backups expire within thirty days. To have the reports and the decision log removed as well, or the whole account closed, write to the contact below; it is done by hand in this prototype and confirmed by email.
Retention
Nothing is kept longer than stated above. Sample tables are kept for as long as their grader exists because re-measurement is the product’s month two: a new calibration of the same table with other parameters, a budget with other floors, or a comparison against the next checkpoint reads the stored table rather than asking for it again. If you would rather not leave tables on the service, delete the grader after reading its report, or use the laptop package.
The laptop package
treecode-calibrate is the engine the service runs, published as an open Python package. treecode-calibrate samples.csv --group-size 16 prints the same report on your own machine, writes the same JSON and figures with --json and --figures, and computes the budgets with --budget and --serving. It opens no network connection: nothing is uploaded, nothing is phoned home, and the package has no telemetry. For proprietary data this is the answer, and the service exists for the storage, the pages, the API, the checkpoint series and the shared reports around the same computation. The documentation’s laptop package section has the options.
Contact
Questions about data handling, deletion requests and account closure: junshimada2002@gmail.com. Treecode is a one-founder venture in this prototype stage; requests are answered by the founder.