Association Communication

What It Models

An association communication combines a workflow’s e-mail request with recipient messages, provider attempts and later reports. Suppression, sender verification and shared lane capacity belong here because they determine whether each message can be submitted.

Identity and Attributes

Workspace, submitting service and repeat key derive the request identity. The request and recipient key derive each message identity. Canonical addresses identify active workspace suppressions, and each workspace has at most one sender setting.

Relationships

The communication message retains its template publication reference, and Communications owns both records. Current association messages do not reference staff inbox notices.

Invariants

The invariant rows identify the guarantees supported by the cited evidence and the layer enforcing each one. They retain implementation gaps rather than treating intended behavior as complete enforcement.

How It Is Stored and Shared

An uncertain provider acknowledgement can lead to resubmission after fifteen minutes. A suppression failure after feedback commitment can leave a bounced address eligible. Sending lanes have no workspace fairness policy, and purge ownership for adopted provider identities is unresolved.

Open Design Questions

The module findings retain unresolved authority, recovery and source-boundary questions affecting this object.