Whoever signs the contract, you are the one who gets the call at four o'clock on a Friday. This page is written for that.
Everything here runs in a cloud account your organization owns and is billed for directly. That means you can read every resource, every policy and every log without asking us, and it means the questions below have answers you can verify rather than accept.
One deployment is one organization in one cloud account. There is no shared plane, no multi-tenant database with a customer column, and nothing of yours on our infrastructure. What follows is the whole inventory, not a highlights reel.
| Component | What it is | Worth knowing |
|---|---|---|
| Dashboard | White-labelled web application, branded as yours at build time | Your name on it, not ours |
| Chat over frontier models | General chat with per-person metering and an optional knowledge base | Knowledge base is PDF only today, and shared across all users of the deployment |
| Content policy | A pinned, numbered guardrail version applied to every inference call | Enforced by cloud identity policy as a deny, not by application code |
| Model gateway | Access to a catalogue generated from the provider's live list | 104 active models from 18 labs at 5 September 2026, classified by where inference runs |
| Administration area | Users, roles as identity groups, runtime-editable grants, access matrix, quotas, usage by person | An administrator reading a transcript is itself written to the audit record |
| Module runtime | Business applications on their own isolated origins, framed in the dashboard | Per-request content security policy from the manifest, 5-minute assertions, 15-minute credentials |
| Invocation logging | Model, caller identity, latency, token counts | Deliberately no prompt or answer text. Do not promise your auditors otherwise |
| The "your plan" page | Your deployment's resolved controls and its standing exceptions, inside the product | Generated from the same typed object that builds the infrastructure. A test fails the build if they disagree |
Platform infrastructure, excluding inference, has run roughly $5 to $10 a month at Baseline and about $110 a month on the private-network tiers. One deployment with light team usage has run an estimated $40 to $120 a month all in. These are figures we have seen rather than a quote, and your own bill will depend on usage, tier and region. Budget alarms are set with you at deployment and watched as part of managed operations. The cost detail.
The split is deliberate and it is the thing most worth understanding before you inherit this. Anything that changes who can do what is editable at runtime. Anything that changes what the system is permitted to do at all requires a release. Nothing in the running system can create a role.
| Change | At runtime, by an administrator | Only through a release |
|---|---|---|
| Add or remove a user | ✓Yes | n/a |
| Change a role's grants | ✓Yes, no redeploy | n/a |
| Set or change a per-person quota | ✓Yes, fails closed when reached | n/a |
| Read a user's chat transcript | △Yes, and the read is audited | n/a |
| Promote a module version to production | △A named administrator approves an exact artifact hash | Admission itself is fixed at deploy time |
| Add a model to the allowlist | ✕No | ✓Deploy-time parameter |
| Change the content policy | ✕No | ✓New pinned version, through a release |
| Change posture tier or residency | ✕No | ✓Posture is committed, and drift fails the deploy |
| Admit a new module to the deployment | ✕No | ✓Admission is fixed at deploy time |
Two consequences worth carrying into a design review. An administrator cannot widen what the platform may do, only who may use what it already does. And our own automation cannot promote anything to production: continuous integration publishes to staging only, and the module API has no promote route at all. Administration and the module runtime.
The true half first: there is no published uptime or response-time commitment, and the monthly fee does not buy a rotation. What it buys is a deliberate release process and a direct line to the person who built the system. Changes arrive from a pinned tag, one deployment at a time and confirmed; drift and diff checks run before anything moves; the acceptance suite runs against your live deployment after it; the operations journal is dated per deployment. No queue, and no ticket system in front of it. Decide whether that shape suits your organization before you sign rather than afterwards. What managed operations covers.
Hosted sign-in with PKCE, tokens in httpOnly cookies, and passkeys, TOTP and second factors as self-service for your users. The user directory lives in your own account, under your control, like everything else in the deployment.
It has been done once and is scoped per engagement. We will not list single sign-on with your enterprise identity provider as a shipped feature, and there is no SAML. If this is a hard requirement, raise it at the assessment and we will scope it rather than nod.
A five-minute audience-pinned assertion and credentials lasting at most fifteen minutes, tagged to the named person using them, with the access record written before the credential is issued. If the record cannot be written, no credential is issued.
The platform is deployed into your account rather than hosted by us, so a parting is a change of operator rather than a migration. You keep the deployed platform and its source; infrastructure as code and runbooks are deliverables written for exactly this moment. Running it afterwards needs a competent cloud engineer, and it is deeply built on one cloud provider, so moving to a different one would be a rebuild rather than a migration. Both of those belong in your assessment of the risk.
Yes. The live demo is the running product: sign-in, governed chat, the administration area and a module in its own origin. For a technical evaluation it is more useful than any document, and you are welcome to bring your own questions and poke at it.
At Baseline no cross-account role exists at all. On the Standard and Strict tiers our management access is scoped and session-capped. Every change arrives through a release from a tagged build, and the operations journal is dated. You hold root and billing throughout.
The catalogue is produced by a script from the provider's live list and classified by where inference actually runs, then refreshed as providers change it. Adding a model to your allowlist is a deploy-time parameter, so it arrives as a release rather than as a surprise. If a model has no compliant route for your pinned region, the request is refused with a reason rather than rerouted. Model access.
There is an authoring kit, a manifest contract at schema 1.1, a command-line validator, a scaffold and server-side re-validation of the exact uploaded bytes. Continuous integration publishes to staging only; production promotion needs a named administrator approving the exact hash. The path is proven end to end by us acting as the client, and the first client-authored build is a pilot. Client modules in use today run on the staging channel.
No. Your people reach the deployment over the web by signing in, so there is no tunnel into your corporate network, and the managed model service processes each request rather than running inside it. The boundary states exactly what is and is not inside.
Come with the architecture questions. The assessment produces a topology and data-flow map for your own environment, and you keep it either way.