Kinds of knowledge.

Raw Odoo schema tells an AI what fields exist. It does not tell it what a record means, which records count, how tables should be joined, which tempting fields lie, or when an action is dangerous. Each of those is a different kind of knowledge, and each has its own entry type. All share the one entry envelope; what differs is the shape of the claim.

The examples below are drawn from the public format examples. They are format demonstrations, not released registry facts.

Noun mapping

Maps a business noun to the exact model and record population that means it.

A customer invoice is an account.move whose move_type = out_invoice. A vendor bill is an account.move whose move_type = in_invoice.

The same account.move table is a customer invoice, a vendor bill, a refund, or a journal entry depending on move_type. A noun mapping is what stops an AI from counting all of them as “the invoices.”

Default filter

Records the context-dependent filter that a class of questions needs, and, just as importantly, when not to apply it.

For accounting-impact analysis, restrict account.move to state = posted. Draft-workflow questions must not use this filter blindly.

Join path

A typed relationship path, so an AI joins tables the correct way rather than guessing a plausible one.

To get from sale.order.line to res.partner: sale.order.line → order_id → sale.order → partner_id → res.partner.

A different join path can silently answer a different question. Typing the path removes the guess.

Field semantic

Explains what a field actually means, rather than trusting its label.

On account.move, the salesperson is invoice_user_id, not a guessed user_id.

Negative knowledge

Encodes a tempting interpretation that is wrong, the trap itself, so an AI is warned off it.

Treating one plausible-looking total field as a universal revenue metric mixes different document types and business definitions. Resolve the metric definition and record population first.

Disambiguation

Marks a concept that has more than one valid business meaning, and the question that resolves it.

“Revenue” can mean general-ledger revenue or invoice-based sales, on different date bases. The correct behavior is often to ask which definition applies, not to pick one silently.

For genuinely ambiguous questions, asking a clarifying question is the right answer, and the layer says so rather than forcing a single universal definition.

Security note

Records a visibility or boundary rule that changes what an answer means.

Records visible under allowed_company_ids are not proof of globally complete records.

Company, currency, and access boundaries change the answer. The layer carries them so an AI does not mistake “what I can see” for “what is true.”

Gotcha

Flags a context-sensitive computed value that answers a different question than intended when its scope is left implicit.

Reading a stock quantity without defining company, warehouse, or location scope can answer a different question than the one asked. Make the scope explicit first.

Write policy

Represents a high-risk business transition and how to perform it safely.

Posting an account.move is a critical operation. Prefer the model’s business method after authorization and validation; require an explicit record set, Odoo authorization, and human approval.