---
id: ADR-CRM-ENT-002
title: The Contact Owns Its Affiliations
product_area: crm
module: entities
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-crm: 7ea48a414c42eade10d60753b8bcc323b1dd726f
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
decision: >-
  Affiliations and role periods are persisted through the owning contact
  aggregate, using its transaction and version; the implementation creates,
  edits, ends and removes them through contact saves without separate
  affiliation write routes.
constrains:
  - DOM-CRM-ENT-001
  - DOM-CRM-ENT-003
  - SVC-CRM-ENT-entities
  - WF-CRM-ENT-002
  - SCR-CRM-ENT-004
  - SCR-CRM-ENT-007
origin: >-
  D-09 (Andrew, 2026-10-19), cited in services-platform
  docs/standards/record-write-contracts.md W3; CRM-M2 plan; OQ-CRM-ENT-005 open
alternatives:
  - option: 'Give affiliations independent create, end and remove operations.'
    why_not: >-
      Explicit end and remove operations meet the Platform standard, but the
      approved planning and current clients use save-based relationships. The
      migration choice remains open.
  - option: Let the organization persist its own contact list.
    why_not: >-
      That would introduce a second writer for one relationship. Organization
      screens instead update the owning contact.
consequences:
  - 'Contact versions, revisions and change events cover relationship work.'
  - >-
    Organization-side relationship edits can conflict with an open contact
    editor.
  - General-save ending still disagrees with the explicit-operation standard.
evidence:
  - >-
    services-crm at 7ea48a41: modules/entities/aws/api/contacts.routes.ts
    (header); modules/entities/services/persistence/contact-affiliations.ts
  - 'react-console at da630758: lib/affiliations/contact-write.ts'
  - 'services-platform at ad3f6a65: docs/standards/record-write-contracts.md W3'
---
# The Contact Owns Its Affiliations

## Context

Contacts are the persistence owners for relationship periods and their roles. An organization screen can present those relationships without becoming another writer of the same data.

## Decision

Affiliations and role periods are persisted through the owning contact aggregate, using its transaction and version; the implementation creates, edits, ends and removes them through contact saves without separate affiliation write routes.

## Alternatives Considered

Give affiliations independent create, end and remove operations. Explicit end and remove operations meet the Platform standard, but the approved planning and current clients use save-based relationships. The migration choice remains open.

Let the organization persist its own contact list. That would introduce a second writer for one relationship. Organization screens instead update the owning contact.

## Consequences

The current aggregate boundary is supported by code and planning. It does not resolve the Platform requirement for explicit relationship ending and removal. The existing open question must settle an exception or migration before implementation preparation.

Contact versions, revisions and change events cover relationship work. Organization-side relationship edits can conflict with an open contact editor. General-save ending still disagrees with the explicit-operation standard.