How Estelle improves itself

Effective date: July 15, 2026

A product that reads your code has to be honest about what it learns. Estelle improves from how the product is used, not from what your code says. This page draws that line in plain English, because a tool built to refuse guessing should not be vague about its own data.

The promise

Estelle's whole reason to exist is that it grounds every answer in your real code and blocks anything it cannot prove. That only earns trust if we hold ourselves to the same standard. So:

We do not train on, or mine, your code.

The content of your repositories is never used to train, fine-tune, or evaluate a model, and never used to build features for other customers. Because you bring your own model and key, your code goes to your provider under your terms; Estelle structurally cannot make itself a training recipient of it.

We improve from how the product is used.

Estelle gets better from aggregated, anonymized usage metadata, which capabilities are called, where it errors, how fast it responds, what people ask for next, plus public market and technical research. That is how you use it, not what is in your code.

You can opt out, and still keep the product.

Product-improvement analytics are optional. Turn them off and Estelle keeps working; only the metering strictly required to run and bill the service continues.

Two kinds of learning

“Estelle learns” can mean two very different things, and the difference is the whole point. We keep them strictly separate.

Learning that stays yours. Estelle gets better at your codebase, your conventions, your history, your facts, and keeps all of it inside your namespace, serving only your team.
Learning that improves the product. Estelle-the-product gets better for everyone, and that learning is fed by usage metadata and public research, never by the contents of anyone's repositories.

Learning that stays yours

When Estelle picks up your team's conventions, remembers a decision from a past session, or records which of its skills worked on your repo, that knowledge is written to your namespace and used only to serve your team. It is your competitive memory, not a contribution to a shared pool.

Convention and preference signals learned from your work stay in your namespace.
Per-team skill and instinct feedback tunes Estelle for your repo, and is not pooled across customers.
None of it is visible to, or reused for, another tenant, consistent with the isolation guarantee in the Privacy Policy.

Learning that improves the product

The product itself, the retrieval quality, the grounding gate, the skills catalog, the docs, the roadmap, improves from two sources, and only these two:

Aggregated, anonymized usage metadata: which capabilities get used, error and retry rates, latency, and what customers ask us to build. This tells us where the product is weak without telling us anything about your code.
Public research: published benchmarks, market and competitor research, public datasets, and our own internal evaluations run on public or synthetic data. When we measure Estelle against a benchmark, we use public or our own test data, never your repositories.

Note. Our improvement loop is driven by evaluations we run ourselves on public and synthetic material. Your private code is not part of that loop, and does not become training data by using Estelle.

What 'usage metadata' means

Concretely, usage metadata is signals like:

Which capabilities and skills were invoked, and how often.
Request counts, memory-tokens held, and other metering figures.
Error rates, retries, timeouts, and latency.
Feature requests and support questions you send us.

It explicitly does not include:

The source code, files, or content you ingest.
The text of your prompts or the model's answers about your code.
The facts or memory derived from your repositories.

Where aggregated metadata could still be linked back to an individual or a specific customer, we treat it as personal data under the Privacy Policy.

The line we will not cross

To be unambiguous, here is what we will not do, restated as a commitment:

We will not train, fine-tune, or evaluate any model on your code content.
We will not use your code content to build features for, or improve the experience of, other customers.
We will not pool one team's learned conventions or facts into another team's.
We will not silently change this: material changes to how we improve the product will be announced, and the opt-out will remain.

Why it is built this way

This is not only a policy choice; it is how the system is built. Bring-your-own-key means your code travels to your provider under your terms, so we are not positioned to harvest it. Per-namespace isolation means one tenant's data is not readable by another. And the grounding gate treats your real code as the source of truth and refuses anything injected into it, so the memory cannot be quietly turned into a training feed. The honest version of self-improvement is the only one the architecture actually supports.

How to opt out

Product-improvement analytics are opt-out. Disable them in your dashboard settings, or email khai@fatelabs.ca and we will turn them off for your account. Metering that is strictly required to operate and bill the service continues, because it is part of delivering the product to you.

Contact

Questions about how Estelle learns: khai@fatelabs.ca. This page is a plain-English companion to the Privacy Policy and the Data & Processing notice. Estelle is operated by Honour Systems Inc. (incorporated in Ontario, Canada), doing business as Fate Labs.