A
Nothing counts seats.
No seat concept exists anywhere in the product. Usage is metered in tokens per person against the provider's own record of the call.
org.tech is the company. orgOS is the product, and the deployment is yours.
A governed AI environment, deployed {inside} an account you own.
orgOS is not a service you log into. It lands in your cloud account and stays there. The dashboard carries your name, the data at rest sits in your storage, and the controls are written as infrastructure rather than promised in a document.
What a deployment actually is.
ORGOS · WHAT LANDS IN THE ACCOUNT
A deployment is not a zip file handed over, and not a tenant on our servers. It is a tagged release of one codebase, layered with your parameters, built into your own account by our deployment factory. What arrives is a working environment with six parts, all under your account's identity and billing.
At every deployment
Built, first client use under way
Named tier required
01 Deployed
A dashboard with your name on it.
White-labelled at build time. Hosted sign-in, tokens in httpOnly cookies, a user directory in your account. Passkeys and second factors are self-service.
02 Deployed
Frontier chat, metered per person.
Streaming chat with model and region selectors, sessions, attachments and voice dictation, plus an optional knowledge base that cites its source document.
03 Deployed
A content policy nobody can switch off.
Attached to every inference call and enforced by cloud identity policy as a deny, never an application setting. Pinned to a numbered version. Tests fail the build if a deny is weakened.
04 Deployed
Administration your people run.
Users, roles with grants editable at runtime, an access matrix, per-person token quotas that fail closed, usage by person. Reading a transcript is itself audited.
05 Pilot
A runtime for business applications.
Modules framed inside the dashboard, each on its own origin, reaching resources only through short-lived credentials tagged to the person using them.
06 Deployed
One gateway to 104 models.
A generated catalogue of 104 models from 18 labs, each classified by where a request is actually processed. A pinned deployment refuses in words rather than rerouting.
104models
Catalogue · 18 labs
17
Control rows · mapped
2,700tests
Product suite · ~170 files
72releases
Tagged · in 52 days
One organization, one account.
TENANCY · ONE ORGANIZATION
Isolation is the account
There is no shared plane to get out of.
Multi-tenant products isolate you with code. orgOS isolates you with an account boundary that holds whether our code is correct or not.
- 01We do not resell compute. The provider invoices you at list price, so there is nothing to mark up.
- 02We hold no client data. Documents, sessions, the index and the usage record sit in your storage region.
- 03Our access is a posture decision. Scoped, session-capped on Standard and Strict. At Baseline no cross-account role exists at all.
org{•}tech / orgOS / tenancyOne organization · one account
Your people
StaffHosted sign-in
AdministratorsRoles and grants
Cloud account you own Billed to you directly
DashboardWhite-labelled
Policy gateDeny in cloud identity policy
Your data at restDocuments, sessions, index
Module runtimeOwn origin per module
Managed model service
Frontier modelsNo vendor access to content under default retention
Solid border is what you own. The red node is the control point every inference call passes. The model service is called out to, not run inside your network.
Tenancy·Simplified · full topology on the architecture page
You are not renting seats.
OWNERSHIP · NOT SEATS
B
The bill is yours to read.
Platform infrastructure has run roughly $5 to $10 a month at Baseline, about $110 on the private-network tiers, excluding inference.
C
Cancel the service, keep the platform.
The monthly fee buys the service, not access. Running it afterwards needs a competent cloud engineer, which is why runbooks are deliverables.
D
Changing model is configuration.
Composable means models. Switching between frontier models is a parameter change on the same governed route. Switching cloud provider would be a rebuild.
Most private AI means they hold your data privately. Ours means you do.The line the platform is built to earn
Useful on day one, then built to fit.
VALUE · TWO PHASES
- 01Out of the box
The governed environment
Everything in the grid above arrives configured: sign-in, chat, the knowledge base if you want it, quotas, administration and the audit record. Your policy is written into the deployment rather than circulated, and a page inside the product shows the resolved controls and the exceptions we have not yet closed. This is the phase that ends the shadow usage.
GateAre your people working in it, and can your security owner defend how?Decides: your executive sponsor - 02Per deliverable
Capabilities built into it
Then it becomes where your own operating capability gets built: modules carrying your way of doing things, with governed access to your records and, where it earns its place, inference. Each is scoped and priced as a deliverable. Most never call a model at all, because what organizations use day to day is governed business software.
GateDoes this earn a deliverable, and is a deterministic tool the better answer?Decides: you and org.tech, per deliverable
Both phases run on the same release train
Every deployment comes from a tagged release and a clean checkout. A capability built for phase two arrives the same way the platform did: a tag that exists in a repository, stamped into the running system so it can tell you itself what version it is. The factory.
Who operates what.
RESPONSIBILITY · US AND YOU
| Decision or duty | org.tech | You |
|---|---|---|
| The cloud account and its root credentials | ✕Never ours | ✓Yours, in your name |
| The compute invoice | ✕We never hold it | ✓Billed to you directly |
| Releases, deploys, drift and diff checks | ✓We run them | ✕Nothing to do |
| Users, groups, roles and grants | △On request | ✓Your administrators |
| Content policy, allowlist, tier, residency | ✓Changed by release | △You decide, we apply |
| Promoting a module to production | ✕Our automation cannot | ✓A named administrator |
| Evidence for your security review | ✓We produce it | ✓You own the programme |
"Changed by release" is the point: a deploy-time parameter cannot be altered by anyone signed into the running system, us included. See what administrators cannot do, or the full responsibility split.
Managed operations, concretely
Releases rolled one deployment at a time and confirmed, drift and diff checks, acceptance scripts that exercise your real deployment over HTTPS after a deploy, catalogue refreshes, cost watch with budget alarms, a dated operations journal, and a direct line to the person who built it, with no queue. $500 a month, cancel anytime.
Read it in any order.
PLATFORM · WHERE TO GO NEXT
- 01Architecture, layer by layerTopology, what policy denies, how the diagram is verified.→
- 02Model accessThe generated catalogue, retention posture, residency refusals.→
- 03Chat and the knowledge baseWhat staff get on day one, and the limits of retrieval.→
- 04AdministrationRoles, quotas, audited reads, and what nobody can change.→
- 05ModulesIsolated origins, credentials tagged to a named person.→
- 06Developer modulesAuthoring kit, validator, promotion path. In pilot.→
- 07Factory and fleetTagged releases, clean checkouts, fleet status.→
- 08The live demoOur own deployment of the same product.→
- 09Platform or gatewayIf the problem is your documents, the other product may be the right one.→
The questions we get.
QUESTIONS · PLATFORM
01Is this SaaS?
No. There is no shared service to sign into and no tenant of ours holding your data. What you subscribe to is managed operations, and cancelling it does not take the platform away.
02Who pays for the compute?
You do, directly to your cloud provider at list price. Light team usage has run an estimated $40 to $120 a month all in: what we have seen, not a quote. Compute costs breaks it down.
03What happens if we stop paying you?
You keep the platform, its source and its infrastructure-as-code. Runbooks and infrastructure-as-code are deliverables from the start, for exactly that reason. Ownership and exit sets out what running it yourself takes.
04Can we see it first?
Yes. The demo is our own deployment of the same product, not a mock. The assessment is $2,500 and you keep the deliverable whether or not you proceed.
05Which models can we run?
104 active models from 18 labs at the last catalogue generation, produced from the provider's live list rather than typed by us. Where a request is processed matters more than the count: see model access.
06Is it only chat?
Chat is the first capability, not the product. Day-to-day work happens in modules, and most never call a model. Inference is not always the answer.
The claim this page exists to make
You're not buying seats. You're buying a private AI platform on your own cloud, yours to keep.
If your AI vendor disappeared tomorrow, would anything still run? With us, you log into your own cloud and keep running.
- 01One organization, one account. Isolation is the account boundary, not our code.
- 02Policy applied, not circulated. A deny in cloud identity policy, on every call.
- 03The exceptions are shown to you. Inside the product, generated from the code.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
A bounded $2,500 engagement ending in a written deployment plan for your own account, yours to keep whether or not you proceed.