ADR 0002: Asset Registry, Lineage, and Lifecycle Governance

Status

Proposed

Context

OVES operates a CKD-based supply and local assembly model:

• CKD kits are shipped to local markets
• assembly operations transform CKD into finished-goods motorcycles
• critical component serials such as chassis, motor, and MCU are only revealed at assembly

The system must support:

1. reliable CKD-to-FG transformation tracking
2. a human-usable FG identity such as oem_id
3. component-level lineage tracking over time
4. a registry-based verification system driven by QR lookup
5. future extensibility into ABS, IoT, and anti-counterfeit governance

Decision

Adopt a lifecycle-oriented identity stack with three layers:

• conceptual layer: emob-lifecycle-models
• implementation layer: ov.asset.registry
• supporting lineage layer: ov.asset.component

Core Design Principles

P1: Lifecycle-Centric Design

Assets evolve through assembly, operation, service, replacement, and retirement.

P2: Identity Versus Lineage Separation

• identity stays stable at vehicle level
• components are dynamic and may be replaced over time

P3: Traceability Begins At Assembly

• CKD remains lot-based
• identity is formed when component identifiers are revealed

P4: Odoo As Transactional SPOT

Odoo handles:

• manufacturing orders
• inventory movements
• lot and serial traceability

Registry handles:

• identity binding
• component lineage
• lifecycle evolution beyond the first production event

P5: MVP First

The first version prioritizes registry reliability, QR lookup, and ID comparison before advanced cryptographic trust features.

System Architecture

Layer	Responsibility
Odoo	Inventory, MO, and serial records
Assembly Operations	Capture real-world identifiers
ov.asset.registry	Stable asset identity anchor
ov.asset.component	Component lineage and replacement history
Future Trust Layer	Verification hardening and anti-counterfeit controls

Model Structure

ov.asset.registry

Represents a single FG asset.

Field	Description
oem_id	Human-readable FG serial
product_template_id	Vehicle model
lot_id	Link to Odoo FG serial
mo_id	Manufacturing order
ckd_lot_id	Source CKD batch
status	active, inactive, or retired
qr_code	Encoded lookup reference
tracking_id	Future trust or cryptographic identifier

ov.asset.component

Tracks component relationships to the registry record.

Field	Description
registry_id	Link to asset registry
component_type	chassis, motor, or mcu
component_id	OEM component serial
state	active, replaced, or retired
timestamp	Event time
source	assembly or service

Operational Flow

1. receive CKD shipment and assign a CKD lot
2. issue CKD lot to the assembly line
3. capture chassis_id, motor_id, and mcu_id
4. generate or assign oem_id
5. create the registry record
6. create active component-lineage records
7. complete the manufacturing order and link the FG serial to the registry

Post-Production Lifecycle

Field Verification

Input:

• oem_id
• one or more observed component identifiers

Expected result:

• PASS
• FAIL
• UNKNOWN

Service And Replacement

When a part is replaced:

1. mark the old component record as replaced
2. insert the new component as active
3. record timestamp and source

Lifecycle Traceability

The registry should preserve:

• original assembly bundle
• replacement history
• current configuration

Key Rules

• one asset equals one registry record
• no FG without identity
• identity capture at assembly is mandatory
• history is preserved through state transitions, not destructive overwrite
• CKD remains lot-based
• registry complements Odoo instead of duplicating inventory logic

Consequences

Benefits

• minimal disruption to the transactional core
• stronger lifecycle traceability
• clean support for service and IoT extension

Trade-Offs

• MVP verification is not cryptographically strong yet
• assembly discipline remains critical
• registry quality depends on accurate data capture