Context Layer for Odoo
Context packs and offline.
A context pack is the assembler's output for one question: the smallest applicable, verified context, sized for a model. How packs work, why assembly is risk-preserving, and how signed offline caches serve the layer without a live connection.
What a context pack is
A context pack is what the AI actually reads. For one question, the assembler selects the applicable entries, joins, filters, and warnings, attaches provenance, and emits a single request-scoped artifact that conforms to the public context-pack schema.
A pack is deliberately small. It is not a dump of the registry; it is the minimum verified context that answers the question. That keeps token cost down and keeps the model’s attention on what matters.
Risk-preserving assembly
Selecting “the smallest context” has a hard rule: critical warnings cannot be dropped to meet a token budget. If a question touches a posting operation, a company boundary, or a misleading field, the warning that goes with it stays in the pack even under pressure. Assembly trims redundancy, never safety.
Deterministic over released content
Retrieval and assembly over the released kernel are deterministic: the same question against the same pinned release produces the same pack. That is what makes a pack reproducible and auditable.
Static packs
Because a pack is a self-contained artifact, you do not need a live service at answer time. You can assemble a pack ahead of time and hand it to a model directly, in a prompt, a file, or a pipeline. This is the simplest way to give an AI verified Odoo meaning with no runtime dependency.
Signed offline caches
For offline or air-gapped use, the layer can be served from a signed offline cache: an entitlement-scoped, content-hashed cache that a licensed user verifies, installs, and serves locally. The signature is what lets you trust a cache you received rather than fetched live, and the content hash is what lets you pin exactly which released meaning it carries.
Signed caches come with runtime access
The offline cache is implemented and tested locally. Because a signed cache carries the verified registry, it is delivered through verified runtime access, not a public download. The open standard on GitHub covers the format and the ten-example demonstration; request runtime access for a signed cache of the verified kernel.
When to use which
- Static pack: one-shot or batch questions, prompt engineering, no live service wanted.
- Live operations (MCP or REST): interactive agents that call
get_contextper question. See Consuming the layer. - Signed offline cache: air-gapped, on-premise, or offline deployments that still need the released kernel.