ADR-006 - Asset Type Definition
- Status: Superseded
- Decision Date: 2026-03-24
- Deciders: PIES Design Team
- Category: Data Model, Ontology
Context​
The current data model embeds asset identification directly within message headers, mixing transport concerns with semantic identity. As the model evolves to support Groups (which contain multiple assets) and Linkages (which reference assets), a consistent, reusable way to identify and reference assets across message types becomes necessary. Without a formal Asset type, duplicate identification logic appears in multiple places, creating maintenance burden and inconsistency.
Decision​
Define Asset as a reusable data type consisting of three required fields: record_id, system_id, and record_kind. This type serves as the canonical reference to an asset across all message types and can be used individually or in collections (asset_set).
Rationale​
Extracting Asset as a type creates a single definition for how resources are identified within the PIES domain. This reduces duplication, ensures consistency across Group, Linkage, and other message types, and makes the specification more maintainable. The three-field composition (record_id, system_id, record_kind) provides sufficient context to uniquely locate and type a resource in the sector without requiring external lookups during message construction.
Assumptions​
- The combination of record_id, system_id, and record_kind uniquely identifies a resource within the PIES ecosystem.
- record_kind is fixed at the time of asset creation and does not change.
- record_kind will have a finite, codified set of values that can be validated against a controlled vocabulary.
- Clients can tolerate the presence of record_kind in every asset reference.
Options Considered​
- Embed asset identification in message headers only: Simpler locally but creates duplication and inconsistency when assets must be referenced in Groups or Linkages. Rejected.
- Create a separate Asset Registry service: Allows dynamic asset lookup but adds operational complexity and introduces a new external dependency. Rejected as over-engineered for current requirements.
- Reusable Asset type (chosen): Define Asset once, use consistently across message types. Balances simplicity with composability and maintainability.
Consequences​
Positive​
- Consistent asset identification across all message types and contexts.
- Single definition reduces maintenance burden and documentation complexity.
- Asset collection patterns (asset_set) become natural and well-defined.
- More flexible identification in JSON payloads without requiring external resolution.
Negative​
- Every asset reference now includes record_kind, slightly increasing payload size.
- Validation must ensure that record_kind is consistent with the actual record type being referenced.
- Future changes to asset identification semantics require coordinated updates across all message types using Asset.
References​
- ADR-004 requires asset identification in Group and Linkage types.
- PADS-646 Outcomes discussion on asset type extraction from Header.