Users, bundles, and rules.

Everything on this page is admin territory: who may connect an AI at all, what each person’s AI may reach, which actions stop for a human, and which business rules the server enforces. All of it is configured in screens that read back as plain sentences, and all of it is enforced by access rules, not hidden menus: a plain user attempting any of it over RPC is refused.

Users & permissions: the manager’s cockpit

There are four access levels:

Level	Sees	Can change
No access	nothing; AI clients cannot connect as this user	nothing
Connect an AI client (default)	own connections, own evidence, own approvals	own connections and API keys
Auditor	the full action log and evidence of every user	nothing in configuration
Administrator	everything	all configuration, and any user’s bundle and access

Internal users get “Connect an AI client” by default, as a removable membership. Odoo system administrators cannot be blocked; to take AI away from such a person you would first remove their Odoo Settings access.

Since version 1.1 this screen also carries each user’s two messaging levels, one for Discuss and one for WhatsApp: Off, Confirm each message (the default), Approval in Odoo, or Unrestricted.

The off switch is immediate and reversible. Set a user to No access and their existing OAuth tokens and API keys stop authenticating on the very next call (HTTP 401), a new sign-in is refused before any authorization code is issued, and the Execution Layer disappears from their Odoo. Nothing is deleted: restore the level and the same client works again without re-consent. The change itself is recorded, and the refused calls appear in the action log.

Bundles: role presets in plain language

A bundle says, in one sentence, what a group of users’ AI clients may reach. Six ship ready: Odoo permissions · read only (the default), · read & write, · full, plus Sales, Finance, and Support.

The top of the form shows the generated sentence (“The Sales bundle can read Activity, Contact, Lead, Sales Order…; create/update…; Export is off.”). The Models tab is a per-model grid of Read / Create / Update / Delete / Actions with a per-field sub-list; the Tools tab holds per-tool overrides that can only switch a tool off, never widen access. A bundle never grants anything the user’s own Odoo permissions would refuse.

Allowed actions is the allow-list for execute_action. Odoo’s business buttons (confirm an order, post an invoice, mark done) are refused by default; each row here allows exactly one method on one model, the form suggests the model’s real methods and refuses one that does not exist, and everything not listed keeps failing closed with ACTION_NOT_ALLOWLISTED.

Rules: what stops, what must be set, what a person must approve

• Risk classes & approvers decide which calls stop for a human. Five ship enabled: deleting anything, mass updates of 10 or more records, validating invoices or bills, confirming orders, and sending outbound mail. You build new ones from friendly fields (tools, models, action methods, a minimum record count, the approver), and typos are refused at save. What happens next lives in approvals.
• Required fields: fields AI must set, stricter than Odoo’s own, enforced server-side. Example: “Tasks created by AI must always have an assignee.”
• Preconditions: your business rules, checked before anything is written; the AI cannot talk its way past them. Conditions range from “a field must be set or be one of these values” to a related-record check to an expert Python expression, and each rule reads back as a sentence while you build it.
• Alert rules turn an event (a refusal, a failed verification, an export, an evidence-chain break) into an Odoo activity, an email, or a signed webhook. A Send test alert button fires a clearly marked test through the real channel, so you can watch it arrive under Evidence → Alerts.
• The simulator dry-runs any action as any user: allowed, refused, or needs approval, plus the evidence row it would leave. Nothing executes and nothing is recorded. This is how you prove a rule does what you meant before trusting it.

Meaning: the registry your AI reads before it acts

The Registry (Meaning → Registry) is where you tell AI clients what your fields and business nouns mean. Three kinds: a field meaning (“commercial tier decided yearly by sales management; not the delivery priority”), a business noun → model mapping (“customer invoice” means account.move), and a field misuse trap (the field AI keeps misinterpreting). Entries carry aliases, allowed values, examples, sensitivity (confidential and PII fields are hidden from AI unless a bundle explicitly allows them), and origin: local entries always win over the Context Layer.

• Add meaning (guided) is a 3-step wizard that writes the same registry entries.
• Disambiguation rules name the fields that identify a record beyond doubt, per model (“an Employee is resolved only through work_email; a name alone never resolves it”). The server enforces them: the AI gets a structured AMBIGUOUS_TARGET refusal naming the fields to ask for, never a guess.

Next: approvals, where risk-classed actions wait for a person.