Entry anatomy.

An entry is the atom of the context layer: one small, self-contained fact about what something in Odoo means and how to use it safely. Everything else, packs, retrieval, context assembly, is built out of entries.

The example below is a real entry from the public format examples. It is a format demonstration, not a released registry entry, so read it for its shape rather than as a guaranteed fact.

{
  "document_kind": "ocl.entry",
  "schema_version": "0.1.0",
  "id": "ocl.example.odoo19.account.customer_invoice",
  "type": "noun_mapping",
  "status": "evidence_attached",
  "applies_to": {
    "odoo_versions": ["19.0"],
    "editions": ["community", "enterprise"],
    "requires_modules": ["account"]
  },
  "claim": {
    "summary": "A customer invoice is an account.move whose move_type is out_invoice.",
    "business_noun": "customer invoice",
    "aliases": ["sales invoice"],
    "model": "account.move",
    "domain": [["move_type", "=", "out_invoice"]],
    "limitations": ["Add state = posted only when the task requires accounting impact."]
  },
  "evidence": [
    {
      "id": "move_type_source",
      "kind": "source_code",
      "locator": "https://github.com/odoo/odoo/blob/7beeb76.../account_move.py#L142-L159",
      "observed_at": "2026-07-11"
    }
  ],
  "assertions": [
    { "id": "out_invoice_selection", "kind": "selection_contains", "mode": "snapshot",
      "target": { "model": "account.move", "field": "move_type" }, "expected": ["out_invoice"] },
    { "id": "domain_executes", "kind": "domain_executes", "mode": "live_read",
      "target": { "model": "account.move", "path": "claim.domain" }, "expected": true }
  ],
  "confidence": {
    "score": 0.99,
    "basis": "pinned_official_source",
    "rationale": "The discriminator is explicit; live execution remains pending."
  },
  "provenance": {
    "created_by": "stage1-source-normalizer",
    "created_at": "2026-07-11",
    "change_reason": "Public v0 format example."
  }
}

The claim

The claim is the meaning itself, in a form an AI can act on. For a noun mapping it names the business_noun (“customer invoice”), its aliases, the model it lives on, and the domain that selects the right records. limitations records the fine print: here, that state = posted belongs only when the task actually needs accounting impact, so an AI does not silently exclude draft invoices when the question did not ask it to.

Domains are portable. A condition is [field, operator, value], logical operators are "&", "|", "!", and runtime values use a structured placeholder such as {"$var": "today"} rather than an unquoted expression. That keeps a claim readable by any consumer, not just Odoo.

Applicability

applies_to is the scope: the Odoo versions, editions, required modules, and localizations a claim holds for. It is what makes the layer honest across setups. A fact proven on Odoo 19 Community with the account module installed says exactly that, and the assembler will not hand it to an AI working a database where it does not apply.

Evidence

evidence is where the claim comes from: pinned source code (a file, a commit, line numbers), official documentation, a live observation, or expert review. Evidence is referenced by id from the assertions, so every check points back at what it is checking against. The customer-invoice entry cites the exact lines of Odoo’s account_move.py at a pinned commit.

Assertions

assertions are the executable part: code that proves the claim on a real Odoo. Each has a kind and a mode.

• snapshot assertions check normalized metadata, for example that move_type really offers out_invoice as a selection value (selection_contains).
• live_read assertions run against a live database, for example that the claim’s domain actually compiles and executes (domain_executes).

Syntax validation alone does not prove a domain runs on a model; that is exactly what a live_read assertion is for. This is the mechanism behind the layer’s core promise: a fact is only as good as the checks that pass for it.

Confidence

confidence is a separate estimate with a score, a basis, and a rationale. It is deliberately not the same thing as trust state. An entry can cite a pinned official source and still be only evidence_attached because its live assertions have not run yet, exactly as the example shows: confidence 0.99, status evidence_attached.

Provenance

provenance records who created the entry, when, who reviewed it, and why it changed. Combined with immutable releases, this is what lets a consumer trust that a fact has not quietly shifted under them between one answer and the next.

The shape, in one line

A claim, proven by assertions against cited evidence, scoped by applicability, rated by confidence, and signed by provenance.

Every kind of knowledge in the layer, noun mappings, negative knowledge, field semantics, joins, security notes, and disambiguations, uses this same envelope. What changes between them is the shape of the claim. See Kinds of knowledge.