> ## Documentation Index
> Fetch the complete documentation index at: https://docs.galtea.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Glossary and FAQ

> The terms used across these pages, and answers to common questions.

## Glossary

**Organization**: the tenant unit inside the platform. All data belongs to exactly one
organization, and access is checked against the caller's organization on every request.

**Evaluation**: a run that scores your AI product's output against criteria you define,
usually with a language model acting as the judge.

**Generation**: producing test data: synthetic user scenarios, golden datasets, adversarial
(red-teaming) test cases.

**Worker**: a service that processes evaluation and generation jobs asynchronously, pulling
them from a queue. This is the compute-heavy part of the platform.

**Worker pool**: a set of workers. Shared pools process every organization's jobs; dedicated
pools are reserved for one organization.

**LLM gateway**: the single outbound choke point for model calls. Handles provider routing,
fallback, retries and quotas, so providers and models can be changed without touching the
services.

**Helm chart**: the packaging format for a Kubernetes application. Galtea publishes versioned
charts you install with `helm install` or through a GitOps controller.

**ArgoCD**: a GitOps controller that keeps a cluster in sync with configuration stored in
git. Galtea uses it internally; it is optional for a self-hosted install.

**KEDA**: a Kubernetes component that scales workloads on an external signal, in Galtea's case
queue depth. Optional.

**WireGuard**: the encryption protocol used for the VPN tunnels in a private tenant.

**NetBird**: the open-source overlay network, built on WireGuard, used to give private access
to a tenant. Its control plane coordinates peers; it never carries application traffic.

**Routing peer**: a VPN peer that advertises whole network ranges, so a site reaches the
tenant without installing a client on every machine.

**Egress control layer**: the component all outbound traffic passes through in a private
tenant, enforcing a hostname allowlist that denies everything not explicitly approved.

**Workload identity**: a mechanism that lets a Kubernetes workload authenticate to cloud
services without a stored key.

**Signed URL**: a short-lived, single-object URL that lets a browser upload or download from
object storage directly, without the platform proxying the file.

## FAQ

**Can we start on shared SaaS and move to a private tenant later?**
Yes, and it is a common path. The product surface is identical, so your tests, SDK code and
CI pipelines do not change. Existing data migration is scoped per case.

**What are the availability and support commitments?**
Availability targets, support hours, response times by severity and breach-notification
terms are commercial commitments and live in your agreement rather than in these pages. Ask
your Galtea contact for the current service description.

**How do we get our data out, and what happens at the end of the contract?**
Your test definitions, datasets and evaluation results are exportable through the API and
the SDK at any time, in the same shapes the product uses. Retention while the contract runs
is configurable per deployment; deletion at the end of it is covered in your agreement. In
a self-hosted install the data is already yours and no export step is involved.

**Does Galtea need access into our network?**
Not for the platform to function, and never as an inbound firewall rule you open for Galtea.
Traffic toward your AI product is outbound from the platform, with your endpoint as the
server, and private tenant VPN connections are established outbound from your side. One
deliberate exception: in model 4 Galtea needs credentials to run Helm against your cluster.
You issue them, you scope them to the platform namespaces, you can restrict them to your
VPN or bastion, and you can revoke them, or remove the access entirely by choosing the
GitOps mechanism. See [model 4](/deployment/model-managed-in-your-cluster).

**Can we use our own LLM provider account?**
Yes, in a private tenant and when self-hosted. Inference then runs under your contract, in
your region, against your quota. In shared SaaS, inference runs on Galtea's provider
accounts.

**Can the models run in Europe? Can we use a European model?**
Yes to both, and they are different questions. The major models are available from EU-resident
deployments, exposed in the gateway as separate entries with their own credentials, so choosing
EU is choosing a route rather than trusting a setting. European models, Mistral Large among them,
are available the same way. If even an EU region of a third-party provider is unacceptable, a
model you host yourself behind an OpenAI-compatible endpoint is supported in a private tenant or
a self-hosted install. One thing to decide deliberately: automatic failover between providers
protects uptime but can move a request elsewhere, so a strict residency requirement means
restricting the allowed set and giving up that fallback.

**Can we restrict which models are used?**
Yes, in a private tenant and when self-hosted. Restricting the gateway to an approved model
subset is a normal requirement in regulated environments.

**Is our data used to train models?**
Not by Galtea, and in shared SaaS and private tenants not by the LLM providers either: the
enterprise provider terms those deployments run under exclude training on submitted data. In
a private tenant or self-hosted install you can additionally bring your own provider account
and terms, and restrict which providers are reachable at all.

**Where exactly is our data?**
Shared SaaS: Galtea's cloud account and region. Private tenant: a dedicated cloud account in
the region you choose. Self-hosted: your infrastructure.

**Can our test data include personal or confidential information?**
The platform holds whatever you upload, so treat it as holding your test data's
classification and scope the test data accordingly. If your data cannot sit in third-party
infrastructure, that points at a private tenant with your own encryption keys, or a
self-hosted install.

**What happens if a Galtea component fails during a long evaluation?**
Jobs are queued and retried. A worker restart does not lose queued work. In a
Galtea-operated deployment it is monitored and resolved for you; in a self-hosted install
queue depth is the signal to watch.

**Can we run the platform completely air-gapped?**
Yes, by agreement. Images and charts must be mirrored into your internal registry, and you
must provide an LLM endpoint reachable from inside the perimeter, which usually means a
self-hosted or privately deployed model.

**Do we need ArgoCD, KEDA or a service mesh?**
No. All three are optional. The charts install with plain Helm on a bare cluster. KEDA only
adds autoscaling; without it you set fixed replica counts. A service mesh only adds mutual
TLS between platform services.

**Which cloud can we self-host on?**
Azure AKS is the validated target and has a complete deployment package. AWS EKS is the
platform Galtea runs on itself. Google GKE, OpenShift and other conformant Kubernetes
distributions are supported as a scoped adaptation.

**How often do we have to upgrade a self-hosted install?**
There is no forced cadence, and nothing expires or stops working if you stay on a version.
Galtea ships releases frequently, typically weekly; how often you apply them is your decision
and should match what your change process can absorb. The only constraint is the step size:
upgrades are tested between consecutive versions, so catching up from far behind means applying
the versions in order. Back up before each one.

**Can we get read-only access to the platform's own monitoring?**
Not out of the box. In the shared SaaS models you get the status page and the support channel.
In a private tenant, read-only dashboard access can be arranged on request, after a one-time
setup that isolates your tenant's metrics, logs and traces. In a self-hosted install the
monitoring is your own.

**Who at Galtea can see our data?**
In Galtea-operated deployments, a restricted set of named personnel, for operations and
support, with MFA, and that access is logged. In a self-hosted install, nobody: there is no
access path. That access is recorded in audit logs, which Galtea's own security team reviews;
the logs are internal and are not exposed to customers. Further restrictions and break-glass
procedures can be agreed per contract. The access-control and logging policies behind this are
published in the trust center.

**Are you certified? Can we get your security policies?**
Galtea is **ISO 27001 certified**. The certificate, its scope, the policy set and the
subprocessor list are published at [https://trust.galtea.ai](https://trust.galtea.ai), without an NDA. Beyond naming the
certification, these pages do not restate the trust center on purpose: anything dated that is
copied into a document goes stale and then contradicts the live source. For a signed
data-processing agreement or a report under NDA, ask your Galtea contact.

**Do you penetration test the platform?**
Yes, as part of the annual security audit cycle under the ISO 27001 programme. You can also
run your own test, scheduled with Galtea first. Against the shared SaaS platform that
scheduling is not optional: it is multi-tenant, so your traffic is indistinguishable from an
attack on another customer.