Skip to content

9.2 Build Record & Asset Passport

Purpose

The Build Record is the starting point of an LEV entity's lifecycle. It is created at the moment the asset enters the registry — the "true birth" as defined in ADR 0002 and the assembled asset registry foundation.

This note defines the business goal and information scope of the Build Record. It also introduces Asset Passport — the evolved concept that the Build Record grows into over the asset's lifecycle.

Implementation details are deferred to the Odoo model extension (ADR 0007 in dirac-odoo).

Terminology

Term Meaning
Registry The Odoo model (ov.asset.registry) — the container that holds all Build Records
Build Record A single row in the registry — the assembly-time record for one specific asset
Asset Passport The evolved Build Record — as provenance, service, and performance data accumulate, the Build Record becomes the Asset Passport (the RWA-ready object)

Business Goal

Transparency and traceability.

The Build Record must contain sufficient information to support:

Concern What The Build Record Enables
Warranty Verify manufacturing date, batch, and component provenance to validate warranty eligibility
Quality Control Trace any quality issue back to the specific batch, shift, or component lot
Productivity Link the asset to the MO, assembly line, and personnel for efficiency analysis
Provenance Establish an immutable record of what components went into the asset
TPM / Crypto-Anchoring Provide a hashable payload for future TPM or blockchain anchoring to prove asset authenticity

Information Scope (Domain Level)

The Build Record must capture:

Core Identity

  • oem_id — the unique serial number of the finished vehicle
  • Manufacturing date / time
  • Manufacturing Order (mo_id) reference

Component Provenance

  • chassis_id
  • motor_id
  • mcu_id
  • CKD batch / lot reference (ckd_lot_id)

Production Context

  • Assembly location
  • Production line / station
  • Personnel references (assembler, QC inspector) — future

Quality Gates

  • Test results reference (future)
  • QC pass/fail status
  • Packaging completion

From Build Record to Asset Passport

The Build Record is the seed. Over the asset's lifecycle, it accumulates:

Build Record  (assembly event)
    ↓
+ Service events  (maintenance, component replacement)
    ↓
+ Ownership transfers  (sale, lease, re-assignment)
    ↓
+ Performance data  (production rate, revenue, utilization)
    ↓
Asset Passport  (living record — the RWA anchor)

Asset Passport is the destination concept: - The Build Record is the assembly-time snapshot. - The Asset Passport is the full provenance + performance record, structured so that a future RWA smart contract can reference it as the authoritative off-chain source.

The registry (ov.asset.registry) stores the Build Record. The Asset Passport is the logical evolution of that record — enabled by appending lifecycle events to the provenance chain.

Version Scope

This version is about the birth of the asset — the creation of the Build Record and the capture of component provenance.

Future versions will extend the concept to: - Crypto-anchoring (hash of Build Record anchored to blockchain) - TPM integration (secure element on the vehicle itself) - Dynamic warranty state transitions (sale → activation → claim) - Performance data capture (production rate, revenue generation) - Asset Passport structure definition (RWA-ready payload format)

Relationship to Odoo Implementation

The Odoo model (ov.asset.registry and ov.asset.component) implements this domain concept.

Specific implementation decisions (field names, triggers, Odoo integration points) are documented in: - dirac-odoo/docs/adr/0007-asset-registry-and-component-model-implementation.md

The Build Record payload in Odoo is the union of: - ov.asset.registry record (core identity, status, warranty dates) - ov.asset.component records (component provenance, replacement history)

Design Principle

The Build Record is the single source of truth for asset identity. All downstream processes (warranty, service, resale) must reference the registry — not Odoo stock models, not MO records, not packaging logs.

Traceability is a business requirement, not an Odoo implementation detail. The registry and its Build Record exist to serve transparency — for the customer, for quality investigations, and for future trust infrastructure (TPM, crypto-anchoring, RWA tokenization).

Cross-Reference

  • Conceptual ADR: docs/adr/0002-asset-registry-lineage-and-lifecycle-governance.md
  • Domain foundation: docs/9-warranty/1-assembled-asset-registry-foundation-for-warranty-and-service.md
  • Provenance & RWA: docs/10-provenance-and-rwa/1-asset-provenance-and-rwa-readiness.md
  • Odoo implementation ADR: dirac-odoo/docs/adr/0007-asset-registry-and-component-model-implementation.md