Teams and roles

Every account starts with a personal organisation. A team gets a shared one: organisation switcher → Create organisation, with a name and a short URL slug. Machines, skills, deliveries, jobs, alerts, channels and API keys belong to one organisation; creating another does not move existing machines, and a machine is paired into one organisation at a time. The dashboard shows one organisation at a time under /o/<slug>.

Four roles, each including the ones below it. Access applies to every machine and skill in the organisation; a machine's mode and its allow and deny lists still apply on top (see Machines and pairing). An API key acts as the role of its scope and never as owner.

• Admins and owners pair machines, add notification channels, create API keys and invite people. Admins manage viewers and members; only an owner changes an admin's or an owner's role, or makes someone owner.
• An organisation needs at least one owner: the last owner cannot step down or be removed until someone else is made owner.
• Anyone can leave an organisation themselves; admins and owners remove others.

Team → invite by email with a role (viewer, member or admin; owners are promoted afterwards). The invitation is emailed and its link is always shown too, so you can send it yourself when email is not enabled on the deployment. An invitation is valid seven days and must be accepted while signed in with the invited, verified email address; another address is refused. Resending issues a new link with a fresh seven days and the old link stops working; withdrawing deletes it. Open invitations count towards the plan's people limit until they are accepted or withdrawn (see Plans and limits). An organisation can send at most 20 invitation emails an hour; its admins still get the links.

Keys, members, invitations, roles, pairing machines and new notification channels are changed by a signed-in person on the dashboard only. A key can read the team (list_members; admin keys also see pending invitations) and never invite, change a role, remove anyone or create another key, so a leaked key can neither widen nor outlive its access, and revoking it ends everything it could do. See API keys and scopes.

Every mutation is audited: who (a person, an API key, a machine, or the system), what, and on what: commands sent, machines paired, renamed and disconnected, skills saved and deleted, hosted URLs turned on and off, settings, members, invitations, roles, keys created and revoked, channels, alerts dismissed, problem reports. Payloads, answers, SKILL.md contents and report text are never in it, only identifiers and flags. Admins read it under Audit log or with list_audit_log, filtered by an exact action or a prefix ending in a dot.