Skip to content

Repo Boundaries

This page defines how dirac-abs fits with the adjacent DIRAC documentation repos.

Primary Role

dirac-abs is the developer-facing repository for ABS-side implementation semantics.

It should be the primary place to document:

  • asset lifecycle and asset-state behavior
  • bundle realization on the ABS side
  • entitlement state and service activation logic
  • station, technician, rider, and device-facing workflows
  • IoT coordination and operational event handling

What Belongs In Adjacent Repos

dirac-odoo should own:

  • ERP object semantics
  • inventory, sales, CRM, and people models
  • commercial transactions and governed Odoo object behavior
  • Odoo-side implementation and extension strategy

emob-commercial-models should own:

  • operations-facing commercial model language
  • product-unit and bundle operating definitions
  • pricing, rollout, and SOP guidance
  • business-facing and field-operations-facing process framing

Handoff Rules

When a topic crosses repo boundaries, keep the split explicit:

  • document ABS execution semantics here
  • document Odoo ERP semantics in dirac-odoo
  • document commercial operating intent and SOP framing in emob-commercial-models

If the same concept appears in more than one repo, this repo should explain the ABS implementation meaning rather than restating the commercial or ERP meaning.

Shared Invariants

  • PA is the correct current term for the portal application surface. OVApp is a legacy term and should only appear where historical reference is necessary.
  • Entitlement is authorized by Odoo business transactions and enforced/substantiated by ABS in physical and IoT operations.
  • Pricing source of truth remains in Odoo. ABS may reference pricing context but does not own pricing truth.
  • service template is reserved for commercial and operational packaging in emob-commercial-models.
  • service model is reserved for runtime ABS behavior in this repo.
  • Asset affiliation should not be invented separately in ABS. Current asset anchoring should follow Odoo stock and inventory constructs rather than a separate ABS-owned affiliation model.

Conflict Resolution

When repos disagree, use this tie-break rule:

  • functional intent conflicts are resolved by emob-commercial-models
  • Odoo implementation conflicts are resolved by dirac-odoo
  • ABS implementation conflicts are resolved by dirac-abs

Short Form

  • dirac-abs explains how asset-based services work in ABS.
  • dirac-odoo explains how the ERP side works in Odoo.
  • emob-commercial-models explains what commercial and operations teams are trying to deliver across both systems.