Execution Layer for Odoo

Evidence: receipts and history.

The evidence screens of the Execution Layer: the immutable action log, the Why panel on every refusal, field-level before and after on every write, per-record history, stored Action Receipts, export trails, and alert delivery proof.

Available now · Odoo 19 Updated 22 September 2026

Evidence is the pillar the whole product exists for: not “the AI said it worked” but “here is what actually happened, provable later”. This page walks the five evidence screens.

Actions: the complete log

The actions log: every AI call with when, user, tool, model, records, status, error code, context column, outcome summary, duration, auth kind, and client reference, with filters for Today, Refused, Failed, Writes, and Context-enriched. — Every AI call, successful, refused, or failed. Rows are immutable, and the filters answer the everyday questions in one click.

Every AI call lands here: when, who, tool, model, records touched, status, error code, a Context column, the outcome summary, duration, auth kind, and the client reference. Filter by Today, Refused, Failed, Writes, or Context-enriched. Rows are immutable.

A refusal opens to a “Why”

A refused create_record call with the Why panel: the plain-language reason that the field does not exist on res.partner, the suggestion to use describe_model, and the structured FIELD_UNKNOWN error code. — The same explanation the AI client received, in plain language, with a pointer to the screen where you would change the rule.

Opening a refused row shows a prominent Why panel: the plain-language reason, the structured code the client received (one of the 42 error codes), and a “change it here” pointer to the exact configuration screen. A refusal is never a mystery, for the AI or for you.

A write opens to before → after

A successful update_records action detail: who and when, the model and records touched, the stage reached, the receipt reference, and the evidence-integrity block with verification status, chain sequence, and row hash. — Who, when, what, and the integrity block: verification status, chain sequence, row hash.

A write’s detail carries the field-level before and after snapshot, the records touched, the context enrichment used, and the evidence-integrity block: verification status, the position in the hash chain, the row hash.

Record history: everything AI ever did to one record

The record history screen: every AI write to a record, with who, when, the operation, the field, the before value, and the after value, each row linked to its audit log entry. — "Show everything AI ever did to this customer" is one search, not an afternoon of grepping logs.

Search a model and a record, and see every AI touch in order: who, when, the operation, the field, before, after, each row linked to its audit entry. AI clients can read the same history through the get_record_history tool, and that read is itself audited.

Receipts: the stored proof of every verified write

The receipts list: stored Action Receipts with their Executed, Persisted, Verified, and Audited checkmarks, verification status, and audit log link. — One row per verified write. Four green checks or an honest failure, never a silent one.

A single Action Receipt: the Executed, Persisted, Verified, Recorded chain, the user, tool, and model, the verification result, the audit log link, and the exact receipt JSON as returned to the AI client. — The receipt in full: the four-state chain, and the exact JSON the AI client got back. What the AI was told and what you can prove are the same document.

Every verified write stores its Action Receipt: Executed, Persisted, Verified, Recorded, with the verification result and the exact JSON returned to the AI client. If a write commits but cannot be verified, the receipt honestly reports verified: false with the reason, and an alert can fire; you are told loudly rather than lied to. The mechanics live in verified execution.

Messages

Since version 1.1, Evidence → Messages is the log of every message the AI sent: destination, kind, recipients reached, a preview, the human gate it passed (confirmed, approved, or unrestricted), and the linked audit entry. The whole messaging story, screens included, lives in messaging: Discuss to WhatsApp.

Exports and alerts

Exports. Every time AI exported data out of Odoo: who, what, how many rows. Data leaving the system gets its own trail.
Alerts. Every alert an alert rule fired, with its delivery state: sent, pending, or failed with the error. This is proof that notifications actually went out, not just that a rule exists.

How the chain resists tampering

The evidence chain is hash-chained and protected at the database level by a trigger, not just the ORM. The only deletion path is the retention cron, which purges a contiguous prefix and records an anchor, so the retained chain stays verifiable. Tamper-evident, honestly stated: a database administrator with raw SQL access is outside any module’s control.