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.