The questions, answered before you ask them.

Be precise about which data. Everything at rest stays in your account, in the storage region you chose: uploaded documents, the knowledge index, chat sessions and messages, usage and metering records, module data, logs. What does not stay is the content of an inference call: your prompt and its answer are processed by the managed model service, inside your account's billing and identity perimeter, under terms where prompts are not retained for training or shared with model vendors.

What holds that in place is not our word. Cloud identity policy denies inference outside the configured endpoint regions, denies inference that bypasses the governed route, and denies any workload widening the account's retention election. That is why we write "data at rest stays in your account" and never "nothing leaves". The boundary.

No. Model invocation logging records the model, the caller's identity, latency and token counts, and deliberately carries no prompt or answer text. Chat sessions and messages are stored in your own account, because a chat product without history is not usable, and an administrator reading a user's transcript is a separate action that writes its own audit record. Administration.

No. Every deployment starts in a zero-retention posture: prompts are not used to train models and are not shared with model vendors, per the managed model service's terms. There is one exception and it is visible rather than silent. One vendor's newest frontier tier is offered only with provider-side data sharing and retention of up to 30 days; those models show as unavailable until you make that election explicitly, and a deny prevents any workload widening it on its own. Model access.

Yes, and this is the most important limit on the page. Anything loaded into a deployment's knowledge base is readable by every user of that deployment. Per-user or per-document permissions on retrieval are not built, so the control today is what you choose to load. Load what everyone in that deployment may see, and keep the rest out of the index. Chat and knowledge.

At the Baseline posture, none: no cross-account role for us exists at all, and work is done with credentials you grant. At Standard and Strict our management access is a scoped, session-capped role you can see, audit and revoke. What we hold on our own infrastructure is the platform source, the deployment factory and your parameter file. We hold no client data. Shared responsibility.

Storage, yes: the storage region is chosen per deployment, and documents, index, sessions and logs sit there. Inference is a separate question, because routing decides where a request is processed. A deployment can hold everything at rest in Canada and still have inference processed elsewhere unless it is pinned, and pinning has a real capability cost. We ask both questions separately in the questionnaire and write both answers into your posture. Data residency.

No. We hold no third-party attestation of any kind, of either type. What exists instead is a controls matrix mapping 17 technical control rows to SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A, each with an enforced, partial or not-enforced verdict, plus the resolved posture object for your deployment and its standing exceptions. A SOC 2 report is issued by an independent audit firm; no vendor can hand you one. Compliance alignment.

It is evidence about their controls, not about your obligation. A report covers the scope the vendor chose, in the period they chose, and it says nothing about where your data flows once it is inside their product or whether your own program is satisfied. Compliance obligations do not transfer with a certificate. The question your reviewer has to answer is whether the data flow can be scoped and evidenced, which is a different question from whether the vendor has a report. SaaS AI assistants compared.

Four denies in cloud identity policy, on the chat role and on every module inference role: no inference without your content policy, none outside the configured endpoint regions, none that bypasses the governed route, and no widening of the account's retention election. They are evaluated by the cloud provider before a request reaches a service, using credentials the application cannot widen, and tests fail the build if one is weakened. Enforced in cloud policy.

Usually Standard. Baseline is the low-cost entry posture and we describe it honestly: single-account isolation, encryption in transit and at rest, the mandatory content policy, least-privilege identity policy and everything as code, with no private networking and no account audit trail. That suits low-sensitivity use and a first evaluation. Standard adds the private network endpoint, account-level audit logging, provider-managed keys, enforced MFA and scoped management access. Strict adds customer-managed keys and the residency pin. Posture tiers.

Three things, in order. The posture questionnaire, published in full summary so your reviewer can read it before the call. The evidence pack: the controls matrix with its verdicts, your resolved posture object, the data-flow description, the shared-responsibility split and the standing exceptions. Then an architecture walk where questions we cannot answer become items with owners, and gaps go onto your plan page rather than into a drawer. Evidence pack.

There is a page for it, maintained against ourselves, and it is the one to read before a design review rather than after one. It sets out what the product does and does not do in one place, with the reason in each case, so your reviewer is reading our own list rather than assembling one. What we do not claim.

No. Administrators manage users, roles, grants, quotas and module channels at run time. They cannot change the model allowlist, the content policy, the posture, residency, or admit a module: those are deploy-time parameters changed through a release. The policy itself is held by a deny in cloud identity policy rather than by the application, so there is no switch to find. Administration.

The catalogue is generated from the provider's live model list by a script and classified by where inference actually runs, so it is never retyped into copy. At the last generation, 5 September 2026, it held 104 active models from 18 labs. Which of those a deployment may call is set by its allowlist, a deploy-time parameter, and by its residency posture. Frontier models from the major labs are available where your posture allows the route. Model access.

Then the conversation is about fit and route, not brand loyalty. If the model is in the generated catalogue and your posture allows the route it needs, you can have it, and switching to it later is a configuration change rather than a migration. If your deployment is pinned to a jurisdiction the model has no route inside, the request is refused with a reason instead of being quietly served from somewhere else. That refusal is the feature. Model access.

It happens, and the product does not pretend otherwise. General chat can be confidently wrong, exactly like the assistant your people already use at home. Knowledge base answers are better bounded: they return citations to the source documents, and the assistant declines when retrieval finds nothing, after retrying with alternative phrasings.

One limit belongs in the same breath: citations are returned but not independently validated, so a citation is a pointer to check rather than a proof. The operating rule is the old one: a human accepts any consequential output, and anything that has to add up should be computed rather than generated. Chat and knowledge.

Capability, measurably. Of the 104 active models in the catalogue, 13 run in-region in Canada and one more routes within Canada only; 18 are reachable but processed outside Canada, and 72 are served from US and global regions. The in-Canada generation set is previous-generation: Claude 3 Sonnet and Haiku, Llama 3 8B and 70B, Mistral Large 24.02, Mixtral 8x7B, Mistral 7B. Every current frontier model routes outside Canada. Residency is a real choice with a real price, and the numbers are in front of you before you make it. Data residency.

Partly, and here is the honest split. Models are replaceable: they sit behind the platform's own application layer, so changing model is configuration rather than a migration. The cloud is not replaceable in the same way. The platform is deeply built on one provider's services, and moving it to another would be a rebuild rather than a migration. What protects you is that the account, the data and the deployed platform are already yours, and that the exit does not depend on us existing. Composable AI.

No. Your prompts are not used for training and are not shared with model vendors under the default retention posture, and we do not fine-tune anything on your documents. Where your own knowledge matters, the platform retrieves from it at question time instead, which keeps the knowledge current, keeps it inside your account and keeps it deletable. Chat and knowledge.

The platform keeps running, because it is in your account and the monthly fee buys the service rather than access. You keep the deployed platform, its source and its data. What stops is us: releases, checks, changes and the direct line. Be realistic about the other side of that: operating it afterwards needs a competent cloud engineer, which is exactly why runbooks and infrastructure as code are deliverables rather than favours. Ownership and exit.

The cloud account and everything in it: the deployed platform, the stores, the documents, the index, the logs, the module data. The infrastructure code and runbooks that stand it up. The deliverables from the engagement. You are the account holder and the payer of record, and at the Baseline posture there is no cross-account role for us at all. You are not buying seats. You are buying a private AI platform on your own cloud, yours to keep. Ownership and exit.

Not without a rebuild, and that is the exact answer rather than a portability story you would test during a migration. The platform is deeply built on one provider's identity, storage, inference and policy services, and those are precisely the parts that make the governance real. What is portable is your data, your documents and your own module logic. Composable refers to models, not clouds. Composable AI.

The risk is real, and three things bound it. You own the account, the billing, the data and the deployed platform, so nothing is held hostage by our continued existence. The engagement produces infrastructure as code, runbooks and architecture records another provider could pick up, which is why they are deliverables. And the work is deliberately mechanical: tagged releases, scripts, checks and a written journal rather than knowledge that lives in one head. Continuity.

It is written down before anything is deployed, not negotiated after an incident. We own the platform contract, the control plane, the deployment standard and the controls we operate, including technical remediation of a defect in them. You own data quality, priorities, grants, any logic your own people author, acceptance and your own risk decisions. Either side can pause a deployment, and that authority is part of the agreement rather than a courtesy. Shared responsibility.

With the strategic assessment. It is $2,500, bounded, and it ends in a written assessment you keep whether or not you proceed: an environment and data-flow map, a recommended posture with reasons, a first-capabilities shortlist tied to outcomes you choose, an estimate of what it would cost to run on your cloud bill, and a go or no-go recommendation that is genuinely allowed to be no. Strategic assessment.

An hour or two with the people who can answer for security or privacy, for operations, and for IT. An honest picture of what AI your people already use, sanctioned or not. Your identity setup, any existing acceptable-use or AI policy, where the documents people would want to ask about actually live, any residency or contractual constraints on your data, and one or two processes where delay or rework hurts. There is a preparation page with the whole list. Assessment prep.

The shape is this: one command deploys the stacks, and a checklist of manual steps surrounds it, including account and identity configuration, certificates, DNS, and the first users and roles. We quote no fixed number of days on this site; you get a schedule for your own engagement, in writing, once we have seen your environment. Deployment.

Then keep it if it is working, and do not compare on features, because you will get a long list either way. Compare on two things: whether your data flow can be scoped and evidenced to your reviewer's satisfaction, and whether you can build your own governed capability on top of it. A suite assistant is a seat in somebody else's product, and the data boundary is the argument, not the feature grid. SaaS AI assistants compared.

You can, and a capable team will get a demo running quickly. The distance is in everything after the demo: identity and roles, a policy that is enforced outside the application, metering that settles against the provider's record, per-module isolation and short-lived credentials, a release and drift discipline, and the evidence a security review asks for. That is the part that takes quarters, and it is the part nobody budgets for. Building it yourself.

That is the design, and it is in pilot rather than in general use. The authoring kit, validator, scaffold and publish path are built, and the whole path is proven end to end by us acting as the client. The first client-authored build is a pilot. Client modules in use today run on the staging channel, and the production promotion path is built and exercised on our own deployment. Developer modules.

No. What managed operations is: a direct line to the person who built the system, with no queue and no first-line triage, releases cut and rolled deliberately, drift and difference checks before a change, acceptance runs against the live deployment afterwards, cost watch, and a dated operations journal you can read. We publish no response-time or uptime commitment. If round-the-clock cover is a hard requirement, say so early. Managed operations.