Per-tier data grant — shared_anon
What the shared_anon tier permits us to keep and reuse, restated from Terms of Service §6 and §9.
Fronset — Per-tier data grant: shared_anon
KAPUA Labs LLC, doing business as Fronset 30 N Gould St Ste R, Sheridan, WY 82801, United States
| Document kind | data_grant |
| Tier | shared_anon |
| Version | 2026-09-15 (date-based versioning) |
| Effective | On publication at the URL recorded in the corresponding ConsentDocument row |
| Parent | Terms of Service §6 and §9 · Privacy Policy · Data Processing Agreement |
This document is the data grant for the shared_anon tier, and nothing else. It restates
Terms of Service §6 and §9 as they apply to this one tier, so that what you are accepting
is legible without reading the whole agreement. It creates no right that §6 and §9 do not
create; where this document and the Terms differ, the Terms govern.
The access mode that serves a Call — bring-your-own-key (ToS §5.1) or operator-supplied
(§5.2; the mode the Service, the portal and the documentation call managed) — decides
who pays the Provider. It does not change anything on this page.
1. What we keep, and what we may reuse
| What | On shared_anon |
|---|---|
| Your prompt variables (your inputs) | Never stored — dropped at the moment the Call record is written |
| Which prompt version ran (identity only, no content) | Retained |
| Your Template / system prompt | Stored to run your Calls; also usable by us for the taxonomy purpose in §2, and subject to the republication licence in §3. Yours to delete once the one-time §2 evaluation is complete |
| Semantic index of your Call (a routing embedding) | Stored only until the §2 evaluation of the Capability is complete, then deleted. An embedding is partially invertible, so we treat it as content: erasure hard-deletes it |
| Model Output | Held only until it has been delivered to you and any evaluation of it has finished, then deleted (§1.2). An Output we could not deliver is held for you to retrieve for at most 72 hours |
| Evaluation evidence (what a judge saw, the candidate Outputs, the Verdicts) | Deleted with the Output — except on a Capability you judge on your own criteria, where a copy is kept for the review window you set (§1.3) |
| Verdicts (quality scores about models) | Retained |
| Where your Verdicts aggregate | Cross-customer pool — and pooling is irreversible |
This table is a rendering of a single retention matrix in the Service’s code, applied at one write chokepoint. Any change to it is a change to the agreement and requires a new version of this document and of the Terms.
1.1 What “never stored” does and does not mean
Your prompt is not persisted on the Call record. It is not written and later deleted. It does necessarily exist in worker memory while your Call is being served, including when we retry or fail over to a second model within the same request.
Two qualifications, both real:
- Batched Calls hold a working copy. A Call submitted through the Batch interface keeps its rendered request in the Call record’s operational metadata, because the Provider submission reads it back and a retry needs it again. It is stripped when the batch finalizes, stripped again by a daily sweep, and backstopped by a hard 24-hour batch expiry. For batch traffic, “never stored” means “not stored beyond the operational window” — hours to a couple of days — rather than “not written at all”.
- Benchmark inputs you upload are exempt, by design. A benchmark (“golden”) set is stored and re-run on every tier, because that is what you uploaded it for. Uploading requires an explicit acknowledgement of this exemption, recorded with who and when.
1.2 The model’s answer is deleted once you have it
We delete the Output of a Call promptly — typically within minutes — once it has been delivered to you and any evaluation of it we perform has finished. An Output we could not deliver (a webhook that kept failing, a batch file nobody fetched) is held for you to retrieve for at most 72 hours, then deleted. There is no retrieval of a past Output beyond that: keep what you fetch. A batch output file stays fetchable for a short time after your first fetch so a broken download can be retried, and then goes. The prompts in a batch input file are deleted once the batch has finished. This is a schedule we enforce and monitor, not an intention (ToS §7).
1.3 Reviewing evaluations made on your own criteria
If you set your own evaluation criteria for a Capability, its Verdicts stay with your Account (they stop pooling from that point) and you can review them: we keep a copy of each evaluated exchange on that Capability — what the judge saw, the candidate Outputs and the Verdicts — for a review window you control, up to the maximum shown in the console, and delete it when the window closes. You may shorten the window to nothing at any time; you cannot lengthen it past the maximum. On this tier a judge grading a single Output is not shown your prompt, so that copy carries none (ToS §11).
2. Taxonomy use of your Capabilities and Templates
We maintain a canonical library — a map from many differently-named Capabilities onto one canonical definition — so that quality statistics can be compared across customers.
On this tier we use your Capability definition (slug, display name, description) and your Template text to derive that structure. Deriving structure does not, by itself, permit us to reproduce, publish or redistribute your Template text; §3 does, separately.
The evaluation happens once, and it is bounded. We compare a Template with the library within a bounded period of the Capability’s creation — the console shows when it is done. Everything we kept for the comparison (the routing embeddings in §1) is then deleted, and from then on you may delete the Template text yourself, from the console or the API. The content-free record of which version ran a Call survives; a Template already adopted under §3 stays adopted. A Capability whose Template you delete cannot serve Calls until you register a new one.
3. Common-capability adoption — read this one carefully
This is the grant most easily missed, and it is the widest one on this page.
If we determine that a Capability you defined is suitable to become part of the canonical library made available to other customers, you grant us a non-exclusive, worldwide, royalty-free right to reproduce, publish and redistribute that Capability’s Template text, verbatim, as part of the published canonical set — including serving it, unmodified, to any other customer whose Calls route to that canonical Capability.
- We decide which Capabilities we adopt this way, at our discretion.
- You do not need to request or approve it, and we do not owe you notice, credit or compensation for it.
- This is a licence, not a transfer — the Template text remains yours.
- To the extent it is published or served to other customers under this licence, it is no longer confidential, and it is used well beyond deriving structure.
If your Template text is commercially sensitive, do not put it on this tier.
4. Changing tier, and what a change cannot undo
A tier change takes effect going forward (ToS §6.4). It does not re-classify data already written, and it does not withdraw Verdicts already pooled.
5. Deletion
Your erasure rights, and the honest limit on them, are in ToS §12 and Privacy Policy §8. The short version: we can delete your content; we cannot un-derive an Aggregate. Erasure blanks your Template text too, on every tier; the record of which version ran a Call stays, without the text.
6. Unknown or unrecognised tier
An Account whose tier is missing or unrecognised is treated as private — the most
restrictive setting — never as this one (ToS §6.3).
Version 2026-09-15. Prepared by KAPUA Labs LLC, doing business as Fronset. This document restates Terms of Service §6,
§7, §9 and §11 for the shared_anon tier; the Terms are the operative instrument.