Overview
Ask an Odoo copilot which customers have overdue balances and it may return a polished table within seconds. The answer can still be wrong if it includes draft invoices, mixes currencies or treats an invoice date as a payment deadline.
These mistakes do not always come from missing records. They can come from missing meaning. A field contains a value, but the AI system lacks the context needed to interpret it correctly.
An Odoo semantic data audit checks whether business definitions, relationships and restrictions are clear enough for a specific AI workflow. It complements conventional data cleaning by asking whether an authorized assistant can select the right evidence and explain its limits.
Use this checklist before deploying copilots, retrieval-augmented generation or agents. Start with one business question and expand after its meaning and results have been verified.
Why data meaning belongs in the AI readiness decision
Oracle’s September 2026 Analytics update describes dataset and column descriptions as semantic metadata that helps AI agents understand business meaning. Its examples include similar forecasts, fiscal calendars and units of measure. Authors can review and refine generated descriptions rather than accepting them unchanged. Oracle Analytics September 2026 update.
The practical lesson for Odoo teams is that column names alone are insufficient. A label such as “Value” does not explain whether a number represents a quotation, confirmed order, invoice or payment.
This is an architectural lesson rather than a claim that Oracle’s capability exists unchanged in Odoo. Your implementation must determine where definitions are stored and how the assistant receives them.
Odoo documents agents through topics, tools and sources. Those provide places to guide behavior and supply information, but they do not remove the need to validate business definitions. Odoo AI agents documentation.
Distinguish clean data from interpretable data
Conventional checks detect empty fields, invalid formats and duplicate records. Semantic checks determine what populated values mean and whether they answer the intended question.
| Audit dimension | Example failure | Required evidence |
|---|---|---|
| Completeness | Product has no purchasing unit | Required field and exception report |
| Meaning | “Sales” could mean orders or invoices | Approved measure definition |
| Relationship | Joining order lines repeats order totals | Documented record grain and joins |
| Context | Stock belongs to another warehouse | Explicit company and location scope |
| Authorization | Retrieval includes restricted records | Permission tests using real roles |
| Freshness | Yesterday’s stock is presented as current | Source timestamp and freshness limit |
A complete dataset can fail several of these checks.
AI readiness should therefore be approved per use case. A product-documentation assistant and an agent that changes purchase orders need different data, controls and acceptance tests.
Start with the question and decision
Write the intended question in business language, then identify the decision it supports. “Which products need attention?” is too broad. “Which purchased products in Warehouse A have projected shortages before their next confirmed receipt?” defines a more useful starting point.
Specify the user role, company, period and expected output. Identify whether the system may explain information, draft a recommendation or execute a change. List the situations in which it must ask for clarification or stop.
Collect representative questions from actual users. Include ordinary wording, abbreviations and ambiguous requests. The audit should prepare the system for those questions instead of only the wording used in a demonstration.
The Semantic Data Audit Checklist
1. Define fields beyond their display labels
Record each important model and technical field alongside its business name. Explain what it measures, when it changes and which process owns it. Include exclusions and an example that distinguishes it from similar fields.
For instance, “confirmed order value before tax, excluding cancelled orders” provides more direction than “sales amount.” Check that the definition matches deployed configuration and custom code rather than assuming the screen label is authoritative.
Document the dataset as well as its columns. State its purpose, included companies, date coverage and refresh method. A correctly described field can still be misused within the wrong dataset.
2. Resolve duplicate terminology and competing definitions
List terms such as customer, account, partner, member and contact. Determine where they are true synonyms and where they represent different relationships. Map approved alternatives to a canonical definition without merging distinct concepts.
Review terms that vary across departments. Sales may use “revenue” for booked orders while finance uses it for recognized income. The assistant should select the approved definition for the task or ask which measure the user intends.
3. State the record grain and permitted joins
Describe what one row represents: an order, an order line, a payment or a stock movement. Record the identifiers used to connect related records and whether each relationship can have multiple matches.
Test whether joins multiply values. An order with five lines must not contribute its full header total five times. Similarly, several deliveries against one order do not necessarily represent several separate customer purchases.
Provide an approved aggregation rule for each measure. Distinct counts, sums and ratios require different handling. Validate results against a trusted report before exposing the dataset to an assistant.
4. Make units and quantities explicit
Audit purchasing, inventory and sales units together. Specify whether a quantity means pieces, packs, kilograms, hours or another measure. Preserve the product-specific conversion where packaging or operational definitions require it.
Review rounding and conversion rules. A supplier pack of twelve units is different from one stock unit, even when both are described informally as “one.” Prevent the assistant from adding quantities that have incompatible dimensions.
Explain whether quantities represent physical stock, reserved stock, demand or projected availability. The same number can support very different decisions depending on that definition.
5. Define currency and valuation context
Every monetary measure needs an identified currency and basis. State whether it uses transaction currency, company currency or a reporting currency. Document conversion dates, exchange-rate sources, rounding and whether tax is included.
Do not let the system combine amounts across currencies simply because they share an “amount” label. Separate current balances from historical valuations and explain the sign treatment for refunds or credit notes.
For management measures such as margin, name the cost basis and calculation owner. An assistant cannot safely resolve competing financial definitions by choosing the most familiar formula.
6. Preserve company, location and time context
Record the legal entity, warehouse, branch and relevant date for each answer. Shared products or contacts do not imply shared inventory, account settings or unrestricted access.
Odoo’s multi-company guidance explains that company-dependent fields can return different values according to the current company. This makes the execution context part of the meaning of the retrieved value. Odoo multi-company documentation.
Distinguish order date, posting date, due date and delivery date. Define fiscal periods and timezones for reporting boundaries. Test a transaction near midnight or period end so the assistant’s interpretation matches the operational report.
7. Inspect custom models and computed fields
Inventory custom models, Studio fields, integrations and legacy imports used by the AI workflow. Assign an owner to each definition and identify obsolete fields that should be excluded.
For computed fields, document dependencies and when the value is evaluated. Odoo supports computed fields that are not stored by default, so a database extract is not necessarily equivalent to application-level retrieval. Odoo ORM documentation.
Check inherited customizations and external mappings. A field originally called “priority” may now control something more specific. Generated descriptions must be checked against implementation and business practice before publication.
8. Audit permissions across the whole retrieval path
Identify the user or service account that reads Odoo and the people who can consume its results. Odoo access rights, record rules and field restrictions must be reflected in the integration design. Odoo security documentation.
An exported document or vector index does not automatically retain the source system’s permission behavior. Test authorization before restricted content reaches the model, including citations, cached answers and conversation history.
Verify what happens after access is revoked or a record becomes restricted. Metadata describing sensitive fields can also reveal information, so review the glossary and tool descriptions for appropriate exposure.
9. Separate missing values from valid business states
Audit incomplete customer, supplier and product records against the selected use case. Define mandatory identifiers, units, categories and relationships. Give missing values an explicit treatment rather than filling them with convenient defaults.
Zero, unknown and not applicable are different states. No payment term does not necessarily mean immediate payment and missing delivery information does not prove that an order is late.
Route uncertain records into an owned exception queue. If missing data changes the recommendation, the assistant should disclose the limitation or pause rather than invent a plausible value.
10. Check freshness, lineage and approval status
Record where information originated, when it was updated and which version is approved. For document retrieval, retain the policy owner, effective date and superseded status. For operational figures, define an acceptable delay.
Test whether archived records, draft documents or outdated exports remain searchable. A semantically clear answer can still be wrong when it uses an old source.
Treat source text as evidence rather than authority to change system instructions. Business definitions should come from reviewed metadata, while externally supplied content remains subject to normal trust and validation controls.
Reuse this field-definition template
Maintain this record for each critical field or measure. Store it in a controlled catalog that the integration can access, then verify that the relevant definition actually reaches the tool or retrieval context.
| Template item | What to document |
|---|---|
| Identity | Dataset, model, technical field and business label |
| Meaning | Definition, synonyms, exclusions and sample interpretation |
| Structure | Record grain, key, relationships and aggregation rule |
| Measurement | Unit, currency, conversion rule and precision |
| Context | Company, location, period and applicable timezone |
| Quality | Required values, missing-value behavior and known limitations |
| Security | Authorized roles, sensitive fields and export restrictions |
| Lifecycle | Source, refresh limit, owner, approval date and version |
Example: from an ambiguous question to a controlled answer
Consider an illustrative distributor asking, “Which customers owe us the most overdue?” The company operates two legal entities and accepts payments in several currencies. This example describes a proposed design rather than a client result.
Without audited meaning, an assistant might rank invoice totals across both companies, include draft documents and ignore partial payments. Its explanation can sound confident because the retrieved numbers are real even though the selection and calculation are wrong.
A controlled workflow moves through six stages:
Establish scope. Authenticate the user and confirm the permitted company, reporting currency and as-of date.
Resolve meaning. Load the approved overdue definition, including eligible document states, due dates, open amounts and treatment of credits.
Retrieve evidence. Call a bounded Odoo query or approved reporting service. Retrieve identifiers and supporting values using the correct access and company context.
Calculate consistently. Apply the approved balance logic and currency rules in deterministic application or reporting logic. A historical as-of request needs a suitable historical calculation rather than today’s residual values.
Explain the result. Return the ranking with its scope, timestamp, source references and exceptions. State unresolved limitations explicitly.
Control follow-up. If the user requests reminders or order holds, pass the proposal into a separately authorized workflow. Recheck current records and required approvals before any change.
RAG can retrieve the collection policy and explain terminology. Live balances require an appropriately current structured source. Combining these sources works only when their purposes and authority are clear.
Decide whether the pilot can proceed
Use explicit readiness gates rather than one average score. Strong completeness should not compensate for a failed permission test or an undefined currency conversion.
| Gate | Evidence required | Outcome if missing |
|---|---|---|
| Meaning approved | Owners agree on fields, measures and exclusions | Clarify definitions before evaluation |
| Calculations verified | Answers reconcile with an approved reference | Restrict output until discrepancies are resolved |
| Access proven | Unauthorized users cannot retrieve protected content | Block release |
| Freshness controlled | Delays and stale-source behavior are tested | Limit claims or pause affected answers |
| Action boundaries tested | Proposed changes follow permissions and approvals | Keep the pilot read-only |
Create a test set covering normal requests, ambiguous terminology, missing data, mixed currencies and unauthorized access. Measure answer correctness, appropriate clarification, source traceability and unauthorized disclosure separately.
Retest when metadata, custom modules, access rules or retrieval logic change. A one-time audit cannot establish permanent readiness for an evolving ERP.
For implementation planning, BrowseInfo’s Odoo AI implementation services can provide a starting point for discussing the selected workflow. Request a scoped semantic audit, an approved definition catalog and an evaluation plan as concrete deliverables.
Frequently Asked Questions
1. What is a semantic data audit in Odoo?
It checks whether fields, relationships and measures have clear business meanings for a specific AI use case. It also examines context, freshness and permissions so that an assistant uses appropriate evidence.
2. How is it different from data cleaning?
Data cleaning addresses problems such as duplicates, missing values and inconsistent formats. A semantic audit examines interpretation. A correctly formatted amount is still ambiguous when its currency or business purpose is unknown.
3. Will a better AI model solve unclear metadata?
A stronger model may handle language better, but it cannot reliably determine undocumented company rules. Resolve ambiguous definitions and test the complete workflow rather than expecting model selection to supply missing business context.
4. Do Odoo field labels provide enough context?
Usually they need additional explanation for consequential decisions. Include calculation rules, exclusions, units, scope and relationships. Verify that the actual AI integration receives those definitions rather than only the visible label.
5. Should all Odoo records go into a vector database?
No. Select sources according to the question, permissions and freshness requirements. Document retrieval may suit policies and reference material, while current balances or availability often need structured queries and deterministic calculations.
6. Can AI generate the descriptions used in the audit?
It can draft descriptions for review. Business owners should verify the meaning against configuration, code and operating rules. An automatically generated definition can repeat the same misunderstanding the audit is meant to detect.
7. Does every dataset need auditing before a pilot?
Start with the datasets and dependencies required for the selected workflow. Keep other sources outside scope. Expand only after their definitions, permissions and expected outputs meet the same review criteria.
Conclusion
Odoo AI data readiness depends on knowing what information means, when it is valid and who may use it. Clean records are necessary, but clear definitions and tested context make those records usable for dependable AI.
Select one decision, approve its metadata and verify the complete path from user question to retrieved evidence and final answer. Let the assistant ask for clarification when meaning is uncertain and expand only after the pilot demonstrates reliable results.
