On this page
Core primitives
PromptOps
PromptOps is the discipline of treating prompts as production artifacts — versioned, observable, governed, and rolled out with control. It applies the same engineering rigor to prompts that we already apply to code and infrastructure.
A team practicing PromptOps can answer four questions about any prompt in production: which version is live, who approved it, what it costs, and how to roll it back.
→ Longer treatment in our blog · PromptOps product page
AI Gateway
The AI Gateway is the single REST interface services use to call LLMs. It’s OpenAI-compatible — most clients can switch with a base URL change — and routes requests to OpenAI, Anthropic, Google, Groq, and OSS providers through one API key.
Under the hood it enforces authentication, logs usage, applies budgets, and emits audit events. To the calling service, it just looks like an LLM API.
Control Plane
The Control Plane is the set of administrative capabilities that govern how the Gateway behaves: tenant isolation, role-based access, per-tenant budgets and rate limits, kill switch, and feature flags. It’s where operations, finance, and governance teams configure the platform without touching code.
Data & governance
Vault
The Vault is the encrypted store for raw prompts and model outputs. It’s separate from operational metadata (the Usage Ledger) — content lives in object storage with application-layer encryption, while metadata lives in PostgreSQL for fast query.
Vault retention is configurable per data class. Direct read access is refused by default; access requires a documented reason, is logged, and goes through audit.
Tenant isolation
Tenant isolation means data and configuration for one tenant (organization, workspace) is not visible to another. Every query includes service_id + tenant_id + user_id; cross-tenant access is denied unless explicitly granted. Row-level security is a secondary defense on top of application-layer ownership checks.
Consent
In SchneeAI’s data model, consent is a first-class record: who consented, to what purpose, when, and whether they’ve withdrawn. Consent gates whether interactions become eligible for uses beyond the immediate service — most importantly, whether they can enter a training dataset.
Consent is not a one-time checkbox. It’s a state that can be revoked, and revocation propagates to downstream uses.
PII / sensitive content
Personally Identifiable Information and other sensitive content (API keys, connection strings, JWTs, PEM blocks) are scanned before content is stored or sent upstream. SchneeAI detects 17 categories, each with a severity:
- Critical: API keys, secrets, private keys, connection strings → block by default
- Warning: emails, phones, government IDs → mask or flag
- Info: IPs, low-signal identifiers → auxiliary context
Each category has a configurable policy: flag, mask, or block.
Operations
Canary rollout
A canary rollout ships a new prompt version (or model, or config) to a small percentage of traffic first, watches metrics, and either promotes to 100% or auto-rolls back. The pattern comes from deployment practice; SchneeAI applies it to the part of the system that changes most often.
Kill switch
The kill switch is a platform-level control that stops traffic to a model, a feature, or a tenant in seconds. It’s the answer to “what do we do at 3am when something is wrong and we don’t yet know what.” Operations and security roles have it; developers don’t.
Credit ledger
The credit ledger is the append-only record of credit reservations, settlements, releases, and adjustments. Each AI interaction reserves credits before the call, settles once the upstream returns actual usage, and releases the difference if the call fails. The ledger is the financial source of truth — adjustments are new rows, never in-place updates.
Beyond the basics
Dataset Builder
The Dataset Builder compiles training datasets from Vault content — but only after three gates pass: consent (the interaction is eligible), redaction (PII and secrets removed), and review (a human signed off). Output datasets carry lineage: every item traces back to a source interaction.
This is the bridge between runtime AI operations and model improvement.
Model Router
The Model Router decides which upstream model handles a given request. It can be explicit (model: "anthropic:claude") or policy-driven (auto, cheapest, lowest-latency). Routing is configurable per service, per feature, and per tenant.
Service Registry
The Service Registry is the inventory of services permitted to call the Gateway. Each service has credentials, an owner, a feature set, and an entitlement profile. The Gateway refuses calls from services not in the registry.
What’s missing?
This glossary focuses on the terms most often misunderstood. If a term you’d expect isn’t here, email us and we’ll add it.