In these docs

Execution Layer for Odoo

The adversarial test suite.

The Execution Layer is proven by a 119-case adversarial failure suite that attacks it with the exact failures it is meant to catch, green on Odoo 19 Community and Enterprise. This is what it covers and how you run it on your own staging.

Feature-complete · Odoo 19 Updated 25 August 2026

We do not ask you to trust the Execution Layer. We ask you to attack it. The suite that is our own release gate ships with the product, so you can run it on your own staging and watch the layer refuse, roll back, and receipt correctly before you trust it in production.

The numbers

The suite is 119 adversarial test cases, run on both editions:

  • Enterprise: 119 passed, 0 failed.
  • Community: 117 passed, 0 failed, with 2 Enterprise-only cases (which reference Enterprise-only models such as Knowledge) skipped by design.

Both runs are reproducible in the repository:

Run the suite
# Community
ci/run.sh community all


# Enterprise
ODOO_ENTERPRISE_PATH=/path/to/enterprise ci/run.sh enterprise all

What the cases cover

The suite exercises the failures that a connector without these controls would miss:

  • Partial-write refusal: a write that would half-apply is refused, not partially committed.
  • Retry after timeout: the same idempotency key executes once, never twice.
  • Batch rollback: an item failing at position k rolls back the whole batch.
  • The wrong John: an ambiguous reference is caught and refused with candidates.
  • Truncation flags: a bounded read reports how much it left out.
  • Escalation attempts: calls against structurally blocked models are refused.
  • Audit tampering: edits and deletes of the audit through sudo(), raw SQL, and server actions are blocked or made evident.
  • Denial survives rollback: a refused action is still recorded when the business change rolls back.
  • OAuth abuse: PKCE downgrade, redirect tampering, and token replay are rejected.
  • Injection in record text: content that reads like an instruction is stored and returned as inert data.
  • Approval staleness: a payload changed after approval is refused.
  • Evidence mirroring: off-site mirror deliveries stay in chain order, and destinations under nanti.ai’s own domain are refused by the software.
  • Subscription honesty: the dashboard reports the real plan state, and nothing ever blocks on a lapsed or outgrown subscription.

The runner ships with the product

The packaged runner is built: python -m nanti_suite run … executes the suite against your own Odoo 19 staging database and writes an HTML, Markdown, and JSON report. It refuses to run against a database that does not look like staging, and any case it cannot run on your stack is reported as not run, with the reason, never as a pass. It is distributed with the product at launch.

Next: compatibility and versions.