How it works.

The Execution Layer has one job: make every AI action against Odoo provable. It does that by routing every tool call, a read or a write, through a single pipeline. There is no fast path, no bypass, and no “trusted” caller that skips a stage.

The pipeline, stage by stage

identity -> policy -> schema -> semantics -> preconditions -> approval
  -> idempotency -> atomic execution -> read-back -> audit -> response

1. Identity. The bearer token (an OAuth token or a scoped API key) resolves to a real Odoo user. There is no service account: the AI acts as that person, under Odoo’s own access rights and record rules.
2. Policy. The user’s access bundle, the connection’s chosen level, and the tool policy decide whether this tool is even visible, and whether this model and these fields are in scope, read versus write versus full.
3. Schema. A fail-closed sanitizer checks the arguments. Unknown, hidden, read-only, or out-of-scope fields refuse the whole call. Values are never silently dropped or coerced.
4. Semantics. Meaning is injected, human references are resolved, and ambiguity is refused (AMBIGUOUS_TARGET) rather than guessed.
5. Preconditions. Your declarative business rules are evaluated server-side, for example “a sales order needs a customer reference before it is confirmed”.
6. Approval. If the action is risk-classed, the call is refused with APPROVAL_REQUIRED and a payload-bound approval request is opened for a person to decide.
7. Idempotency. The write’s idempotency key is checked. The same key and payload replays the original receipt; the same key with a different payload returns IDEMPOTENCY_CONFLICT.
8. Atomic execution. The change runs inside one transaction: execute, flush, invalidate caches.
9. Read-back. Still inside the transaction, the record is read back and compared against the declared intent and any assertions. Then the layer commits, and reads the record once more after commit to confirm.
10. Audit. The evidence row is written on an independent database cursor, so it survives even a business rollback. In strict mode, a failed audit write fails the call (AUDIT_UNAVAILABLE).
11. Response. The Action Receipt for a write, or the structured result or refusal for a read or a denial. Every response carries both structured content and a text mirror.

The commit boundary

The order around the commit is what makes “verified” mean something:

execute -> flush -> in-transaction read-back and compare -> COMMIT -> post-commit confirmation read -> receipt

verified: true is only ever set when a fresh read after commit matches the intent. If something committed but did not match, because an onchange or a compute altered it, the layer does not silently accept it. It returns VERIFICATION_FAILED, records the evidence, and raises the default alert.

Why one pipeline matters

A connector that has a “quick” path for simple writes has a path with no verification and no audit. The Execution Layer refuses that trade. Because every call runs the same stages, the guarantees hold for the boring writes as much as the dangerous ones, and there is no configuration that turns them off for a caller you trust.

Next: installation.