Two products that work as one.
The Gateway runs in your network and decides each AI request your applications send through it. The Control Plane decides what may run, shows what it costs and holds the evidence. You can use the Control Plane on its own or both products together.
- Allows, redacts, routes or refuses each request
- Writes a chained decision record for every request
- Stops a run, an agent your application labels (X-Saible-Unit), a workload or an application, in every mode
- An AI catalogue found on your platforms and in your code, claimed by its owners, who add only the purpose and the risk class
- Spend, contracts and budgets from your providers' bills
- The context of each application, and what each AI platform permits
- Policy changes approved by two people
- Registers, readiness and the evidence pack
Working together
- 1The Control Plane holds the policy. A change is replayed over what already happened, and a second person approves it.
- 2Every gateway pulls the signed policy revision and decides each request under it. Nothing is pushed into your network.
- 3Each decision is sent back as a decision record. It holds where personal data was found and what was decided, never the text, and it becomes evidence.
Comparison of the two products
Compared by the seven areas of control coverage. The Control Plane on its own covers six. It finds your AI systems on your platforms and in your code, and reads your providers' bills, your contracts and what you declare. With read-only access, it also reads how your AI platforms are configured, the context of each application and your own request logs. The Gateway adds Enforce: a decision and a record for each request sent through a gateway. In record-only mode, the record shows what the policy would have done. A request the gateway could not record is counted in a gap record.
- AI catalogue from code and platforms: every AI system found in the repositories of your GitHub organisation or GitLab group, on your connected platforms or at the gateway, listed until an owner claims itThe owner adds only the purpose and the risk class. Entries describe software, never people. A self-hosted code host is read by a collector you run. The browser extension, Azure DevOps and Bitbucket are on the roadmap.yesyes
- Spend by provider, model and dayFrom the providers' own billing feeds.yesyes
- Contracts: consumed, projected and forfeited amountsyesyes
- Human AI use: unused paid seats, by team and serviceBy team and service, never by person. From the seat exports you upload. Browser use comes with the browser extension, which is not yet published.yesyes
- Exposure: what each AI platform's configuration permitsRead-only, through your spend connectors' credentials. Built, but not yet run against a live account.yesyes
- Landscape report: the AI in useOn its own: providers, models and spend from the bills. The gateway adds applications and requests.in partyes
- Bills matched to recorded requestsOn its own: the bill is checked against itself and the list price.in partyes
- Savings: one list, each saving with its method of calculationOn its own: idle commitments from your contracts. The token checks read the gateway's records.in partyes
- Claim and attest: each AI system found gets an owner, who confirms its purpose and risk class and attestsDiscovered, then claimed. It stays unclaimed until someone claims it.yesyes
- Registry: each application, its owner and its approvalIts application key is checked at the gateway.yesyes
- Registries of agents, MCP servers and toolsListed and reviewed. A registry entry does not yet decide whether a request is allowed. Allowing a tool per agent is on the roadmap.yesyes
- Policy, identifier and application approvals by a second personOther changes wait in the review queue for an organisation admin. Second-person approval of all changes is a setting.yesyes
- Context: a signed context manifest of each application's models, prompts, tools and knowledge sourcesRead only from its repository, its AI accounts and its own traces, and confirmed by a person. No reader has yet run against a live account.yesyes
- Change events: a push or a Bedrock change starts a fresh readGitHub webhooks and Amazon EventBridge. No sender has yet run against a live account.yesyes
- Connected systems: context kept in other systems, through their MCP serversConfluence and SharePoint first, Salesforce and Google Drive next, or any MCP server. None has yet run against a live account.yesyes
- Business ontology: the elements your AI's confirmed context names, with lineage from table to conceptCounted from the confirmed manifests and your enterprise sources. Ranked by stated reasons, never by a model.yesyes
- Data map: the personal and special category data each AI system reaches, and where the data is heldFrom your platforms' tags and what your people declare. Data marked Not classified is never treated as safe.yesyes
- Context health: whether what your AI uses is current, consistent and genuineyesyes
- Ontology API: an agent asks Saible what a business term meansA gateway check of the answer's receipt on each request is on the roadmap.yesyes
- Policy as sentences, signed per revisionyesyes
- Policy packs for the GDPR, the AI Act (deployers) and DORA, scoped per applicationyesyes
- Rules suggested from a scan of your code, approved or dismissed by a personyesyes
- Write-back: a fix on the platform, proposed, tested in a dry run, approved, applied and read againAmazon Bedrock and OpenAI. By default Saible proposes and a person applies.yesyes
- Budgets on a team, an application, an agent or an MCP serverOn its own: alerts, and a platform cap on Bedrock or OpenAI that a person approves through write-back.in partyes
- Past usage assessed against the policyThe assessment run, from the bills.yesyes
- Candidate models evaluated on your own golden setEach request is decided by your policy in Saible and recorded. Not yet run against a live provider.yesyes
- Model lab: each model's figures on your data classes and golden sets, beside costFigures, never a verdict. A model switch goes to the review queue.yesyes
- Each request read from your own logs: Bedrock, Databricks, Snowflake Cortex, OpenTelemetryMetadata only, never a prompt, a completion or a person. Read when an admin starts the read, not yet on a schedule.yesyes
- Those requests checked against the policy in force, chainedOnly as reliable as the logs it reads: not enforced and not signed per request. Run on request, not yet nightly.yesyes
- A decision on every request: allow, redact, route, refusenoyes
- A chained decision record for every requestnoyes
- Emergency stops, in every modeOn its own: a stop on the platform through write-back, approved by two people. With the gateway, every gateway checks for stops every 15 seconds.in partyes
- Routing to a cheaper approved model, playback, and the savings a cache would make (shadow mode: nothing is served from it)Only requests to auto or an alias are routed. A named model is never swapped.noyes
- Model recommendations from your own requestsnoyes
- Evidence ledger: what Saible recorded, tamper-evidentWith the gateway it also holds a chained decision record for every request.yesyes
- Readiness for the GDPR, the AI Act and DORA, by articleOn its own: articles that need the request record show Not yet.in partyes
- Registers: declared compared with observedOn its own: compared with the bills and contracts.in partyes
- Incidents, with their reporting deadlinesA person decides whether an incident is reportable.yesyes
- AI literacy of the people who oversee each systemyesyes
- Evidence pack for an auditorWith the gateway it also holds the decision records.yesyes
Shared by both
- Getting started01Shared service or Dedicated SaibleSaible operates both. Dedicated is available on request: a Dedicated instance serves one organisation alone, in an account Saible owns.
- Locations02Regions and locationsThe gateway runs in your network. Saible keeps your records inside the EU or the US, in the region chosen for your organisation.
Console map
Every page of the console, as its navigation shows it. The new console is organised by control coverage. An organisation admin chooses which console people see first. Each name opens the topic that shows it in pictures.
- Overview
- Signals
- AI catalogue
- Policy
- Review queue
- Context
- Ontology
- Exposure
- Recommendations
- Gatewaysadmin
- Emergency stops
- Playground
- Evaluation
- Landscape report
- Audit
- Ledger
- Assessment run
- Registers
- Readiness
- Regulatory scope
- Policy packs
- Evidence pack
- Spend overview
- Invoice check
- Contracts
- Budgets
- Cache
- getting started
- install gateway aws
- install gateway kubernetes
- connect providers
- troubleshooting
For agents
Every page and task in Saible is also documented as Agent Skills: Markdown files that your agents load in Claude, Claude Code, Cursor and other tools to answer questions about Saible and guide your team. The skills will be published in a public repository under Saible's GitHub organisation. Until then, Saible sends them on request.
- ai-literacy
Console v2 Evidence › AI literacy (/console/evidence/literacy): training completions imported from the organisation's learning system, by team and role (EU AI Act Art. 4), and named overseers for each AI system (Arts. 14, 26(2)). Open it for "how do I import training records", "what columns does the CSV need", "do you store employees' emails", "what counts as trained", "what counts as oversight training", "why is a team shown as Smaller groups", "how do I name an overseer".
- assessment-run
The Assessment run at /dashboard/evidence: historical usage from the providers' billing feeds evaluated retrospectively against a versioned policy, endpoint by endpoint, with its assessment records (/dashboard/evidence/records), one record (/dashboard/evidence/[recordId]) and the policy it was assessed against (/dashboard/evidence/policy). Open it for "what is an assessment record", "did Saible refuse these requests", "what does Would be refused mean", "why is the region inferred", "what is the policy content hash", "how is an assessment record different from a decision record", "how do I verify the assessment chain".
- assistant
Saible's assistant: the "Ask Saible" panel opened from the header button, the sidebar or Cmd/Ctrl+K on every console page, the strip of suggested questions under each page header, and the Assistant page at /dashboard/ask. What it reads, what it can and cannot do (it acts as the signed-in person: reads within their role, proposes changes as cards the person runs, never holds a privilege the person lacks), what it never does, which answers are computed rather than written by a model, how it drafts a policy change for a person to propose, where its model runs, and where past conversations are kept. Open it for "what can Ask Saible do", "can the assistant fix my connector", "what is an action card", "why does the assistant ask for MFA", "can the assistant change our policy", "why won't it give me a figure on this page", "where does the assistant's model run", "is the assistant in the EU", "why does it say Ask Saible is off", "can I see my old conversations", "who can read my conversations".
- audit
The Audit page at /dashboard/control/register: what each team said its application would do when registering it, against what Saible saw the application do using its own application key; names on past requests with no key behind them; requests the policy refused; and the deep dive on unusual data outflows by workload at /dashboard/control/register/exfiltration. Open it for "which applications differ from what their team said", "what is a name with no key", "an application used a model it did not list", "why does an application show personal data it said it would not send", "is anyone exfiltrating data", "does Saible score people", "what does Not computed mean", "how do I verify the Audit check".
- budgets
The Budgets page at /dashboard/spend/budgets: each team's monthly budget against billed spend, the month-end projection, recorded spend at list price, the 80% and 100% alerts, cost per unit of work and value against cost. Gateway budgets: a monthly limit for an application or team in the signed policy, checked by the gateway; once the budget is spent, a request is refused when the budget is in enforce mode under an enforcing policy. The new console (/console/spend/budgets) adds budgets on the organisation, an application, an agent, a run, an MCP server or a provider key, with a ladder (alert, route, approve, stop). Open it for "which team is over budget", "how is the projection computed", "how do I set a team budget", "why are billed and recorded different", "what is cost per unit of work", "are budgets enforced at the gateway", "why was my request refused with 429 budget_exhausted", "where do budget alerts go", "can a budget stop an agent", "does a budget work without the gateway".
- business-ontology
The Ontology page at /dashboard/ontology (nav "Ontology", under Control): every business element the organisation's AI touches (datasets, documents, metrics, entities, prompts, tools, agents, models, memory stores, guardrails), turned inside out from the confirmed context manifests: which reader defines each, which applications consume it, every manifest version that carried it, its signals, the lineage picture, and the context relevant to it ranked by a stated heuristic with a reason for every point. Open it for "which applications use this table", "where does this prompt come from", "what is an element", "what does hash variants mean", "how is relevance scored", "is the ranking a model", "why is the ontology empty", "what does the orange ring mean", "can I change the weights".
- cache
The Prompt cache page at /dashboard/spend/cache (nav "Cache", under Spend): for each application observed through the gateway, where its opening text (the system prompt) stops being identical between requests, which cache lifetime suits how often it sends requests, and what caching would save at list price. Open it for "could prompt caching save us money", "why is our system prompt not cacheable", "what changes in our prompt each time", "5-minute or 1-hour cache", "is caching switched on", "does Saible read our prompts to do this", "when does the cache check run", "why can I not open the Cache page".
- catalog
The AI catalogue (Catalogue › Systems at /console/catalog), the claim flow, the agent, MCP server and tool registries, the who-calls-what graph, an application's Access tab, Home's unclaimed-systems card, and Catalogue › Third parties (roadmap). Open it for "what AI do we have", "which keys have no owner", "how do I claim a system", "who owns this AI", "how do I set the AI Act risk class", "what is an owner attestation", "what happens to an unclaimed key", "which agents can write", "has this MCP server changed since review", "which data does this application reach", "who can call this application", "what is Not ours", "can Saible delete an unknown key", "does Saible track the AI inside our vendors".
- claude-code-gateway
Claude Code through a Saible gateway: a gateway instance on an engineer's own machine (or the organisation's gateway), Claude Code pointed at it with the application's key, the routes and model names Claude Code asks for, what each turn records, prompt capture, and what it costs at the provider's API rates. Saible's own engineers work this way; their setup is the worked example. Open it for "can we put Claude Code behind Saible", "does Claude Code work with the gateway", "which model names does Claude Code send", "does this use our Claude subscription", "what does a Claude Code turn cost", "why does every Claude Code request show a detection", "how do I route only some sessions".
- code-scan
The code scan in the Policy page ("From your code" tab and an application's Policy tab): connect an application's repository read-only, see the AI SDKs, models, data fields, decisions about people, tools and processing regions found with the line each sits on, and approve or dismiss the policy packs it suggests. Open it for "what does the scan read", "does my code leave my account", "what is match strength", "who approves a suggestion", "which languages".
- connect-agent-mcp
Connecting an AI agent (Claude Code, Claude Desktop, or any MCP client) to Saible over the Model Context Protocol. Two servers: the context server, by an application's key, which serves the application's approved context with a receipt Saible signs; and the operations server, by a person's own sign-in, which reads the console's API as that person and proposes setup actions that the person confirms in the console with MFA. Open it for "can Claude read our Saible data", "connect Claude Code to Saible", "an MCP server for Saible", "give our agent approved context over MCP", "what can an agent do in Saible", "is an MCP call recorded".
- connect-providers
Connecting a provider's spend feed on the Providers page at /dashboard/settings (nav "Providers", under Settings; /dashboard/connectors redirects there): OpenAI, Anthropic, Google Cloud, Snowflake, Databricks, Azure OpenAI and Amazon Bedrock, what each feed reads, what credentials it needs, how often it syncs, what to do when a sync fails, and which providers also go through the gateway. The same page holds the display currency, the organisation's data export and browser-extension keys. Open it for "how do I connect OpenAI", "what key does Anthropic need", "how do I connect Snowflake without ACCOUNTADMIN", "Databricks service principal", "why does my provider say sync failed", "how often does spend update", "is Bedrock spend only", "where is the credential stored", "how do I disconnect a provider", "change currency to DKK", "export all our data", "browser extension key".
- console-coverage
The new console's Home (/console), the application Coverage tab, Settings (Connections, Trust, More settings) and the switch between the new and classic consoles. Open it for "what does covered / partly / not yet mean", "what does Saible hold for us", "why does Observe say connect your logs", "why is Enforce not yet", "how do I go back to the classic console", "how does an admin set which console people land on", "does the coverage map say we comply".
- context-events
Change events, skew, conflicts and encrypted content in the context layer: a GitHub repository or a Bedrock account telling Saible it changed so the source is read again then; freshness measured from the later of the last read and the last event; the skew between an application's sources and the organisation's skew bound; two sources disagreeing about one element and the system of record a person names for it; and how the full manifest and prompt text are kept encrypted under the corpus key when no bucket is set. Open it for "how do I set up the GitHub webhook", "how do I send Bedrock changes to Saible", "what does updated by event mean", "what is quiet", "what is skew", "how do I change the skew bound", "what is a conflict", "why is Confirm greyed out", "what is a system of record", "where is my prompt text kept without a bucket", "what happens if I destroy the corpus key".
- context-health
Ontology › Health at /console/ontology/health (console v2), and the Context tab of an application: the state of every context the organisation's AI uses in one place, across every source and application. Freshness, skew, conflicts, drift, integrity and lineage, the issues worst first with where to fix each, and the counts kept day by day. Open it for "which sources are stale", "what is skew", "what is drift", "why is integrity red", "what does coverage mean", "why is the trend empty", "is quality checked".
- context-layer
The Context page at /dashboard/context (nav "Context", under Control) and the Context section of each application's page: what each application is wired to (models, prompts, tools, MCP servers, sources, memory, guardrails), read from its own repository and accounts by readers (repo, Bedrock, Snowflake, OpenAI, Databricks, OpenTelemetry traces, the owner's declaration, MCP servers) and confirmed by a person as a signed manifest per version; the context signals, drift, the review-queue item, what Saible keeps of the content, and the context API an application calls with its own key. Open it for "what is a context manifest", "who confirms a manifest", "why can't I confirm it", "what does drift mean", "what is a widening", "how do I connect a source", "what does Saible keep of my prompts", "has this reader been run live", "how does an agent fetch its context".
- contracts
The Contracts page at /dashboard/contracts (nav "Contracts", under Spend): each provider commitment as a burn-down, consumed so far, projected to the term's end at the observed run rate, and what forfeits or runs over; adding a contract by hand or reading it from an uploaded document; and proposing a preference for a second person to approve. Open it for "are we on track to use our commitment", "how much of our Anthropic commitment will we forfeit", "how is the projection computed", "how do I add a contract", "can Saible read the contract PDF", "what happens to the uploaded file", "what does not supported by the text mean", "how do I propose preferring a provider".
- data-map
The data map: which data each AI system reaches through its tools and MCP servers, where that data lives, and how sensitive the platforms' tags and people's declarations say it is; the application's Map tab and the AI catalogue's sensitive-data paths. Open it for "which applications reach personal data", "which AI touches special category data", "what does this agent read", "where does this data go", "does this model get personal data", "what does Not classified mean", "how does Saible know a table holds personal data", "Snowflake Horizon tags", "Unity Catalog tags", "how do I declare what a store holds", "does the gateway mask it", "what do agents hand each other".
- dedicated-saible
The two ways Saible runs an organisation: on the shared service, with many organisations in one Saible region, or as Dedicated Saible, an instance Saible operates for one organisation alone in an AWS account Saible owns. What differs for the customer: the address, where the mail comes from, who operates it, sign-up and demo data, usage, and what is not yet available on a Dedicated instance. Open it for "what is a dedicated instance", "is our Saible shared with other customers", "who runs our instance", "why can't I find my organisation by email", "why did the invitation come from an odd address", "can Saible support see our data", "is the assistant on our instance".
- discovered
What Saible discovers when you connect a source, and how a person confirms it: the proposals listed under Catalogue › Discovered (`/console/catalog/discovered`) and counted on Home; which source gives which kind (an AI application, a spend link, a personal-data tag, a lineage edge, an AI system or setting in a Bedrock account, a team for a system); what each source reads and the privilege each read needs; how sure each proposal is and why; what accepting does, kind by kind; why a proposal is superseded; the records in the evidence ledger; and what is never kept. Open it for "what did Saible find", "why is this proposed", "what happens when I accept", "does accepting change my AWS account", "what does the Snowflake role need", "why is only some lineage proposed", "what does superseded mean", "can I confirm several at once", "who can accept", "is a column's content kept".
- discovery
How the AI inventory is discovered instead of keyed in: what fills the AI catalogue (Catalogue › Systems at `/console/catalog`) from every repository of your GitHub organisation or GitLab group, the platforms you connected and the gateway (the browser extension is coming); the claim flow with split, merge and Not AI; the collector you run for a self-hosted code host and its keys; what is read, what reaches Saible and what never does; and the "discovered, unclaimed" rows on the AI Act inventory and the landscape report. Open it for "do I have to type in our applications", "how does Saible find our AI", "what does the GitHub App need", "does Saible read our source code", "what leaves our network", "we run GitHub Enterprise Server", "what is a collector key", "can Saible reach into our VPC", "what is a candidate", "what is a deployable unit", "how sure is it", "who sets the risk class", "does an unclaimed system count on the report", "what is person-bound".
- doctor-app-key
Fixing an application key that is expiring, expired or revoked, so the application's gateway requests stop being refused: read the application's keys and the maximum age, rotate with an overlap, then revoke the old key once requests have moved. Open it for "application key expiring", "key expired", "gateway refuses my application's key", "rotate the application key", "401 from the gateway", "key maximum age", "revoke the old key".
- doctor-budget
A team budget that is about to be breached or already has been: read the month's position, the projection to month end and the alerts that fired, separate billed from recorded spend, and propose a changed limit only with a figure the person gives. Open it for "will we go over budget", "team budget breached", "budget alert fired", "why is the projection over", "raise the team's budget", "spend outside every budget", "fix my budget".
- doctor-connector
Fixing a provider connection that is failing, stale, expired or never synced (the Providers page at /dashboard/settings): read the connector health and the open faults, test the connection, resync, and rotate the AWS ExternalId when an Amazon Bedrock role stops being assumed. Open it for "my connector is failing", "why did the sync fail", "Bedrock role cannot be assumed", "rotate the ExternalId", "OpenAI key refused", "spend stopped updating", "provider says expired", "fix my connector", "retest the provider".
- doctor-gateway
Diagnosing a gateway that has gone silent, never reported, is on an older policy revision, has records waiting for delivery or could not forward requests, and renewing its credential: read the fleet, then the credentials, and rotate or issue a credential when it has ended. Open it for "my gateway is silent", "gateway not connected", "partial fleet", "could not forward", "records not written", "revision past expiry", "gateway credential expired", "rotate the gateway credential", "fix my gateway".
- doctor-mfa
Admins without MFA, or the organisation's MFA requirement off: read who is enrolled and whether privileged actions require MFA, turn the requirement on, and guide each person through enrolling themselves in the console. Open it for "which admins have no MFA", "turn on MFA for admin actions", "why does the assistant ask for MFA", "my action needs MFA", "MFA is off", "enrol an authenticator", "fix MFA".
- doctor-policy
Fixing a policy that is refusing or flagging requests that should have been allowed: read the decision records and the clause that excluded each, run a what-if over the recorded requests, and propose a narrow policy revision for a second person to approve in the review queue. Open it for "policy is refusing good requests", "why was this request refused", "false positive", "loosen this rule", "what if we dropped this clause", "narrow the policy", "which rule excluded this endpoint", "fix my policy".
- doctor-review-queue
Working through a review queue backlog with the person: list what is waiting, explain each item and its computed impact in plain words, and approve or reject the ones the person decides on, never an item that person proposed themselves. Open it for "review queue is backed up", "what is waiting for approval", "explain this proposal", "what happens if I approve this", "approve the pending changes", "why can't I approve my own change".
- emergency-stops
The Emergency stops page at /dashboard/gateways/stops (Control on the navigation): stop one run, agent, workload or application at every gateway, or cut one application off from sensitive data, in every mode including record-only; the alerts that recommend a stop and wait for a person to approve or dismiss; automatic action after a wait; and lifting. Open it for "how do I stop a runaway agent", "stop an application now", "does a stop work in record-only mode", "how fast does a stop reach the gateways", "what does a stopped application see", "who can approve an alert", "why was this stopped automatically", "how do I lift a stop", "can I stop a person", "what does restrict sensitive data do", "what are the checks and thresholds".
- evaluation-workbench
The Evaluation workbench at /dashboard/evaluation (nav "Evaluation", under Control): an application's golden sets (written, synthesised, from an opted-in workload, uploaded as JSONL, or imported from the public baseline catalogue), side-by-side runs of up to four candidate models with every request decided by the policy in force, validation packs sealed in the review queue, regression reruns with their diff, Saible-hosted Bedrock candidates, and the Saible standing baseline with its fallback rule. Open it for "how do I compare models on our own prompts", "what is a golden set", "why can't I seal this run", "who seals a validation pack", "what does Saible baseline in use mean", "is the judge's score a verdict", "why is this candidate not callable", "what does Regress now do", "which public datasets can I import".
- evidence-ledger
Console v2 Evidence: the Ledger (/console/evidence), Readiness (/console/evidence/readiness), Reports (/console/evidence/reports) and an application's Evidence tab. Open it for "what kinds of evidence record are there", "how strong is an attestation compared with a snapshot", "how do I verify the chain", "what does Verify chain write", "what is a sealed segment", "can a ledger record be changed", "what does readiness by article show", "is readiness a verdict", "what does sealed mean for a report", "how do I share the landscape report with a reviewer".
- evidence-pack
The Evidence pack page at /dashboard/evidence/export (nav "Evidence pack", under Evidence): the zip you hand to an auditor or a supervisor, with the assessment records, the policy that produced them, the model catalogue, the registers, the request records for a window you choose, readiness as computed at export, and who approved what, with the hashes to check them. Open it for "what is in the evidence pack", "how does an auditor check it", "is the pack signed", "what is manifest.json", "what does chainHeadHash mean", "can I leave the request records out", "why did the download fail", "does exporting need MFA".
- exposure-report
The Exposure page at /dashboard/exposure (nav "Exposure", under Control) and the Exposure card on Home: what each connected AI platform (OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Snowflake Cortex, Databricks serving) lets through at configuration time, read through the credentials the spend connectors already hold; the findings with where each is fixed and the script that fixes it; the evidence coverage score; chained configuration snapshots and drift; and the exposure report sealed in the review queue. Open it for "what is the coverage score", "why is tamper-evident record 0%", "what does this finding mean", "who can resolve a finding", "does Saible change anything on our platform", "what grant does the exposure reader need", "why could the run not read a source", "how do I seal the exposure report", "is the exposure report in the evidence pack".
- gateway-extras
The console v2 Gateway screen at /console/gateway, with Emergency stops (/console/gateway/stops) and Fleet (/console/gateway/fleet): the seven steps every request goes through, a playback of a window of records as it happened, decisions per day, data classes and labels, routing savings, the response cache in shadow mode, the per-request context check (record schema 5) and rollout per application. Open it for "what does the gateway do to a request", "replay what happened when the agent was stopped", "how much did routing save", "what would a cache save", "what is X-Saible-Context", "why does a step say shadow or roadmap", "which gateways are live".
- gateways
The Gateways page at /dashboard/gateways (Control on the navigation, organisation admins only): every gateway instance, the policy revision and mode each one runs, whether the latest approved revision has reached every live instance, how far records are behind, what could not be forwarded, and the credentials that connect a gateway deployment (Add a gateway, Issue, Rotate, Revoke, the AWS account). Open it for "is my gateway connected", "which policy revision is each gateway enforcing", "why does it say partial fleet", "what does silent mean", "what does could not forward mean", "records waiting for delivery", "revision past expiry", "how do I add a gateway", "how do I rotate the gateway credential", "when does the gateway credential expire", "why does Saible want our AWS account id", "why can't I see the Gateways page".
- getting-started
The first steps with Saible, from asking for access to the first request on the record: the request form and the call, Saible creating the organisation and its trial, signing in at the organisation's own address, enrolling an authenticator, inviting people, connecting a provider's spend feed, registering an application and getting its application key, installing a gateway, and finding the first record in the Ledger. Open it for "how do we sign up", "where do I sign in", "I got an invitation email", "what is my organisation's address", "which Saible region is our data in", "why does every page say Sample data", "how do I see sample data", "what are the first steps", "how long is the trial", "what do we do first", "how does an application get a key", "when do we see our first request".
- home
The console's first page at /dashboard (nav "Overview", under Home): the four decision outcomes over the last 90 days, approved applications and what needs a decision, personal data caught, the billed spend, what needs attention, connector health, requests per day, the picture of where requests went (Flow, Replay, Network), and what Saible cannot see. Open it for "what does the home page show", "what is waiting on a decision", "what does Needs a decision mean", "why is an application waiting on someone", "where did our requests go", "what does Routed mean", "is a provider feed failing", "what does Stale mean on Connectors", "why is the home page empty or showing an error", "does Home show all our AI".
- human-ai-use
The AI use by team screen (Catalogue › People) and the Home "AI use by team" card: which AI services staff use in the browser, by team, whether each is approved, tolerated or not approved; reporting coverage of the browser extension; and seats, active use and unused seats of ChatGPT Enterprise, Microsoft 365 Copilot and Claude Enterprise, with the monthly cost of seats nobody used in 30 days. Open it for "which AI services do our people use", "is ChatGPT approved here", "which teams use unapproved AI", "how many Copilot seats are unused", "what do unused seats cost", "does Saible see who used what", "how do I connect the compliance export".
- incidents
Console v2 Evidence › Incidents (/console/evidence/incidents): an incident from an emergency stop, a rogue-agent signal or a person, its timeline, what it touched, the DORA, GDPR and EU AI Act clocks, fixes linked to controls and the review. Open it for "how do I open an incident from a stop", "when is the GDPR notification due", "what are the DORA reporting deadlines", "does Saible decide whether an incident is reportable", "what does time to stop measure", "what did the incident touch".
- install-gateway-aws
Installing the Saible gateway in your own AWS account with the ECS (Fargate) Terraform module, from issuing the credential on the Gateways page to one request served in record-only mode, the /healthz check, and seeing its record arrive. States what has and has not been tested, and where. Open it for "how do I install the gateway on AWS", "what do I need before I start", "which hosts must the gateway reach", "what leaves our network", "where do I get the image", "how do I point an application at the gateway", "how do I check it works", "how do I know a record arrived", "does the gateway change our requests in record-only mode", "how do we bypass or roll back", "has this been tested", "how much latency does it add".
- install-gateway-kubernetes
Installing the Saible gateway on Kubernetes (written for EKS) with the manifests in gateway/deploy/kubernetes, from issuing the credential on the Gateways page to one request served in record-only mode, the /healthz check, and seeing its record arrive. The manifests render and validate; they have not yet run on a cluster. Open it for "how do I install the gateway on Kubernetes", "on EKS", "kubectl apply -k", "what goes in the Secret", "how does the gateway reach S3 and KMS from a pod", "Pod Identity or IRSA", "how do I put TLS in front of it", "has this run on a cluster", "how do I check it works", "how do I know a record arrived".
- invoice-check
The Invoice check at /dashboard/control/money (nav "Invoice check", under Spend): the providers' bills set against the requests Saible recorded. Bill lines a recorded request explains, the ones nothing explains, requests recorded with no bill line, and the bill checked against itself and the list price. Open it for "does the bill match what we sent", "why is so much of the bill not explained", "why is a request missing from the invoice", "what does as billed, list price or invoice-reconciled mean", "when does the invoice check run", "is this an audit of the provider's invoice", "why can I not open the Invoice check".
- landscape-report
The Landscape report at /dashboard/evidence/landscape: one report on what AI is in use in the organisation, from its own records. The providers, models and applications in use, declared against observed; shadow AI; spend by provider, model and team over the last 90 days of bills, with the share attributed to a team; the articles of the GDPR, the AI Act and DORA with evidence held, partly or not yet; and what is not yet evidenced, ranked by severity. Prints to PDF. Open it for "what AI do we use", "how much shadow AI is there", "how much of our spend is attributed to a team", "what are our biggest readiness gaps", "why does a figure say not held", "how do I get the report as a PDF", "where does each figure come from".
- ledger
The Ledger at /dashboard/decisions (every request Saible recorded, by application: allowed, redacted, routed or refused), one decision record at /dashboard/decisions/[decisionId], one saved check at /dashboard/statements/[statementId], and the hidden Audit Trail at /dashboard/audit (the console's access log). Open it for "what does a decision record hold", "does Saible keep my prompt", "what does redacted mean on a record", "what is record-only on a record", "what does a refusal reason code mean", "how do I verify the chain", "what does Chain broken mean", "can a record be changed", "is the ledger signed", "how do I filter the ledger by model or date", "how do I export the ledger", "how do I hide configuration changes", "where does a number on the Audit page come from", "who changed what in the console".
- live-context
Live context: what an application's agents are told is true about a subject right now, and why they should believe it. The resolve call by application key, freshness from each source's own rate of change, the precedence order when sources disagree, contested and unresolved claims, agent writes held in quarantine, each application's trust setting, user feedback, the signed receipt and the context Saible kept out of the model's prompt (avoided claims and an estimate of avoided tokens). The application page shows the items, their approval and what the gateway recorded. Open it for "how fresh is the context my agent gets", "what happens when two sources disagree", "can an agent write context", "who approves an agent's write", "what is in the receipt", "how many tokens does this save", "what does the 82% figure mean".
- mcp-connected-systems
Connected systems (MCP) on the Context page (/dashboard/context): the organisation's MCP servers for Confluence, SharePoint, Salesforce, Google Drive or any other streamable HTTP server, which Saible reads to learn the documents, prompts and tools an application uses. Registering a server with its OAuth token and least-privilege scopes, testing it, attaching it to an application with what is in scope, what the reader sends and what it keeps, the in-scope and seen-not-in-scope counts, and who may do each with MFA. Open it for "how do I connect Confluence", "which OAuth scopes does Saible need", "does Saible call MCP tools", "what does seen, not in scope mean", "does Saible read my documents", "where is my token kept", "why is the token refused", "has this been tested against SharePoint".
- model-lab
The Model lab at /console/models and the Evaluations tab of an application: every model Saible can compare (Bedrock models in the stack's region, open-weight models imported with Custom Model Import, and your own providers), scored on your data classes and your golden sets, quality beside cost, with a best-value pointer and proposals into the review queue. Open it for "which model should this application use", "can we use a cheaper model without losing quality", "how do I compare an open-weight model", "what does the score mean", "is the judge's score a verdict", "can the lab switch a model for me", "why can't I propose a switch for this application", "what is the model change guard".
- observe
Observe without the gateway: per-request metadata read from the customer's own AI platform logs (Bedrock model invocation logs, Databricks inference tables, Snowflake Cortex usage history, OpenTelemetry GenAI spans), checked against the policy in force, one chained observed check per application and day; shown on an application's Requests tab (/console/apps/[id]?tab=calls). Open it for "can Saible see our requests without the gateway", "which logs does Saible read", "does Saible read our prompts", "how do I send OpenTelemetry to Saible", "what is an observed check", "how strong is observed evidence", "why is a request not checkable", "what does outside policy mean on the Requests tab".
- older-pages
Older console pages that are reachable by address but not offered on the navigation: /dashboard/roi, /dashboard/playbook, /dashboard/mcp, /dashboard/chargeback, /dashboard/alerts and /dashboard/shadow-ai. What each shows, where its figures come from, and which current page covers the same ground. Open it for "where is the ROI page", "what is the playbook", "what are MCP connections", "how do I get a chargeback report", "how do I set a spend alert", "where is shadow AI", "why is this page not in the menu", "can I trust the figures on this page".
- ontology
Ontology › Explore at /console/ontology (console v2): business concepts across every source (Snowflake, Databricks, dbt in git, Confluence, Jira, and the elements each application's confirmed context carries), the same-as links between them with how each was matched and its confidence, the trusted (authoritative) source a person names, where definitions disagree, the AI that uses each concept, and Ask, which answers a term or question with a signed receipt. Open it for "what is a concept", "why is this link dashed", "what does 0.85 mean", "who decides the trusted source", "why is a document never trusted", "what counts as a conflict", "is the answer written by a model", "why is my table not a concept", "what is a receipt".
- ontology-api
Ontology › API at /console/ontology/api (console v2) and the ontology API itself: POST /api/v1/ontology/resolve and the MCP tools resolve_concept and search_concepts at POST /api/v1/ontology/mcp, called with an application's own key. A business concept answered under the application's context contract (maximum staleness, data classes, what to do on a conflict) with a receipt signed with Saible's policy revision signing key. Open it for "how does an agent ask for a concept", "what is a context contract", "why was my agent refused", "what does warned mean", "how do I verify a receipt", "does the API return data", "what does the MCP server expose".
- ontology-sources
Console v2 Ontology › Sources (/console/ontology/sources): the organisation-level systems the business ontology is read from (a dbt project and docs in git, Snowflake, Databricks Unity Catalog, Jira, Confluence), how current each is, what it holds and what it could not read. Open it for "how do I connect dbt", "do you read our tables' rows", "which Snowflake grants do you need", "why is a source partial", "why is a source stale", "where do our descriptions and page text go", "what does meaning extraction do", "do you read Jira assignees", "what lineage do you get".
- playground
The Playground at /dashboard/playground: replay Saible's golden sets or one of your opted-in workloads through the model in use and up to four candidate models, compare what can be measured, see which applications a switch would touch and what it would cost at list, and propose it. Also the hidden engineering pages /dashboard/control/models ("Models · engineering") and /dashboard/models ("Models"). Open it for "could another model do this work", "how do I compare two models", "what does equivalent on what we measured mean", "why is there no verdict", "does the judge decide", "which applications would a model switch touch", "why can't I pick this endpoint", "what does a replay cost".
- policy
The Policy page at /dashboard/policy: the rules in force as sentences, a replay of a rule change over what already happened, the policy's mode (Enforce, Advisory, Record only), and the signed policy revision that carries the rules to the gateways, proposed by one person and approved by a second. Also one policy revision at /dashboard/bundles/[revision] and the older /dashboard/policies page. Open it for "what rules are in force", "what would happen if I dropped or added a rule", "how do I propose a policy change", "can the assistant draft a rule", "what is the difference between record-only and advisory", "who signs the policy revision", "why was my approval refused", "what does a policy revision put in force", "why must I confirm a switch to enforce", "what policy does a new organisation start on".
- policy-packs
The Policy packs page at /dashboard/evidence/packs (nav "Policy packs", under Evidence): the obligations of the GDPR, the EU AI Act and DORA as Saible published them, each quoted from the consolidated text on EUR-Lex with its link, the readiness your records show per obligation, the policy rules a pack adds, the evidence only you can supply, and how to propose adopting a pack. Open it for "what does the GDPR pack contain", "where does this obligation's wording come from", "is this the legally binding text", "what happens when I adopt a pack", "does adopting a pack make us compliant", "why is an obligation Not assessed", "who may propose a pack", "do packs update themselves".
- policy-registry
The Policy page in the control-coverage console at /console/policy: the policy catalogue (every rule in force or waiting, searchable and filterable), packs per regulation and region, the scope view and endpoint catalogue, and an application's Policy tab. Open it for "where is every policy", "what does this rule do today", "is this rule enforced", "why does it say needs the gateway", "which rules reach this application", "which packs exist", "what is waiting for approval", "how do I stop an application".
- readiness
The Readiness page at /console/evidence/readiness (nav "Readiness", under Evidence): for the EU AI Act (deployer), DORA and the GDPR, twelve article rows, each with the evidence Saible holds today, a status (held, partly held, not yet) and the step that closes the gap. A second card lists security controls for the CISO. A map of evidence, never a score. Every pack, report and answer uses this same article set. Open it for "are we GDPR ready", "what evidence do we have for AI Act Art. 26(6)", "what does In part mean", "what is our DORA readiness", "why is Art. 35 Not yet", "what happened to the classic Readiness page", "is this a score".
- recommendations
The Recommendations page at /dashboard/recommendations: each night, an opted-in workload's own eval-corpus items replayed against other approved models; what was found equivalent on every measured property at lower cost or latency is proposed into the review queue and never applied without approval; nudges for applications that name their model; Bedrock evidence; and what the replays cost Saible. Open it for "why is Saible recommending a model switch", "how is a recommendation decided", "will Saible change my model", "what is a nudge", "why was my workload not replayed", "how many items does a verdict need", "does the judge decide", "who pays for the replays".
- registers
The Registers page at /dashboard/evidence/registers (nav "Registers", under Evidence): what the organisation declared against what the records show, and the parts of the DORA register of information, the GDPR Art. 30 record and the AI Act inventory that Saible's records can evidence, each field with its source and what no record holds named. Open it for "do we have a DORA register", "can Saible give me our Art. 30 record", "which applications are in use but not registered", "which providers billed us with no contract", "what does Held, Partly, Not yet mean on a register field", "why is criticality empty", "how do I rerun the register check".
- registry
The Registry at /dashboard/applications (nav "Registry", under Control) and each application's page at /dashboard/applications/[appId]: every application, agent and script with its own application key, the models each may use, where each stands (provisional, narrowed, approved, stopped), who it waits on, its keys, and the model catalogue. Also the hidden Teams page (/dashboard/teams) and the unlinked /dashboard/agents. Open it for "how do I register an application", "how do I get an application key", "who approves an application", "why can't I approve my own request", "what happens if nobody approves", "what does provisional mean", "how do I rotate or revoke a key", "what is the maximum key age", "how do I stop an application", "how do I retire or remove a test application", "why is my application refused", "how do I register an agent", "where do I define teams", "which models are approved", "which models may this application use".
- regulatory-scope
The Regulatory scope page at /dashboard/evidence/scope (nav "Regulatory scope", under Evidence): which AI laws and guidance may apply to your organisation worldwide, worked out from a profile you give (where your AI reaches people, where you are established, your role, sector, AI use cases, data and size), and the one de-duplicated list of controls that serves them, each with the requirements behind it and the date it is needed by. Open it for "which AI laws apply to us", "do we need to worry about the EU AI Act / Colorado / Korea", "what do we have to do for AI", "why is this control listed", "what does to verify mean", "what does depends on a figure mean", "does this make us compliant", "who can change our profile", "how does Saible know when a law changes".
- release-gate
How Saible tests a change before it reaches an organisation: the local gate every change passes on the developer's machine against the whole product running together, the pull request's automated checks, the merge rule, and the release that goes to Saible's own Dedicated instance first and then to the shared service's regions, with the checks after each. What exists today and what does not yet. Open it for "how do you test before you ship", "how do releases reach our instance", "can a release break our gateway", "what is checked before a change goes live", "do you have a staging environment".
- review-queue
The review queue at /dashboard/review: every change waiting on a decision (policy revisions, detection patterns, workload label profiles, application approvals, recommendations, validation packs, evaluation regressions, context manifests, exposure reports, contract terms, policy revision signing keys), each with the impact replayed over the organisation's own recorded requests, and the organisation's two approval settings. Also the hidden /dashboard/proposals page. Open it for "who approves a policy change", "why can't I approve my own proposal", "what does the impact on a review card mean", "why is Approve greyed out", "what is four eyes", "is an approval recorded", "how old is the impact", "why can't I decide this item here".
- savings
The Savings page at /console/spend/savings (Spend, Savings): every saving Saible found, in one list, with how it was computed. Open it for "where can we cut AI cost", "are we using prompt caching", "which jobs could use the batch API", "how much do failed requests and runaway loops cost", "what is a realised saving", "how do you know we really saved that", "what is an idle commitment", "why is a saving in the review queue".
- settings
The Settings pages except Providers: Security, Roles and people, Your identifiers, Evaluation corpus, Prompt capture, Usage, Saible access (Saible's requests to read the console for support, approved by an admin with MFA) and Statements (the closed monthly usage statement), one reference file per page. Open it for "how do I turn on MFA", "how do I invite a colleague", "what can a viewer do", "how do I add our member number so the gateway finds it", "what is the eval corpus", "does Saible keep our prompts", "how do I erase the corpus", "how do I store prompts in our own S3 bucket", "is the rate card final", "can Saible see our console", "how do I revoke Saible's access", "where is our monthly statement", "how do I remove a person", "why was I refused after being removed", "where do alerts go", "who gets budget alerts".
- signals
The Signals page at /dashboard/signals (nav "Signals", under Home): what Saible learned about your AI per workload: what each workload does, how each model performs on it, which model for each job where a replay found an equivalent, where the risk sits, where money is wasted, agent runs and unusual days, and the spend forecast; plus spend drivers, team and application rollups and readiness. Also the hidden Forecast page (/dashboard/forecast) and the unlinked pages /dashboard/risk and /dashboard/kpis. Open it for "what are our workloads", "which model is best for this job", "how much are we wasting", "are any agents running away", "what will we spend next month", "how is the forecast computed", "what counts as an anomaly", "is this label reliable", "why does Signals say not computed", "can Saible stop a runaway agent".
- spend
Spend in the new console (/console/spend, nav "Spend"; tabs Overview and By application): AI spend per day and platform read from each provider's billing feed, month to date against the organisation's budget and projected to month end, spend per application, agent and MCP server across platforms, the owning team from the registry, spend no system owns, tool and MCP fees, seats organisation-wide, commitments, and cost per unit of work. Open it for "how much did we spend on AI this month", "which application costs most", "what spend has no owner", "how do I place an unknown key's spend on a system", "spend by team", "how many ChatGPT seats are used", "how much of the Azure commitment is used", "what is cost per unit of work", "how do I set the manual cost per unit", "is spend shown per person".
- spend-overview
The Spend overview at /dashboard/overview (nav "Spend overview", under Spend) and one provider's page at /dashboard/[provider]: what the providers' own billing feeds report, cost by provider and by token-billed model, the trend by day, token economics, and the total in the organisation's display currency. Open it for "how much did we spend on AI", "which model costs the most", "what is our annual run-rate", "what is the blended rate per million tokens", "why is a DKK or EUR bill not in the dollar total", "how is the total converted to DKK", "what does the dashed line on the chart mean", "why is the page empty", "how do I export the usage as CSV", "how do I sync one provider now".
- troubleshooting
What a customer sees when something goes wrong, and what to do: an application refused or answered with an error by the gateway (401 unknown key, 403 access stopped, 403 emergency stop, 503 no route, could not forward), a gateway that will not start or answers 503 on /healthz, a silent instance, records waiting to be delivered, a stale policy revision, a provider feed that does not land, "This action needs multi-factor authentication", and 403 on admin-only pages. Every message is quoted from the code. Open it for "why did the gateway refuse my request", "Saible did not forward this request", "Saible refused this request", "the application key presented", "emergency stop is in force", "my gateway shows silent", "records are not reaching Saible", "revision past expiry", "the gateway exits at start with config:", "my provider has not synced", "Last sync failed", "MFA required", "Role not permitted", "why can't I see this page".
- write-back
Write-back at /console/policy/write-back (Policy › Write-back in console v2), the Configuration tab of an application, and the write-back modes on the Write-back page: a change to an AI platform's configuration that Saible proposes (from a finding, a budget step, a stop, or by hand), dry-runs against a fresh read of the platform, a person approves (one approver for a reversible setting, two for IAM, deletion or a stop), Saible applies through the platform's own API under a separate write role, re-reads to verify, and can roll back. Open it for "how do I fix a finding without the gateway", "what is a dry run", "who approves a write-back", "why two approvers", "what is Propose only", "what is the write role", "does Saible ever write on its own", "how do I roll back a change", "what happens if the platform changed since approval", "which platforms can Saible write to", "how does a budget step stop an application", "what does fixable by write-back mean".