Glossary

Key terms used across the Syncanix documentation.

The cross-cutting vocabulary used throughout these docs. Later sections define their own domain terms where they appear.

Capability: A single thing your API can do — one endpoint or action, like “refund an order” — described so the assistant knows what it does and when to use it.
Capability catalog: The structured list of all your capabilities. It is discovered from your API and is the single source of truth the widget, chat, and MCP server all read from.
Discovery: The process of scanning your codebase to build the capability catalog, run by the Syncanix CLI.
Side effect: What an action does to your data: read (looks something up), write (changes something), or destructive (deletes or irreversibly changes). The side effect sets how the action is confirmed.
Widget: The embeddable chat component you add to your app with a single script tag.
Chat surface: The assistant experience your users interact with — answering questions and taking actions through your API.
Grounding (retrieval): Answering from your own documentation and content rather than the model's general knowledge. The assistant retrieves relevant material and cites it, so answers reflect your product.
MCP (Model Context Protocol): An open standard that lets AI clients such as Claude Desktop, Cursor, and ChatGPT connect to external tools and data.
MCP server: The per-workspace endpoint Syncanix gives you so MCP clients can reach your capabilities.
Builder / admin: Your team — the people who run the CLI, configure the dashboard, and manage the workspace.
End user: Your customer’s signed-in user, who chats with the widget or connects an MCP client. Their own identity — not a shared one — is used for every action.
User Learning: An opt-in capability that lets the assistant learn durable preferences and context about each signed-in end user from their conversations, injecting a compact, budget-capped summary into future turns to personalize responses and available actions.
Agent Impact: The analytics surface that measures the business value the agent delivers — how many end-user requests it resolved without human help (deflection), the outcomes of those conversations, and an estimated return on investment — aggregated nightly per workspace with honest sampling disclosure.
Interaction Map: A visual map of the agent's capability graph and the journeys end users take through it — which areas, routes, and capabilities they reach, where demand concentrates, and where capability gaps remain — rendered as an interactive canvas with an accessible table view.
Red-team report: A signed, per-workspace security report that runs Syncanix's curated adversarial corpus — prompt-injection, jailbreak, and data-exfiltration probes — through the live defences and scores each attack category. A category passes only when every attack probe is caught AND no legitimate probe is falsely flagged. The same corpus gates continuous integration, so a report can never claim coverage the build does not also enforce.
Identity provider (IdP): The service that authenticates your users — for example Auth0, Clerk, Cognito, or WorkOS. Syncanix uses it instead of storing credentials itself.
Federation: Delegating sign-in to your identity provider, so the same login and permissions your users already have apply inside Syncanix.
JSON Web Token (JWT): A compact, signed token that proves who a signed-in user is. Your identity provider issues it; Syncanix verifies its signature to trust the identity.
JWKS (JSON Web Key Set): The set of public keys your identity provider publishes so services can verify the signatures on its tokens, without ever sharing a secret.
OpenID Connect (OIDC): The standard sign-in protocol most identity providers speak. If yours supports it, Syncanix can verify your users through it.
PKCE (Proof Key for Code Exchange): A security step in the OAuth sign-in flow that stops an intercepted authorization code from being used by anyone else. MCP clients sign in this way.
Scope: A named permission attached to a token — what the holder is allowed to do. The assistant's actions are bounded by the user's scopes, never more.
Token exchange: A standard (RFC 8693) way to swap one token for a narrower one bound to a specific job — used in enterprise setups so every downstream action gets its own explicitly-issued, scoped token.
Backend-for-frontend (BFF): A small server you run that sits between the widget and Syncanix, so authentication tokens never reach the browser. The most locked-down way to authenticate your users.
Step-up authentication: Asking a user to re-confirm their identity — for example with multi-factor authentication — before a sensitive action runs.
Act on behalf: The assistant performing an action as the end user, with their identity and permissions — never with elevated or shared access.
Confirmation tiers: How Syncanix gates actions by risk: read actions can run automatically, write actions ask for confirmation, and destructive actions are blocked unless you allow them.
Row-level security: A database feature that filters every query to one workspace's rows automatically — Syncanix's final backstop keeping customers' data apart even if a query forgets to scope itself.
Signed intent: A tamper-proof, single-use token that binds an approved action to a specific user, capability, and inputs, so a confirmed action can't be altered or replayed.
Evaluation gate: An automatic quality check that runs before you promote to production and blocks the change if the assistant's answers regress — so production only ever changes for the better.
Drift detection: Noticing when your API or its behaviour changes so the catalog no longer matches reality, and flagging it so the assistant never acts on a stale picture.
Handoff (escalation): Passing a conversation from the assistant to a human on your team when the user needs one — with the context of the chat so far.
Zero data retention (ZDR): An arrangement where an AI provider processes a request without storing it or training on it. The CLI requires your explicit consent before any AI enrichment.
BYOK (bring your own key): Using your own AI provider keys, so model usage is billed directly to you by your provider rather than counting against your plan.
BYOMCP (bring your own MCP server): Connecting MCP servers you already run as extra tool sources. Their tools appear alongside your discovered catalog, and calls are forwarded to your server with tenant isolation and step-up authentication honored.
Witness: A runtime observation of an API call's shape — field names and inferred types, never values — produced by the opt-in api-witness middleware. Witnesses keep the catalog aligned with what your API actually serves.
CU (compute units): A weighted measure of what your assistant does — messages, tool calls, and the underlying tokens all consume CU. Plans are sized by included compute units, so usage (not headcount) drives cost.
Environment: An isolated copy of your configuration. Each workspace has a development environment for setup and a production environment your users reach.
Promote: Moving your configuration from development to production, so live behaviour only changes when you intend it to.
Publishable & secret keys: A publishable key (pk_…) is safe to embed in your web page for the widget; a secret key (gak_…) is used server-side, for example by the CLI. Never expose a secret key in client code.
Workspace: A single Syncanix tenant — your project, with its catalog, configuration, team, and billing. You can belong to more than one.