Context Layer for Odoo

Verification and trust.

What "verified" means in the context layer, and what it deliberately does not mean. The entry trust states, the difference between confidence and verification, immutable content-addressed releases, and provenance.

OCL format v0 · Odoo 19 Updated 2 August 2026

The context layer exists to solve one problem: an AI given raw Odoo schema guesses, and its guesses look plausible whether they are right or wrong. So the whole point of an entry is that its meaning is proven, not asserted by a language model. This page is how that proof works.

The rule this is built around

“Verified” must never mean “an LLM wrote plausible YAML.” A fact earns the word by passing executable checks and, where the policy requires it, human review, never by sounding confident.

Trust states

An entry moves through explicit states. It never skips to the end.

draft -> evidence_attached -> asserted -> verified
                                 |            |
                                 v            v
                              degraded -> deprecated -> retired

draft: the claim is written but not yet backed.
evidence_attached: sources are cited, but the checks have not run.
asserted: the entry’s declared assertions pass at their stated level.
verified: the entry has passed its full release policy, including live and behavioral assertions and human review where applicable.
degraded / deprecated / retired: the branches for a fact that stopped holding, was superseded, or was withdrawn.

asserted and verified are different on purpose. Assertions passing is necessary but not sufficient: verification is the whole release policy, not one green check.

Confidence is separate

Every entry also carries a confidence score. It is an estimate of how sure the claim is, with a basis and a rationale. It is not the trust state and can never raise it. An entry can cite a pinned official source and score high confidence while still sitting at evidence_attached because its live assertions have not been executed. Keeping the two apart is what stops a confident-sounding guess from being treated as a proven fact.

Executable verification

Verification is code, not prose. An entry’s assertions run against real Odoo:

snapshot assertions check normalized metadata (does this field really offer this selection value?);
live_read assertions run against a live database (does this domain actually compile and execute on this model?).

A claim that code cannot fully prove, a business convention, a policy, an interpretation, needs source evidence or explicit human confirmation before it can advance. This is why the layer is categorically different from documentation or from an LLM generating YAML: the claim and the check that proves it travel together.

Immutable, content-hashed releases

Released entries are frozen. Once an entry is released it is immutable, and releases are content-hashed: a release is identified by a hash of its contents, so any change produces a different release rather than silently mutating an existing one. A consumer can therefore pin a release and know the meaning it is reading today is byte-for-byte the meaning it read last week.

Note that release membership is established by the catalog and its release locks, separately from an entry’s trust state. “Released” and “verified” are related but distinct: an entry is verified by passing its policy, and it is part of a release by being in a signed, hashed catalog.

Verification is re-run against multiple Odoo 19 anchors so a release is not proven against a single moving target. See Coverage and release status for the anchors and what is released today.

Provenance

Every entry records who created it, who reviewed it, when, and why it changed. Provenance plus immutable releases is what makes the layer auditable: a fact can be traced from the answer an AI gave, back through the entry it used, to the evidence and the checks that proved it.