Context Layer for Odoo
Security and boundaries.
What the context layer is authoritative for and what it is not. Odoo keeps every permission and execution decision; OCL supplies interpretation and advisory safety context. How company, currency, and access boundaries are handled, and how tenant data is treated.
The context layer is interpretation infrastructure. It is not a connector, not an authorization layer, and not an execution authority. Getting that boundary right is a security property, not a detail.
Odoo stays the authority
Odoo’s access control lists, record rules, ORM constraints, and business methods remain authoritative for what a user may see or do and how an operation executes. The context layer never bypasses, weakens, or replaces any of them. It supplies meaning and safety context on top of a system that still enforces its own rules.
Write-intent validation is advisory
validate_write_intent can warn that an intended action looks risky and point at the safe
method. It never returns or implies authorization, and it never makes an AI-generated write
automatically safe. Whether the action is permitted, and whether it runs, is Odoo’s decision.
Boundaries change the answer
Several boundaries change what a correct answer even is, and the layer carries them explicitly so an AI does not mistake “what I can see” for “what is true”:
- Company: records visible under the active companies are not proof of globally complete records. Multi-company scope changes counts and totals.
- Currency: amounts are only comparable once currency is resolved.
- Access: a user’s record rules can hide rows; an aggregate over visible rows can silently answer a narrower question.
These travel as security notes and gotchas so the warning reaches the model rather than living only in a developer’s head.
Tenant data
The tenant system is built to be careful with a customer’s database:
- Metadata-first: it works from structural metadata, with no raw business records collected by default. Bounded, privacy-safe aggregates can be enabled where useful.
- Reviewed overlays: detected customizations are proposed, then approved, corrected, or ignored by the tenant. Nothing is assumed.
- Governed memory: confirmed facts are kept with provenance and scope, and are revocable.
- Export and deletion audit, and tenant isolation, are implemented and tested.
Foundation, not a hosted product yet
These are implemented local-alpha foundations. The hosted customer product, the review UI, and production security controls are still being built. See Current limitations. For the Odoo-side data handling of our shipping products, see the security hub.
Scope of released claims
Released entries are scoped to stock Odoo 19. Custom modules, localizations, tenant policy, access rules, company, and currency can all change the correct answer for a specific database. The layer states the scope it was proven against; it does not claim to have proven your customizations, which is what the tenant overlay is for.