01 Deployed
Users and groups.
Create and manage users, manage group membership, remove access. Changes take effect in the running system, and roles resolve fail-closed: an unreadable role store grants nothing at all.
The useful question about an administration area is not what it can do. It is what it cannot.
Your administrators run it. Some things they cannot change.
Everything about the people using your deployment is yours to change, immediately, without us. Everything that defines what the deployment is stays a deploy-time parameter, changed only through a release. That line is drawn on purpose, and this page is where we defend it.
Users, roles, grants.
PEOPLE · RUNTIME CONTROL
Administration is a real area of the product that your own people operate. It is not a ticket queue with us at the other end, and nothing here waits on a release. The directory lives in your account, so the list of who can reach the environment is yours to read and yours to revoke.
02 Deployed
Roles with editable grants.
A role is an identity group. What that role grants is stored in your account and edited by your administrators at runtime, with no redeploy and no call to us.
03 Deployed
One matrix for the whole question.
The access matrix shows which role reaches which capability in one view, so "who can do this" is a screen you open rather than an exercise somebody has to run.
Spending that cannot run away.
QUOTAS · RESERVE THEN SETTLE
Fails closed, by design
Each person carries a token quota. A call reserves against it before inference happens and settles afterwards from the provider's own record of the call, rather than from a counter kept by the application that made it.
- 01An unconfigured meter refuses. If metering cannot be resolved, the call is denied. The failure mode is a stopped request, never an unmetered one.
- 02Usage by person, in tokens. Administrators read consumption per subject; each person reads their own. There is no currency anywhere in the product, deliberately.
- 03Metering covers the home region. Cross-region invocations are logged and not metered, and under global routing that is the normal case, so usage under-counts. A failed settlement deliberately overstates rather than understates, because the failure mode that protects you is the expensive one.
org{•}tech / metering / reserve-settlePer person · tokens only
Your account One lease per call
RequestSigned-in person
ReserveAtomic, fails closed
Governed callPolicy attached
Invocation logNo prompt text
SettleFrom the provider's record
Usage by personQuota gauge, tokens by day
The reservation is written before the model is called, so a quota cannot be overspent by a call that is already in flight. Settlement reads the provider's own record rather than trusting the caller.
Metering loop·Home region today
Every strong action leaves a row.
AUDIT · THE POWER AND ITS TRACE
- 01Reading a transcript is itself audited. An administrator can read any user's chat transcript. The read writes an audit row as it happens, so the power exists and so does the record of using it.
- 02Revealing a restricted field is recorded. Where a module holds field-level encrypted columns, the reveal path is audited rather than silent.
- 03Pausing a module channel is real. Disabling a channel stops it in the running system. It is an operational control, not a cosmetic flag on a list.
- 04Promotion records its approvers and their words. A production promotion is approved against an exact artifact hash, names the approving administrators and stores the justification verbatim, whether it promotes or refuses. Who signs what.
Where the audit trail stops
Those are application audits and they exist at every tier. Account-level audit logging underneath them, multi-region with file validation and one-year retention, is a Standard and Strict control. At Baseline there is no account trail beneath the application's own records, and a security review will usually want one. Posture tiers.
What an administrator cannot do.
THE UNUSUAL PART
| Decision | Who makes it | How it changes |
|---|---|---|
| Which models appear in chat | You decide, we apply | A release |
| The content policy | You decide, we apply | A new pinned version, by release |
| Posture tier and residency | You decide, we apply | A release |
| Admitting a module and its ceiling | You decide, we apply | A release, from your parameter file |
| Users, roles, grants, quotas | Your administrators | ✓Immediately, at runtime |
| Enabling or pausing a module channel | Your administrators | ✓Immediately, at runtime |
| Promoting a module build to production | A named administrator, by hash | △Recorded, with approvers |
| Creating a role from inside the running system | Nobody | ✕Not possible |
This is tighter than most buyers expect, and it is the point. A control an administrator can switch off is a control you cannot present to a reviewer. It also means an administrator account in the wrong hands cannot widen your model allowlist, detach your content policy, change your tier or admit a module. It could read transcripts, and that read is audited.
Nothing in the running system can create a role.The rule administration is built around
The page that shows what we have not closed.
YOUR PLAN · INSIDE THE PRODUCT
Signed in to your own deployment, your administrators can open a page listing the deployment's resolved controls and its standing exceptions. It is generated from the same typed posture object that builds the infrastructure, and a test fails the build if the page and the exceptions table disagree. The description of your controls is generated from the code that builds them.
Behind it sits a compliance controls matrix: 17 technical control rows mapped to SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A, each carrying an enforced, partial or not-enforced verdict. Designed to align with SOC 2 and ISO/IEC 27001: we provide the technical controls that support your program, and hold no third-party attestation.
The controls matrix, verdict by verdict.
What each control maps to, and where the honest answer is "partial". The only control narrative in this business that is tied to code.
org.tech · Compliance→
What your security review actually receives.
The documents, the exceptions and the architecture reconciliation, assembled before the questionnaire lands rather than after.
org.tech · Evidence→
Factors people manage themselves.
SIGN-IN · SELF-SERVICE AND ITS LIMIT
Sign-in is a hosted page using the authorization code flow with PKCE, with tokens held in httpOnly cookies. Each person manages their own passkeys, time-based one-time codes and second factors without raising a ticket. Enforced multi-factor sign-in is a Standard and Strict control, and an optional add at Baseline.
Identity federation
Attaching orgOS to an identity provider your organization already runs is scoped per engagement rather than a switch in the product, and there is no SAML. Raise it in the assessment and we will scope it as work rather than tick it as a feature.
01Do we need an administrator on staff?
At least one, and ideally two, because approving a production promotion is an administrator act recorded against an exact artifact hash. Everything else here, users, roles, grants, quotas and module channels, one administrator can run. The promotion path sets out who signs what.
02Can you change our configuration without telling us?
Deploy-time parameters change through a release, rolled one deployment at a time and confirmed with you. The plan page inside the product always shows the resolved controls, so a change you did not expect is visible to you rather than buried in our notes. Our management access is a tier decision and does not exist at all at Baseline.
03What if an administrator account is compromised?
They still cannot widen the model allowlist, detach the content policy, change tier or residency, or admit a module, because none of those lives in the running system. They could read transcripts and change grants, and both leave records. Enforced multi-factor sign-in is the control that reduces the likelihood, and it is a Standard and Strict feature.
04How fast can we remove someone?
Immediately, by your own administrators, in your own directory. Role resolution fails closed, so a person outside every role reaches nothing rather than defaulting into something.
05Can administrators add a module themselves?
They can enable, pause and promote what has already been admitted. Admission itself, which defines what a module may ever reach, is written into your parameter file and materialized at deploy time. See modules and developer modules.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
Bring the person who will administer it. The assessment ends with the role model, the quota policy and the tier written down.