Organizations, roles and modules

Acest conținut nu este încă disponibil în limba selectată.

Three separate things decide what appears on your screen in kOS. They are worth untangling, because “I can’t see X” has a different fix in each case.

Your organization — the tenant whose data you are looking at.
Your role and permissions — what you may do inside it.
Your product’s modules — which parts of the product exist at all.

Organizations

An organization is a tenant: a law firm, a notary office, a clinic, a team. It owns the records, documents, knowledge bases and assistants you work with, and it is the boundary that kOS enforces. You see your organization’s data and no one else’s.

You join an organization by invitation. Membership carries exactly one role, and a person can be a member of several organizations — with a different role in each.

Only one organization is ever active at a time. If you belong to more than one, kOS asks you to choose on the Select organization screen when you sign in, and afterwards you switch from the sidebar. Nothing you do in one organization is visible from another.

Central administration of several organizations

Some arrangements have one organization that centrally administers others — a network administering member offices, for example. Where that applies, the administering side sees a Client organizations list and can create offices, invite their first administrator, and manage their settings on their behalf. From inside an office nothing looks different; the office’s own administrators still manage their own team.

There is exactly one level of this. An office cannot itself administer further offices, and there are no teams or departments inside an organization — the way to give someone narrower access is their role and permissions, not a sub-group.

Roles

A role is a named bundle of permissions. Two roles are available for an administrator to assign:

Role	What it can do
Organization Member	Use the assistants and the knowledge base; create and edit assistants and reusable prompts; view the organization’s Usage and Audit log.
Organization Admin	Everything a member can, plus invite and remove people, change their roles, edit per-person permissions, and manage API keys.

Med adds its own roles, granted through Med’s Invite doctor flow rather than the general one: Med Physician (patients, appointments, consents) and Med Clinic Admin (physician access plus clinic administration).

Three rules govern who can grant what, and each exists to prevent a specific accident:

You can only assign a role whose permissions you already hold in that organization. An administrator cannot promote someone past themselves.
You cannot change or remove your own membership. Another administrator has to do it.
The last administrator cannot be demoted or removed. Appoint a second one first, or the organization would be left with nobody who can administer it.

Per-person permissions

Roles are deliberately coarse. On top of a role, an administrator can switch individual capabilities on for one person, under Organization → People:

Use the assistants (chat) — on for everyone, and not removable.
Manage AI assistants — create and edit the assistants and their setup.
Manage the toolbox — decide which tools each assistant can use.
Manage the prompt library — add and edit reusable prompts.

These grants only ever add. Anything the person’s role already includes shows as on and locked, marked as included with their role, so there is no way to use this screen to quietly take access away.

Modules

A module is a whole area of the product — Documents, Knowledge, Team, and the domain areas each product brings: clients, matters and deadlines in Lex; patients, consents and the pathology library in Med; GPU inference and the API in razorBridge.

Two things gate a module, and the distinction matters when something is missing:

Whether your organization has it is set by KlusAI, as part of what you have subscribed to. There is no switch for this inside the Hub, for you or for your administrator — if your organization needs a module it does not have, that is a conversation with KlusAI, not a setting.

Whether you see it is your role and permissions. If a colleague can see a section and you cannot, that is the part an administrator can fix today.

What the assistant can reach

The same three layers apply to Klu. Its toolkit is scoped to your product, so a Lex assistant has legal tools and no clinical ones. Within that, it can only reach records you are allowed to see — asking the assistant is not a way around a permission you do not have. And an administrator can narrow it further per assistant through the toolbox.

Accountability

Where your product includes the Organization section, two read-only surfaces let an organization see itself:

Usage — your organization’s consumption.
Audit log — what happened in your tenant, with tabs for configuration changes, sign-in and security events, which sources the AI used, and deletions.

Both are visible to plain members as well as administrators, which is intentional: the record of what the AI did should not be something only the person who configured it can read.

Administering your organization — the how-to: inviting people, changing roles, language.
The Hub — where these sections live on screen.