org.tech / Resources / Glossary Glass box. Seven groups

If a word on this site is carrying weight, it is defined here, next to the page that has to live up to it.

Every term, defined the way we actually use it.

Most arguments about private AI are really arguments about vocabulary. Single-tenant, private, auditable, no lock-in: each of those means at least three things in this market, and the difference between them is the difference between a control and a sentence. So here is how we use every term, including the ones that cost us something to define honestly.

Book the strategic assessment → 01 Read the FAQ

Ownership and the boundary.

GLOSSARY · 01

Six words that decide whether you own an AI platform or rent one. Every other definition on this page depends on the first two being true.

Jump to a letter

A B C D F G I M O P R S T V W Y Z

The boundaryDefined term: The cloud account you own, in the storage region you chose, and everything sitting at rest inside it: documents, the knowledge index, chat sessions and messages, usage and metering records, module data. It is a line with declared traffic across it, not a sealed box. A request to the managed model service crosses it by design, so the exact statement is that data at rest stays in your account. The boundary.

Cloud account you ownOwnership: One deployment is one organization in one cloud account that the organization holds and is billed for directly by the provider. We do not resell compute and we hold no client data on our own infrastructure. Isolation between clients is the account itself, not a tenant column in a shared database. Architecture.

Single-tenantArchitecture: One deployment serves one organization: its own account, its own stores, its own identity directory, its own inference roles. The word is used loosely in this market to mean a separate schema or a separate namespace inside shared infrastructure. Here it means a separate account with its own bill. Platform overview.

White-labelledProduct: The dashboard is branded for the client at build time: their name, their marks, their domain. Our name does not appear in the interface their people use every day. Platform overview.

Glass boxPrinciple: The opposite of a black box, on three axes: an architecture you can inspect, a cost you read on your own bill, and a relationship you can end. The point is not comfort, it is accountability. You can see how it is set up, and that is exactly what lets you answer for it. Glass box.

Shared responsibilityAccountability: The written line between what we own and what you own. We own the platform contract, the control plane, the deployment standard and the controls we operate. You own data quality, priorities, grants, any logic your own people author, acceptance, and your own risk decisions. Either side can pause a deployment. Shared responsibility.

Models and inference.

GLOSSARY · 02

The vocabulary that decides where a request is processed, what happens to it there, and what it costs. Residency is two questions, not one, and the difference is the single most expensive misunderstanding in this section.

Managed model serviceModel plane: The cloud provider's own service that holds the model weights and runs the inference fleet. It sits inside your account's billing and identity perimeter, but it is not code we deploy into your account: your prompt is processed there, under the provider's terms. A managed model service does not run inside your network. Model access.

Frontier modelModels: A current top-generation model from a major lab, as opposed to an older generation that is still perfectly good at retrieval, summarising and classification. Which ones a deployment can serve is generated from the provider's live catalogue by a script, never typed into copy. Model access.

InferenceModels: One request to a model and the answer that comes back. Everything the platform governs is expressed as a condition on an inference call: which policy rides with it, which route it may take, which region may process it, and which person it is metered to. Model access.

TokenMetering: The unit a model reads and writes in, roughly a short word or a fragment of one. Quotas, metering and usage views are all counted in tokens. The product holds no currency at all, so a person sees tokens used against tokens allowed, and money appears on your cloud bill rather than in the product. Administration.

Inference routingModel plane: The provider mechanism that can serve one request from any of several regions with capacity. It is normally invisible and it is the reason a deployment that stores data in one country can have its inference processed in another unless the deployment is pinned. Naming this is the whole of our residency argument. Data residency.

Residency: storage and inferenceResidency: Two separate questions that are usually asked as one. Storage residency is where data sits at rest, chosen per deployment. Inference residency is where a request is processed, and it follows routing, not storage. A deployment can hold everything at rest in Canada and still have its inference processed elsewhere, which is why we ask both questions separately and write both answers down. Data residency.

Residency pinResidency · Strict: The control that constrains inference to endpoints inside one jurisdiction, available on the Strict posture. It is a real enforced allow plus a request-time refusal, and it has a real price. Of 104 active models in the generated catalogue, 13 run in-region in Canada and one more routes within Canada only, while 18 are reachable but processed outside and 72 are served from US and global regions. Every current frontier model routes outside Canada. Data residency.

Refused in wordsBehaviour: What a pinned deployment does when a model has no compliant route: it declines the request and says why. It is never quietly rerouted to a region that satisfies capacity instead of policy, and never silently downgraded to a weaker model that happens to be local. A refusal you can read is better than a success you cannot explain. Data residency.

Model allowlistModel plane: The set of models a deployment may call, checked when models are listed and again when one is invoked. It is a deploy-time parameter: an administrator inside the running product cannot widen it, and neither can a module. Model access.

Retention electionData terms: The account-level choice about whether the model provider may retain prompts. It is made at account scope rather than per request, and a deny in cloud identity policy refuses any workload that tries to widen it. Changing it is a decision with your name on it, not a side effect of enabling a model. Model access.

Zero-retention defaultData terms: The posture every deployment starts in: prompts are not used to train models and are not shared with model vendors, per the managed model service's terms. One vendor's newest frontier tier is available only with provider-side data sharing and retention of up to 30 days, so those models are shown as unavailable until the client makes that election explicitly. It is never a silent upgrade. Model access.

Composable AIPrinciple: Models are replaceable components. Switching the generation model is a configuration change behind the same application layer rather than a migration, which is what keeps you from being married to one lab's roadmap. The honest limit: this applies to models, not to clouds. The platform is deeply built on one provider, and moving it to another would be a rebuild. Composable AI.

Governance and policy.

GLOSSARY · 03

The words a security reviewer will test hardest. Each of these names a mechanism, not an intention, and where the mechanism has a limit the limit is part of the definition.

Content policy (guardrail)Control: The filter that rides on every inference call: denied topics, sensitive-information rules, and whatever else your policy calls for. It is mandatory on every call, enforced as a deny in cloud identity policy rather than as a setting in the application, so a second caller or a module backend cannot miss it. The rule set itself is configured per deployment and is empty by default, so what it blocks is a decision you make rather than a promise we inherit. Enforced in cloud policy.

Pinned policy versionControl: Your content policy is always a numbered version with its digest recorded, never a mutable draft. Changing it creates a new version, so an answer produced last quarter can still be traced to the exact policy that applied at the time. Enforced in cloud policy.

Cloud identity policy denyControl: A refusal evaluated by the cloud provider before a request reaches a service, using credentials the application cannot widen. Four of them hold every deployment: 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. Automated tests fail the build if a deny is weakened. Enforced in cloud policy.

Model invocation logEvidence: The record of each call: model, caller identity, latency and token counts, written in every region the deployment can infer in. It deliberately carries no prompt or answer text: what you get is request metadata and token evidence, and it is what metering settles against. Administration.

Per-person meteringMetering: Usage attributed to a named person and settled against the provider's own record of the call rather than an application counter. Counted in tokens. Two limits worth knowing: it covers the deployment's home region, and a failed settlement deliberately overstates rather than understates consumption. Administration.

Token quotaControl: A per-person ceiling that reserves before a call and settles after it. It fails closed: if the meter is unconfigured or unreachable, the request is refused rather than allowed through uncounted. A quota that fails open is a budget, not a control. Administration.

Posture tierConfiguration: The named set of controls a deployment runs, resolved from one typed object that drives the infrastructure, the plan page inside the product and the machine-readable export, so the three cannot disagree. Three tiers, additive, chosen deliberately during discovery. Any individual control can be overridden up or down with a written reason. Posture tiers.

Baseline, Standard, StrictConfiguration: Baseline is the low-cost entry posture: 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. Standard adds a private network endpoint to the model service, account-level audit logging, provider-managed keys, enforced MFA and scoped session-capped management access for us. Strict adds customer-managed keys with rotation and the residency pin. Baseline suits low-sensitivity use and a first evaluation; a security review will usually want Standard. Posture tiers.

Standing exceptionEvidence: Something a deployment does not do, or does differently from the standard, recorded with the reason it was accepted. Exceptions are not filed away: they appear on your plan page inside the product, so we show you, inside the product, what we have not yet closed. An override you asked for becomes one of these. Evidence pack.

The "your plan" pageProduct surface: A page inside the product where the signed-in client sees their own deployment's resolved controls and its standing exceptions. It is generated from the same typed object that builds the infrastructure, and a test fails the build if the page and the exceptions table disagree. It is the difference between a description of your controls and a rendering of them. Administration.

Controls matrixEvidence: The mapping from technical controls to external criteria: 17 technical control rows against SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A, each carrying an enforced, partial or not-enforced verdict. It is the one control narrative in this company tied directly to code, and the residual exceptions it produces are the ones rendered to you in the product. Compliance alignment.

AttestationCompliance: A report issued by an independent audit firm, such as a SOC 2 report. We hold none, and we say so on the page rather than in a footnote. The platform is designed to align with SOC 2 and ISO/IEC 27001 and provides technical controls that support your program; it does not replace your own organizational controls or your own audit engagement. Compliance alignment.

Modules and extension.

GLOSSARY · 04

How business applications get into a governed environment without quietly widening it. Most modules never call a model at all, which is the honest shape of what organizations use day to day.

Module orgOSExtension: A business application that runs inside the dashboard on its own isolated origin, declared by a manifest, reaching platform resources only through a recorded admission and short-lived brokered credentials. Kinds that exist today include secure file intake, a forecasting tool over an organization's own records, scheduling with public listings, and a roster tool with encrypted fields and an audited reveal path. Most of them call no model: inference is not always the answer. Modules.

Manifest orgOSContract: The declaration a module ships with, validated against a strict schema at version 1.1: identity, version, channel, isolated origins, what it asks of the platform, its tools and its provenance. Nothing about a module is implicit. If a host, a resource or a capability is not declared, the module does not get it. Modules.

Admission orgOSControl: What an add-on may reach, fixed when it is installed rather than when it runs. All of a module's identity policy is materialized from the admission at deploy time, so a request at run time can be narrowed by the broker but never widened. Administrators cannot admit a module from inside the running system: nothing in the running system can create a role. Modules.

Channel: staging, production orgOSRelease: Two separate records for the same module. A build pipeline can publish to staging only, by construction, and production is reached only by promotion. Client modules in use today run on the staging channel; the production promotion path is built and exercised on our own deployment. Developer modules.

Promotion orgOSRelease: The act of moving an exact staging build to the production channel. It is administrator-only on the application interface, the module interface has no promotion route at all, and our own automation cannot promote. That absence is the control. Developer modules.

Artifact hashRelease: The fingerprint of the exact bytes being approved. The hash a named administrator approves must equal the hash already on staging, and the same bytes are copied server side, so what was reviewed is what runs. Approving a build by name rather than by hash approves whatever was uploaded last. Developer modules.

Two-administrator approvalRelease: The rule that a promotion is approved by two distinct administrator identities. A deployment with only one administrator may self-approve with a written justification, stored verbatim and labelled as exactly that. We do not call that segregation of duties, because it is not. Developer modules.

Credential broker orgOSRuntime: The component that vends a module's credentials at run time, after a fixed sequence of fail-closed checks. It intersects what the module asks for with what its admission allows, and it sits on an identity-authorized endpoint with no browser access at all. Modules.

Short-lived credentialRuntime: The credential a module backend actually uses: at most 15 minutes, tagged with the module, channel, person and lease, and refused outright if a tag is missing, so a session is never unattributed. The assertion that gets a module to the broker lasts five minutes and is pinned to one audience. Modules.

Access recordEvidence: The row written for each grant of module access, per person per module per day, retained 400 days. It is written before the credential is issued, and if it cannot be written no credential is issued. An audit trail that can be skipped under load is not an audit trail. Modules.

Authoring kit orgOSDeveloper: The packages your own developers build a module with: the manifest contract, a browser and a server library, a command-line validator and a scaffold. The browser half deliberately has no model method at all, and the server half refuses to do anything before it has verified the caller. Developer modules.

ValidatorDeveloper: The command that checks a module before anyone else sees it: schema, paths, declared connect hosts, tool-to-resource binding, bundle shape. Failures name the file, the line and the fix. The server then re-runs the same rules against the exact uploaded bytes, because a check that runs on the author's laptop is a convenience rather than a control. Developer modules.

Scaffold orgOSDeveloper: One command that writes a working module: source, a manifest, a build pipeline, deploy scripts and instruction files for coding agents. Tests assert that the generated templates pass strict validation unedited, so the starting point is never the thing that fails. For the gateway sense of the word, see scaffold (gateway). Developer modules.

Deployment and operations.

GLOSSARY · 05

What "managed" actually names. These are the words behind the monthly fee, and they are deliberately mechanical: a release, a check, a record, a refusal.

Tagged releaseRelease: Every deployment comes from an annotated release tag on the mainline and a clean checkout. The factory refuses a tag that is not on the mainline and refuses a dirty working tree, and it stamps the version into health endpoints so the running system can be asked what it is. 72 tagged releases were cut in the 52 days between 28 July and 18 September 2026. Factory and fleet.

Pinned versionRelease: A deployment deliberately held at a specific release rather than moved with the others. Upgrades are decided one deployment at a time and confirmed before they run, which is slower than a fleet-wide push and is the point. Factory and fleet.

Deployment factoryOperations: The separate repository and scripts that deploy a tagged product release into a client account, with that client's parameter file layered over the product's. It resolves the tag, materializes it as a clean checkout, discovers the client's module stacks, deploys, emits the discovered architecture model and appends a record. It owns no product code of its own. Factory and fleet.

Fleet statusOperations: One view across separate client accounts: which deployment runs which version, how far behind the current release it is, declared divergences, pins and last deploy. It can probe each deployment's health endpoint live, and a deployment with nothing reachable must declare that in writing rather than carry a dead entry. Factory and fleet.

Drift checkOperations: The comparison between what the infrastructure code says and what is actually deployed, run before a change rather than after an incident, so a difference is found while it is still a decision rather than a surprise. Factory and fleet.

Acceptance scriptOperations: A check that exercises the real deployment over HTTPS after a deploy: a replayed ticket, a forged session, one module's session presented at another module's host, a corrupted upload. Each must be refused. It runs against the deployment that is actually serving, over the same protocol a user reaches it on. Managed operations.

Discovered architecture modelEvidence: A model of the deployment emitted from what was actually deployed, then reconciled against the drawn diagram. It means your architecture document is checked against the infrastructure rather than maintained alongside it and quietly diverging from it. Factory and fleet.

The gateway.

GLOSSARY · 06

The second product has its own vocabulary, and mixing the two is the easiest mistake to make here. The gateway runs no language model: it governs what the assistant your people already use can reach, and tool results travel to that assistant's vendor.

Different product, different claims

Model Context Protocol gatewayStandard: The open standard by which an AI assistant discovers and calls tools on a remote server. It is what lets the gateway serve your own documents and data to the assistant your people already use, with no new application to adopt and nothing per seat. It also makes changing assistant a reconnection rather than a migration. How it works.

Connector gatewaySurface: What the assistant sees: an authenticated server it can call tools on, added once per person in a couple of minutes and signed into with your own corporate identity, so there is no password to distribute. Behind it sit four things an ordinary connector lacks: a mirror inside your own account, server-side policy of your own, a layer of human-confirmed facts, and deterministic tools. The gateway.

One-way mirror gatewayData flow: Approved document libraries copied into a store in your own account, one library at a time, through a read-only grant you can revoke in one action. The folder tree is preserved exactly, only what changed is pulled, and deletions propagate. Nothing is ever written back into the source system. How it works.

Confirmed fact, candidate, gap gatewayEvidence: Three states for anything the gateway will state about a record. A confirmed fact was signed off by a named person and is attributed to them. A candidate is a proposal, explicitly not authoritative. A gap is something missing, reported as missing rather than filled in. Outward-facing generation accepts confirmed facts only, and that is enforced in code. Numbers you can defend.

Deterministic tool gatewayAnalysis: A tool that computes rather than predicts: integrity checks first, canonical tables built from your raw exports, then answers produced in SQL over every row, each carrying how it was computed and how to reproduce it. Retrieval returns passages that resemble a question, and a total needs every row, so the index is never used to calculate. Numbers you can defend.

Tool gate gatewayControl: The check inside every tool call, on the server, before anything runs. The filtered menu the assistant sees is usability only and fails open by design; the gate inside the tool is the boundary. A person the policy does not recognize gets nothing, because there is no default role. Access and data boundary.

Scope: narrow, never widen gatewayControl: A caller's arguments can only reduce what they are already permitted to see. Policy resolves as personal override, then role union, then deny. No instruction sitting inside a retrieved document can grant a tool the caller does not already hold, because the grant is decided before retrieval runs. Access and data boundary.

Scaffold gatewayGeneration: Not a written document. A structure whose slots are filled from confirmed facts with citations, or flagged as gaps for a person to close. The assistant writes the prose; the server decides what is allowed into it. For the orgOS sense of the word, see scaffold. Numbers you can defend.

Capability pack gatewayExtension: A set of tools encoding one organization's own process on top of the general kernel: readiness checks, stage tracking with entry criteria, ask lists, standard workbooks. A pack adds no second source of truth. It reuses the confirmed layer for human judgments and the analysis engine for every figure. How it works.

Commercial terms.

GLOSSARY · 07

What each thing on the ladder is, in the words we use in an engagement document. Prices are the published ones and nothing else; anything scoped per deliverable is scoped in writing.

Strategic assessmentEngagement: $2,500. The bounded first engagement and the only thing we ask you to buy in order to start. It ends in a written assessment you keep whether or not you proceed, including an environment and data-flow map, a recommended posture with reasons, and a go or no-go recommendation that is genuinely allowed to be no. Strategic assessment.

Managed operationsEngagement: $500 a month, cancel anytime. Releases cut and rolled deliberately from pinned tags, drift and difference checks before changes, acceptance scripts against the real deployment, catalogue refreshes, access and role changes, cost watch with budget alarms, a dated operations journal, and a direct line to the person who built it, with no queue in front of it. You lose us, not the platform. Managed operations.

The solutions pipelineEngagement: Our name for the sequence of scoped capability work that follows a deployment, one deliverable at a time rather than one programme at a time. It is why a first engagement starts at $2,500 and typically lands around $5,000 once the work is actually scoped. Deployment.

Forward-deployed engineeringEngagement: An engineer working inside your context rather than at a distance from it: your processes, your data, your definition of done, building capability that stays yours. Scoped per deliverable. Longer engagements are priced in the range of one junior technical hire, without the permanent headcount. Forward-deployed engineering.

Operating capabilityPositioning: What we sell, in preference to "an AI tool". The governed ability to turn your own knowledge and processes into new capabilities repeatedly, rather than access to one model this quarter. A tool is something you buy; a capability is something you keep. Our approach.

VelocityPositioning: The measure we use instead of speed: how quickly your organization can decide, act and adapt with the same people. More AI activity is not the goal, and the measure that matters is the one you set against your own baseline. Our approach.

Client-defined outcomesPositioning: The outcomes are yours to name, with a baseline taken before the work starts and measured against afterwards. We do not arrive holding a percentage, and an outcome only counts when it is measured against a baseline you accepted. Our approach.

⎯⎯ Book the strategic assessment ⎯⎯

Your private AI, inside your control ·

Bring the three or four terms that matter most to your own review. The assessment is where they become parameters in a written posture.

Book the strategic assessment →See the engagement path →