10.1 Asset Provenance and RWA-Readiness¶

Purpose¶

This note defines the provenance model for LEV assets across their full lifecycle, and frames the RWA (Real World Asset) conceptual requirements that the model must support.

The goal is to ensure the domain model is tokenization-ready — the registry and provenance records should be structured so that a future RWA smart contract can reference them as the authoritative off-chain source.

Scope¶

Provenance in this context means the complete, verifiable history of an asset from birth to retirement:

Phase	Provenance Question
Birth	Where/when was it assembled? What components went into it?
Service	What maintenance has been performed? Which components were replaced?
Ownership	Who owns it now? What is the transfer history?
Performance	What is the production rate (for fleet assets)? What is the revenue generation rate?
Retirement	When/why was it retired? What was the disposal path?

This is broader than warranty — warranty is one consumer of provenance, but the provenance model serves all downstream consumers (quality investigations, RWA tokenization, regulatory compliance, resale).

Starting Point: The Build Record¶

The Build Record (defined in 9.2-build-record-and-asset-passport.md) is the first provenance record.

It establishes: - Asset identity (oem_id) - Component provenance (chassis_id, motor_id, mcu_id, CKD lot) - Production context (MO reference, assembly location, personnel)

Every subsequent lifecycle event extends the provenance chain — the Build Record is the anchor, and each event appends to the chain.

Build Record → 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)

The Asset Passport is the destination concept: the Build Record evoles into the Asset Passport as provenance, service, and performance data accumulate. The Asset Passport is the RWA-ready object — structured so that a future RWA smart contract can reference it as the authoritative off-chain source.

RWA Conceptual Framing¶

RWA tokenization requires an off-chain registry that can answer, for any given asset, a set of authoritative questions.

2.1 Asset Identity and Status¶

RWA Question	What The Registry Must Provide
Where is the asset?	Current location (GPS, assigned SA, service center)
What kind of asset is it?	Product model, specifications, configuration
Is it real?	Build Record with component provenance; crypto-anchoring (future)
Is it alive?	Registry status (`active` / `inactive` / `retired`); last heartbeat (future TPM)
Is it under control?	Assigned owner/operator; SA association; theft/lose flag

2.2 Asset Performance¶

RWA Question	What The Registry Must Provide
Rate of production	MO completion records; assembled-count-by-model-by-period
Rate of revenue generation	Sale records; service contract records; energy generation (future)
Utilization rate	Service intervals; odometer / runtime (future TPM)
Health score	Warranty claim history; QC test results; component age

Design Principle: Tokenization-Ready¶

The registry and provenance model must be designed so that:

Each asset has a unique, stable identifier (oem_id) — this is the token's off-chain reference.
Provenance records are append-only and hashable — each lifecycle event can be hashed and anchored to a blockchain (future TPM / crypto-anchoring).
Asset status is machine-readable — an RWA smart contract can query the registry via an API and get a definitive answer on asset reality, liveness, and control.
Performance data is structured and queryable — revenue, utilization, and health metrics are available for on-chain valuation models (future).

What Is NOT Covered Here¶

Technical RWA integration details (how RWA tokens are minted, how valuation is performed on-chain, how coin integration works) — this will be covered in a separate technical note. Remind me to supply this.
TPM / crypto-anchoring implementation — the design goal is tokenization-readiness; the actual anchoring mechanism is a future implementation decision.
Odoo implementation details — deferred to dirac-odoo ADR 0007 and future ADRs.

Relationship to Other Notes¶

Note	Relationship
`9.2-build-record-and-asset-passport.md`	Build Record = first provenance record; Asset Passport = evolved RWA-ready concept; this note extends both to full lifecycle
`9.1-assembled-asset-registry-foundation-for-warranty-and-service.md`	Registry foundation; provenance model extends the registry
`docs/adr/0002-asset-registry-lineage-and-lifecycle-governance.md`	Conceptual ADR; provenance is part of lifecycle governance
`dirac-odoo/docs/adr/0007-asset-registry-and-component-model-implementation.md`	Odoo implementation; tokenization-readiness must be reflected in model design

Next Steps¶

Expand provenance model — define the data structure for each lifecycle event (service, ownership transfer, performance metric capture).
Supply technical RWA integration note — the user will provide details on how RWA tokens are integrated with coin, valuation, etc.
Reflect tokenization-readiness in Odoo model — update dirac-odoo ADR 0007 or create a new ADR to capture the model fields required for RWA reference.