ADR 0002: `ov.*` Model Namespace And Semantic Independence¶

2026-04-07

Status¶

Accepted

2026-04-06

dirac-odoo uses custom Odoo models such as ov.serviced_account, ov.membership, and ov.asset.

Discussion around SA asset modeling exposed a naming ambiguity:

readers may incorrectly infer that the ov.* prefix means all ov.* models belong to one tightly coupled object family
readers may also incorrectly infer that SA-scoped wrapper objects should use an sa.* technical namespace

The repo needs an explicit naming rule so model names are interpreted consistently.

Custom Odoo models in this design space should continue to use the ov.* prefix.
This is a technical/module namespace convention, not a semantic claim about model coupling.
SA remains the business and governance concept name, not the technical model prefix.

A model named ov.<class> must not be assumed to have a direct relationship with every other ov.<other_class>.
Direct relationships must be explicit in fields, invariants, and design documentation.
Semantic scope must be read from the model's documented responsibility, not from namespace similarity alone.

A wrapper object that exists primarily for SA governance may still use an ov.* name such as ov.asset.
This does not require renaming it to sa.asset.
If such a wrapper is kept, its SA meaning should be expressed by:
its documented role under SA governance
its relationships to SA and native Odoo objects
its {actor, sa} visibility and attribution semantics when applicable

Current examples:

This keeps the technical namespace stable while allowing each model to remain semantically distinct.

The repo can keep ov.asset as a valid name even if its only tight coupling is to SA visibility/governance and native Odoo asset objects.
Future ov.* models do not implicitly inherit relationships or invariants from existing ov.* models.
Documentation must keep relationship boundaries explicit so readers do not infer architecture from prefix alone.