---
id: ADR-MBR-STR-017
title: Retain Stable Configuration and Product Identities
product_area: membership
module: structure
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Kinds, relationship purposes, programs, types, reasons and policy sets use permanent readable identifiers;
  units have permanent internal identity with changeable codes, and extensions share product identity.
constrains:
  - DOM-MBR-STR-006
  - DOM-MBR-STR-001
  - DOM-MBR-STR-003
  - SVC-MBR-STR-configuration
  - SVC-MBR-STR-structure
origin: >-
  services-membership:modules/configuration/services/configuration/configuration-records.ts (an id is the
  request's configuration id, or one made from the name)
alternatives:
  - option: Generate opaque identifiers for all configuration.
    why_not: That would change direct import and known-record references that currently use readable keys.
  - option: Allow configuration identity to change with its name.
    why_not: >-
      That would require coordinated reference and crosswalk rewriting instead of the existing immutable
      identity contract.
consequences:
  - Imports can directly name readable configuration records.
  - 'Display names remain editable, but an existing configuration identity cannot be renamed.'
  - Replacing grants and policies allocates new generated identities; other owned lists use composite keys.
supersedes: []
evidence:
  - >-
    services-membership at 5994c270: modules/configuration/services/configuration/configuration-records.ts;
    modules/structure/services/persistence/organizational-unit-types.ts
---

# Retain Stable Configuration and Product Identities

## Context

Imports and other records need stable references even when staff change display labels. Product extensions also need a shared identity across their owning services.

## Decision

This record describes the implemented identity schemes. Readable configuration, internal unit identity and product-extension identity serve different reference needs and are not interchangeable.

## Alternatives Considered

Generate opaque identifiers for all configuration. That would change direct import and known-record references that currently use readable keys. Allow configuration identity to change with its name. That would require coordinated reference and crosswalk rewriting instead of the existing immutable identity contract.

## Consequences

Imports can directly name readable configuration records. Display names remain editable, but an existing configuration identity cannot be renamed. Replacing grants and policies allocates new generated identities; other owned lists use composite keys.