CRM

Purpose and Outcomes

Today Rhythm CRM gives association staff a shared record of the people and organizations with whom they work. It connects a person's identity and contact details with dated organizational affiliations, the responsibilities held within those affiliations, geographic placement, interactions, and follow-up work. The same contact can be a professional society's individual member, an employee of a corporate member, and a committee volunteer. CRM supplies the common identity; the applications responsible for membership, finance, commerce, and governance retain their own records about that person.

The CRM architecture explains why stable identity matters: changing an employer, correcting an address, combining duplicate records, or retiring a closed organization can affect work throughout Rhythm. The area's purpose includes preserving enough relationship and change context for staff to understand those effects. A useful outcome is more than a clean contact list. Staff need to distinguish a current affiliation from a past one, an organization's shared address from a person's own address, a possible duplicate from a confirmed combination, and an archived identity from a removed record.

Today the corpus describes four implemented modules: Entities, Data Quality, Regions, and Activities and Tasks. Their specifications and findings establish the detail and the limits of the examined implementation. This document explains how those modules fit together and the architecture that guides their development. Built behavior is identified as today's behavior; a product ruling is identified as a decision; an undecided design is identified as a proposal. A proposed architecture is not evidence that the corresponding screen, contract, or safeguard works in a deployed environment.

Andrew also records future directions for first-class households, person-to-person relationships, membership coverage, and CRM-owned enrichment. These extend the information CRM can supply without transferring membership entitlement, financial responsibility, or Platform security into CRM. Household implementation remains deferred until a signed customer needs it. Enrichment has six recorded gating decisions and six open decisions; its architecture record establishes no implemented enrichment product.

Who Uses It

Today the CRM Editor maintains contacts, organizations, their contact details, and affiliations. A membership coordinator uses this work to record a member's new employer while retaining the previous connection. The CRM Reader finds people and organizations and inspects permitted history without changing the records. These are responsibilities, not additional security roles; the authorization model determines which operations each caller may attempt.

The CRM Administrator maintains classifications, record protections, regional definitions, and placement policy. Duplicate Review Staff assess suggested identities and resolve false matches. The Record Quality Administrator configures matching behavior and prepares reviewed combinations. These roles serve different questions: whether two records appear related, whether they represent the same identity, and whether an authorized combination is safe to execute.

Today the Task Contributor manages personal and shared work, including reserving available queue or role-offered tasks. The Workflow Action Engine is a trusted service caller that delegates application work through the task contract. The CRM System maintains related information and evaluates organization compliance. The Data Importer brings external records into CRM through authorized data jobs rather than bypassing the owning record services.

Today a Portal Registrant participates in Platform registration with contact suggestions supplied by CRM. This limited registration seam does not establish a general CRM portal editing experience. The household design proposes managers and guardians who act under scoped Platform grants, while the enrichment design proposes review responsibilities and provider administration. Those future responsibilities are described with their architecture rather than added to the area's current actor catalogue here.

Key Business Processes

Today establishing and maintaining a constituent starts with contact or organization creation, classification, and contact information. The existing journey Create a member record and inspect the saved information follows the contact experience. The Contact Records and Organization Records feature acceptance suites specify cumulative feature outcomes. An association can then record organizational ties through Record an employer change while retaining the previous affiliation, which connects relationship maintenance with historical context. The Affiliations and Roles feature suite and the Organization Compliance feature suite cover their respective parts of that process.

Today identity-quality work connects duplicate review with a merge preview, staff choices, execution, and retained outcomes. The journeys A reviewer settles duplicate work and revisits a dismissal, An administrator combines a sparse contact with a member record, and A colleague follows an absorbed identity and inspects its history explain that chain. The modules retain the precise guards for review, plan freshness, permissions, and participant behavior. A suggestion alone is not permission to combine identities.

Today geographic administration connects coverage definitions with saved policy and a separate recalculation of existing records. The regional journeys An administrator establishes geographic placement and An administrator applies revised coverage to existing records explain the distinction. Staff preserve an intentional exception through A coordinator maintains and releases a regional exception. Changing policy and applying policy to the existing population are different pieces of work.

Today staff record interactions and the work they generate. Log a shared meeting and create its follow-up connects the interaction with a task; Take a task through completion, reopening and cancellation explains closing attribution; Claim, release and transfer shared queue work explains shared responsibility. Archive a closed organization and inspect its retained history connects lifecycle controls with the retained record.

No product-area acceptance suite is present in the supplied CRM corpus. The journeys, feature suites, and capability test specifications provide scoped contracts, but they do not substitute for a product suite proving each complete process across modules. It is not established here that these chains pass in a deployed environment. Product-area qualification remains an open coverage question recorded in the composition report.

Scope and Boundaries

Today CRM owns constituent identities and the CRM records that describe relationships, quality, placement policy, interactions, and work. Entities owns contacts and organizations, their owned details, affiliations, role periods, classification catalogues, compliance, settings, and record safeguards. Data Quality owns duplicate evidence, review decisions, merge plans, attempts, aliases, and retained outcomes. Regions owns geographic definitions and assignment policy; the placements themselves remain on Entities-owned records. Activities and Tasks owns interactions and work that refer to those identities.

Today Platform owns authentication, security assignments, permission evaluation, and customer workspace access. It also owns metadata definitions, shared query execution, Explorer infrastructure, managed files, communication delivery, attention and responsibility infrastructure, durable work engines, and workspace lifecycle orchestration. CRM supplies definitions, data, operations, and participant functions to those systems. Hosting a CRM screen in the console does not change the owner of the information it administers.

The CRM architecture proposes stable read contracts and reference participation for other applications. Membership owns membership records and benefit entitlement; Accounting owns issued financial documents and their retention; Commerce owns orders and product entitlements; Committees owns appointments and governance; Submissions owns intake and review records. CRM coordination never authorizes it to rewrite those applications' records outside their owner-supplied functions.

Andrew decides that future person-to-person relationship tables and enrichment live in CRM, and that households are first-class CRM records. These are decided directions with unbuilt details, rather than additional implemented modules in the current division. Household membership coverage stays with Membership. Enrichment provider catalogue, credentials, gateway execution, and adapters stay with the Integration Platform even though CRM owns enrichment policy and evidence. The boundaries for future Submissions capture and the older CRM-specific import and lifecycle owner names still require reconciliation by their owners.

How the Area Is Divided

Today Entities provides the common record model. Open its Contact Records and Organization Records features for identity and hierarchy, Contact Details and Communication Preferences for contact channels, Affiliations and Roles for dated organizational connections, and Organization Compliance for the assessment of required responsibilities. Classification Types and CRM Settings explains customer configuration; Record Protection and History explains lifecycle safeguards and attribution. This module is the starting point when a question concerns what a person or organization record means.

Today Data Quality connects matching evidence to staff review and deliberate identity change. Its features distinguish locating and preventing duplicates, reviewing suspected identities, preparing a merge, executing a combination, and following absorbed identities. Open this module when the question concerns what evidence supports a combination, what the preview approves, which participant owns a reference change, or how an old identity remains explainable.

Today Regions owns the catalogue, geographic assignment policy, placement coordination, and recalculation. Open Regional Catalogue for the definitions, Geographic Assignment Policy for deciding addresses and ordered coverage, Record Placements for automatic and deliberate results, and Policy Recalculation for applying changed coverage to existing information. A placement question often crosses into Entities because that module owns the record on which the result is stored.

Today Activities and Tasks connects interaction records, timelines, task work, configuration, and workflow delegation. Open Interaction Records and Timelines for shared context, Activity Classification for the details a category collects, Managing Task Work for ownership and closing state, Task Configuration and Routing for queues and categories, and Workflow Delegation and Record Safeguards for service callers and lifecycle interactions. Task authority comes from Platform security, while the task's routing and state remain this module's concern.

Vision and Architectural Principles

The CRM architecture proposes a constituent foundation that answers who an association deals with and preserves that answer through change. Today the implemented record model already separates a person from an organization and stores dated affiliations between them. The architecture's motivation is continuity: an identity is referenced by many applications, so a correction or combination must be understandable beyond the screen where staff initiate it. The architecture record's evidence reports explain the operational failures behind this emphasis; their research and historical assessments remain in the records.

A Shared Owner for Behavior

The architecture proposes that every channel use the owning domain service: console, portal, import, bulk action, API, and another application's service call. Today the module responsibilities describe record persistence behind route handlers and shared work engines. The architectural direction puts business validation in the owner and supports it with database constraints where the condition can be expressed there. A form can help staff enter a valid change, but its presence cannot make an API or import safe.

The architecture records Andrew's reference-based affiliation decision. Today a contact's organizational context comes from affiliations, and organization-supplied addresses and phones can be resolved through links. This gives the model one source for a shared value and a dated record for the reason it is used. The same principle guides the household proposal: a shared mailing address can be linked explicitly, while the person's own address remains theirs.

Identity Changes Have Wider Consequences

Product decides that participating merge changes commit in one transaction. Andrew also decides that a merge must be blocked when an absorbed record has references in an application without a participant for that object type. Together these decisions put integrity ahead of an apparently successful CRM-only result. The merge coordinator assembles the change, but each application supplies the code and policy for its own references.

The architecture proposes a corresponding safe-delete contract. Archive preserves identity and references; deletion requires knowing what can be removed, retained, detached, redacted, or blocked. Today archive exists in the Entities contract, while cross-application safe delete remains deferred. Treating the future deletion design as today's protection would erase an important limit of the product.

Shared Infrastructure and Visible Results

Andrew's recorded console ruling calls for shared metadata-driven cards, actions, forms, field editors, history views, and Explorer recipes. The architecture uses Platform capabilities instead of giving CRM a parallel query engine or import framework. CRM's contributions remain domain-specific: meaningful datasets, record definitions, record operations, and remediation actions.

The architecture proposes that derived information either be computed live or have an explicit, proved freshness bound. Today regions, duplicates, search, compliance, and attention involve captured changes or background work with different boundaries. A committed contact edit does not establish that every projection is immediately current. The document therefore distinguishes the source record, the committed notification, delivery, and the resulting projection rather than describing them as one instantaneous action.

The architecture also proposes bounded work with progress and understandable outcomes. Large recalculations, merge operations, and data jobs need execution paths appropriate to their scale. A proposed performance target is not a measurement, and a durable job declaration is not proof of recovery after every interruption. The owning modules' findings remain the place for observed gaps in concurrency, settlement, and delivery.

Built, Decided, and Proposed

Today the four module contracts supply the implemented baseline in this document. The three architecture records supply motivations, proposals, and named rulings. Some parts use earlier assessments or retain recommendations that a later ruling changes. The reconciled architecture follows the explicit ruling where one exists and names the remaining uncertainty. It does not turn an internal architecture choice into Andrew's approval or turn an architecture diagram into a deployment claim.

Domain Model

Today the domain centers on two constituent identities: a contact is a person, and an organization is a non-person body. Their classifications help staff recognize the record and choose its presentation. Names, contact points, operational status, archive state, references, and record attribution describe different facets. Membership status, account balance, and governance service are supplied by the applications that own those facts rather than added as competing CRM identities.

Contacts and Organizations

Product decides that contact display names are computed from name parts and that writing a contact does not parse an incoming full name. The architecture explains the benefit: the stored parts and the displayed identity stay connected. It proposes name splitting as an import-mapping aid with staff preview, not as an alternative domain write behavior. Today the Entities contract covers contact identity, record numbers, classified information, communication choices, and customer-defined values.

Today organizations carry their identity, classification, contact details, and hierarchy. The hierarchy describes parentage, while affiliations describe which people are connected to the organization. The architecture proposes an ancestor relation suitable for queries, eligibility, and exports, with a maintained closure table or recursive view selected by measurement. A hierarchy read in one staff operation does not establish that every query consumer already supports hierarchical selection.

The architecture proposes organization email addresses and preferred organization phone behavior to make contact channels more consistent. These are additions to the architecture, not facts inferred from the existence of organization addresses. The classification and contact-detail capabilities remain the authoritative home for what is implemented and permitted.

Relationships Have Their Own Meaning

Today an affiliation records a person's dated connection to an organization, with a type, job title, and responsibilities. A primary affiliation expresses the person's principal organizational context without removing other current relationships. Role periods describe responsibilities within the connection. Organization-type compliance evaluates the required distribution of those responsibilities, while security roles remain a separate Platform concept.

For example, a society member can work for a member firm, teach at a university, and retain a past affiliation with a previous employer. Ending the previous employment does not require inventing a second person or replacing all organizational context. Today the Entities feature explains the current and historical relationship model; the architecture supplies the reason for keeping identity and relationship separate.

Today CRM retains an interim spouse reference. Andrew decides a future CRM-owned typed person-to-person relationship model. A household is another distinct concept under his ruling: the mailing and recognition unit, with dated membership and its own identity. Neither a relationship nor a household row is itself a membership benefit or a permission. The household chapters explain the decided direction and proposed mechanics without folding them into the current affiliation model.

Contact Details and Their Sources

Today the contact-information model distinguishes a person's own value, a copied value with source context, a linked organization value, and a disconnected value awaiting resolution. The architecture records the decision to preserve a removed source's last value as visibly disconnected rather than make it appear to be a live link. These states matter to a consultant configuring records: a corrected organization address can affect a linked person without changing a separately maintained home address.

The architecture proposes one validation path across channels and explicit operations for resolving contact details. It keeps seasonal address selection separate from preferred address selection and records Andrew's recurring month-and-day direction. Communication preferences describe the person's choices; they do not establish that every sender already enforces those choices. The communication contract and sending controls remain separate architectural work.

Work and Identity Evidence

Today an activity records an interaction with links to related contacts or organizations; one shared meeting need not be duplicated on each person's timeline. A task records work, its routing, due day, and closing attribution. These records use constituent identities without owning them. Their histories and deletion behavior are not identical, and the module findings preserve those differences.

Today duplicate candidates describe possible sameness. Merge plans describe a proposed combination. Attempts and retained outcomes describe execution, and aliases describe where an absorbed identity leads. None is interchangeable with a contact's operational status. The architecture treats detection as evidence for staff and merge as a deliberate identity transition with wider effects.

Storage Supports the Ownership Model

The CRM domain-model record documents workspace-scoped composite keys, references checked within CRM, forced row-level security, normalized text, versions, and transactions for records with owned collections. Today the domain objects and responsibilities describe these mechanisms at the pinned baseline. Andrew's identifier standard distinguishes immutable configuration strings from UUIDv7 record identities; the records also identify implementation exceptions, so this page does not claim universal compliance.

The architecture separates references within the owning schema from soft references across applications. A local foreign key can protect an affiliation's organization, but cannot establish Accounting's retention policy. Across owners, integrity requires the merge, deletion, and published-read contracts described later. The future enrichment model follows the same distinction: the claim, suggestion, and current value have separate records even when their owner is CRM.

Functional Architecture

Today CRM's functions are organized around identity, context, quality, geography, and work. The runtime service has more technical modules than the four product modules: configuration routes, duplicate detection, merge execution, data-job adapters, and lifecycle participation have their own deployment concerns. The product division follows responsibility for business facts rather than treating each function or table as a separate module.

Constituent Maintenance and Configuration

Today Entities brings identity, contact channels, affiliations, roles, compliance, and protection into the same record context. Product's affiliation decisions make a relationship the reason for organizational context and linked contact information. Classifications select applicable presentation and configuration. Platform owns custom-field definitions, forms, and layouts; CRM stores its record values and references the definitions that apply. Changing a presentation does not change who owns the record.

Today organization compliance is a distinct assessment based on configured role requirements. It can retain violations and prepare notices, while Platform owns message delivery. Andrew's recorded rulings require compliance to follow an organization-type change, preserve referential protection for roles used by configuration, and allow ordinary customer defaults to remain customer-editable. The architecture does not make an advisory compliance warning equivalent to a database prohibition on a second role holder; exclusive roles remain an open product choice.

The architecture proposes relationship-aware query properties and a small set of stable reads. These help other applications and staff ask business questions without reproducing CRM's internal joins. For an implementation consultant, “current contacts below this corporate parent” combines organizational hierarchy with effective affiliations; it is not simply a filter on a contact's stored employer field.

Geographic Context

Today Regions defines coverage and placement policy, while Entities stores the result on contacts and organizations. A deciding address may be a person's own detail or a value resolved through an affiliation. Committed relevant changes cause reconciliation, including reconsideration of linked contacts after an organization address changes. Saved policy and a requested recalculation have separate roles: policy defines the current choice; recalculation traverses the existing population to apply it.

Today deliberate overrides and record safeguards constrain that traversal. The responsibilities describe batch commits of placement and progress rather than one transaction over the entire workspace. They also record qualifications around policy snapshots, first writes, rule versions, and best-effort failure settlement. The architecture's resumable-work direction is therefore a design goal with specific observed limits, not a promise that a failed run always self-repairs.

Interaction Context and Follow-Up

Today Activities and Tasks records what staff discuss and what remains to do. Timelines combine interaction context and upcoming work around an owning contact or organization page. Activity categories determine the details collected and the outcomes available. Tasks separate the person assigned from a pool or role to which work is offered, and separate those routing facts from completion or cancellation.

Today a trusted workflow caller uses the task service contract instead of reproducing task persistence. The module describes activity and requested follow-up insertion in one transaction, while also retaining inconsistencies in the end-to-end feature. Queue claiming uses arbitration to admit a committed holder; discovering role-offered work depends on Platform's role-holder answer. Neither a queue responsibility nor a CRM contact role substitutes for task permission.

The architecture proposes integration-generated activities through an owner-supplied service function and richer shared list actions and history. Task revision history, assignment eligibility, and external workflow readiness remain unresolved in the current module record. These are visible boundaries for someone designing automation, especially when a workflow has succeeded in creating work but no eligible person has yet claimed it.

Data Quality as Evidence and Remediation

Today the duplicate service derives candidates from record changes, groups them for review, and retains staff dismissals. The merge service converts an authorized staff choice into a plan and outcome. The architecture proposes broader data-quality views for disconnected details, missing relationships, compliance violations, and incomplete customer-defined information. Each view leads to the capability that owns the correction; it does not establish a second generic rules engine.

That direction makes quality work explainable. A coordinator inspecting an old work phone needs the contact-detail resolution path; a reviewer inspecting repeated identities needs the duplicate and merge path; a regional administrator needs policy preview or recalculation. The architecture proposes saved queries and remediation actions that preserve those different causes and owners instead of collapsing them into an unexplained score.

Future Functions and Their Boundaries

Andrew decides the future household and enrichment ownership described in the topic chapters. Directories, engagement scoring, email types, exclusive roles, and some staff scoping remain product questions. The architecture proposes a directory projection that applies permitted fields and discoverability before page templates and an engagement design that recognizes inputs from multiple applications. These proposals do not establish a current directory or scoring product.

The portal direction is shared-owner work: Web Experience owns pages, Platform owns resolved authority, and CRM owns the data operations. Registration contact matching is a current narrow seam. General profile editing, organization roster administration, guardian action, and enrichment transparency need the corresponding contracts and pages. Andrew's portal-last ruling shapes their construction; it does not turn the proposed functions into built experiences.

Services, Contracts, and Ownership

Today CRM is a macroservice with separate API functions for entity work, configuration, regions, activities, tasks, duplicates, and merges, plus shared-work and service-only paths. Route handlers dispatch to domain services and persistence. The current product responsibilities name the operations and events exposed by each owner. This chapter explains their architectural relationship; the service contracts remain the precise operation catalogues.

Human Requests and Trusted Calls

Today customer requests enter through Platform identity and authorization, then encounter the CRM operation's record and state guards. The workspace context bounds the request. The console presents available actions, but the service decides whether a change is authorized and valid. Public health routes do not supply customer-record access.

Today trusted task invocation uses the calling service's cloud identity and function grant and is unavailable through ordinary HTTP. The service does not borrow a staff member's permissions merely because it creates work for them. Platform registration also has a narrow CRM contact matching and creation seam. These are specific contracts; they do not establish a general service interface for every CRM operation.

The architecture proposes published contact, organization, activity, and party-resolution services. Party resolution answers what an identity means now: live, archived, absorbed into a survivor, or deleted under a future deletion contract. It would let other applications resolve an old reference without copying the entire constituent record. Match-or-create is proposed as a shared entry path over duplicate policy, rather than separate matching logic for each form and importer.

Record Writes and Transactions

Andrew's recorded update ruling requires an ordinary write to change only named information, with explicit clearing where permitted and a separately named complete-replacement operation. His relationship ruling calls for explicit, permissioned, audited mutations within the owning aggregate. These decisions amend earlier replacement-oriented descriptions. Today Entities' findings still record missing complete replacement, stale no-op qualifications, and incomplete explicit relationship operations. The intended contract and the observed implementation must therefore remain separate.

Today the record owner handles owned collections and aggregate revision capture in its transaction. Stable owned-row identities support links and meaningful history. A correction to a phone is different from removal followed by addition. Product's concurrency direction binds a change to the client's expected version; refreshing a stale version silently would defeat the protection. The exact no-op and version behavior belongs in the capability rules and their test specifications.

The architecture records a compliance communication exception involving a request object outside the database transaction. Today the responsibilities distinguish acceptance of a notice from Platform delivery and communication outcomes. This is why an organization compliance state, a prepared notice, and a delivered email are different pieces of evidence.

Reference Owners Participate

Product's merge design calls application-owned participant functions inside the merge transaction. Each participant plans and applies its own reference changes. CRM can combine constituent identity without gaining ownership of a posted invoice, committee vote, or membership record. A participant can preserve historical identity or raise a blocker rather than rewrite an immutable business record.

The proposed safe-delete coordinator reuses Platform lifecycle participation. Its subject hold, impact answers, application order, and audit are described in the lifecycle chapter. A service that has no declared reference answer is a coverage problem, not permission to assume it holds nothing. The architecture proposes explicit registries and coverage checks so the boundary can be inspected before destructive work.

Captured Changes and Business Events

Today the responsibilities describe committed contact and organization change streams and local handlers for duplicates, regions, compliance, history, and projections. Data Quality declares a committed contact-merge business event. These local change streams and externally published business events have different roles. The former support named processing of committed changes; the latter provide a subscription contract for application workflows and integrations.

The architecture proposes contact and organization lifecycle events containing identities and changed field names rather than personal values. It also proposes invoking Membership's change handling for affiliation and role effects. Those proposed integrations are not a claim that every external consumer is registered or deployed. Today overdue-work and compliance attention publication have activation switches and readiness qualifications recorded by the modules.

Shared Execution and Future Enrichment

Today Platform's work engines supply durable execution, job monitoring, imported-file controls, and lifecycle coordination. CRM registers its operations and participant behavior. The architecture proposes admission, limits, progress, and explicit recovery appropriate to large workloads. Each owner retains responsibility for its own failure settlement; a shared queue does not erase a module's stuck-run finding.

Andrew's enrichment ruling places requests, claims, suggestions, suppressions, provenance, and allowances inside CRM. Provider calls still cross to the Integration Platform gateway using trusted service invocation. Accepted suggestions use the local CRM write path in the same transaction as their applied state. This decided ownership removes the originally proposed cross-service apply seam but preserves Platform ownership of credentials, execution records, and provider adapters.

Duplicate Evidence and Merge Integrity

Today Data Quality separates the evidence that two records may represent one identity from the decision and execution that combine them. The duplicate service owns comparison keys, candidate pairs, groups, dismissals, and configuration. The merge service owns previews, staff choices, attempts, retained outcomes, and aliases. Entities still owns the constituent records. This division lets staff resolve a false match without changing identity and initiate a reviewed merge without depending on the detector to find the pair first.

Deterministic Evidence and Human Review

Product's merge and duplicate design uses deterministic matching rather than a learned model. The architecture describes normalized email, phone, name, and postal keys, bounded candidate generation, similarity and nickname comparison, and explanations of matched information. Today the module supplies scores and evidence that reviewers can inspect. A high band is evidence to assess, not an automatic instruction to combine people.

Today committed record changes maintain duplicate evidence, and a background recheck can revisit a record type. The architecture records Andrew's direction to retire evidence that no longer supports a suggestion while preserving independent matching reasons. It also records attributed, reversible dismissals and ordinary creation blocking with a separate, reasoned override for an authorized caller. The current capabilities define exactly which entry paths and exception records enforce that behavior.

Consider two association contacts named Maria Lopez. One uses the professional address associated with a member firm; the other shares a postal location but has different personal information. The duplicate explanation allows a reviewer to decide whether the repeated name is meaningful. A dismissal preserves that staff judgment; it does not delete either contact. If staff instead establish that the records represent the same member, the merge preview is the next architectural boundary.

Preview Is Approval of Particular Information

Today a merge plan recommends a survivor and allows decisions about fields and collections. The architecture records a preview and execution built from the same planning behavior. Product decides that approval binds the identities and versions of dependent children, not just their counts. Two tasks before and two tasks after a preview can still be different work. A changed source value or transferred child therefore affects what staff approve.

Today the module describes plan freshness checks and revalidation. The architecture calls for readable winning, losing, and filled values, absorbed originals, participant actions, blockers, and warnings. A meaningful preview explains the consequences of choosing the sparse contact as survivor rather than merely showing a total number of moved references. The capabilities remain the authoritative home for collection combination and field choices, including the product decision to preserve the most restrictive communication consent.

Organization combinations are wider than contact scalar changes. The architecture describes transfer of affiliations and preparation of hierarchy, with bounded scale and a background execution warning. Today the merge responsibilities distinguish ordinary survivor saves through Entities from merge-owned reference and relationship preparation. A planner must consider the actual owned and participant data that the combination changes.

Atomic Execution and Owner Policy

Product decides that all participating database changes in a merge commit together or roll back together. Today the merge engine encloses its participant work in one transaction. An application-owned function controls its own schema's changes, so atomic coordination does not erase business ownership. An issued invoice can retain its historical party identity while readers follow an alias; a current appointment can require a specific resolution before it can move.

Andrew decides that missing participation blocks a merge only when the records being absorbed have relevant references. Unreferenced records can still be combined. The plan explains the application and affected counts, and the ruling offers no override. This corrects earlier parts of the CRM record that still describe the block as conditional on a future decision. The current module's reference coverage and findings determine what participation is observed; this document does not assert that every other application has completed its participant.

Product's login decision also distinguishes one linked portal account from competing accounts. The participant can transfer a single identity to the survivor, while multiple active logins require resolution. Platform owns that identity change and its security audit. A staff merge permission does not authorize CRM to invent an account-combination policy.

Aliases, Attribution, and Recovery

Today retained merge outcomes connect the original records, the survivor, and aliases for absorbed identities. The architecture records the product direction for gone responses with survivor context and readable merged-from history. A colleague opening an old record link should be able to understand the identity change rather than conclude that the member disappeared. Today the authorization model distinguishes retained merge outcomes from narrower record-scoped inspection, so visibility follows the applicable authority.

Today failure handling has important qualifications. The responsibilities describe a rolled-back execution claim that remains queued until separate failure settlement, and caught failures that normally become failed attempts rather than automatic business retries. The architecture's broader interrupted-job recovery description is not a verified promise for every current path. Operators need the owning job and merge outcomes to establish whether work committed, failed, or still needs settlement.

The architecture does not propose an unmerge that reverses arbitrary later business work. It proposes a future assisted recreation from retained originals, followed by ordinary owner-controlled edits to references. Today deleting a survivor can also leave an alias destination absent, as the module records. An alias preserves an identity route; it does not independently make the destination immortal or solve the deferred safe-delete problem.

Lifecycles, Safeguards, and Safe Deletion

Today record status, archive, customer locking, system protection, merge, and hard deletion represent different decisions. An operational status describes the person or organization's condition. Archive sets a record aside while retaining its identity. A lock constrains changes; system protection preserves required records. A merge absorbs identity into a survivor. Hard deletion removes the owning record and requires a different account of its consequences.

Status and Archive Preserve Context Differently

Andrew decides that archive is separate from operational status and never means deletion. Today Entities exposes archive and unarchive with reasons and attribution, and retains historical records. A deceased contact can also be archived; a closed organization can remain named by a past affiliation. These combinations preserve business meaning without using one overloaded state to describe death, inactivity, storage, and removal.

The architecture records a common discoverability direction for default lists, search, and new-choice pickers, while existing references remain readable. It calls for archived held values to remain understandable and for new-reference checks to use the same model across services. Today the current capability and service contracts establish the precise lifecycle refusals and exceptions. They do not prove that every external application has adopted the reference checks.

For example, a trade association closes a former corporate member's operating record but needs to explain which people worked there during the previous term. Archive supplies a retained identity for those affiliations. Deleting that identity is a different operation with different risks. The architecture's reason for preserving the distinction is that historical use and new operational use have different needs.

Locks, Protection, and Version Preconditions

Andrew's recorded rulings distinguish customer locks from protected system records. Ordinary default classifications remain configurable; protection applies to a record whose continued existence supports a Platform invariant. Lock transitions require restricted, audited actions, and ordered-list movement is not treated as editing the protected substance of a record.

Today Entities provides dedicated record lock operations and attribution, but the current responsibilities preserve qualifications for legacy contact-role saves and ordinary-lock paths elsewhere. Regions records that its definitions have not adopted the same history and audited-lock facilities. The area cannot promise uniform protection merely because records carry similar system fields.

Product's write direction also makes record versions meaningful preconditions. A staff draft or background plan is based on particular data. Changing the version to the newest value without reconsidering the draft would defeat that relationship. Today exact stale-write, no-op, archive, and merge-busy behavior remains in the relevant capability; the architecture explains why these safeguards belong in persistence rather than only in the screen.

Disconnected Contact Information

Andrew decides that a removed linked source leaves a visibly disconnected last-known value needing resolution. Today Entities exposes verification, relinking, and removal for disconnected addresses and phones. This is a lifecycle of the contact detail, not the same thing as archiving the person or closing an affiliation.

The architecture leaves a separate question about whether an ended affiliation must disconnect its links and another about excluding disconnected details from mailings. A value can retain useful evidence without being represented as currently verified. The eventual mailing policy needs a product answer; this composition does not silently choose one. The household design proposes corresponding disconnection when a member leaves or a shared household source is removed.

Current Delete and the Deferred Contract

Andrew explicitly decides to keep current API and console bulk-delete behavior until cross-application safe delete ships. That ruling closes the earlier proposal to hide or restrict the delete path in the interim. Today the module records local retention and reference consequences; Activities and Tasks can retain interactions while their related-record links disappear. Cross-application protection is not established by that local behavior.

The architecture records the release consequence of the deferral: acceptance of the current build is distinct from readiness for customers who hard-delete constituent records with business references. The future safeguards below are a proposed contract shaped by Andrew's retention and activity rulings. They are not protections a consultant can assume are operating today.

Proposed Deletion Impact and Approval

The lifecycle architecture proposes that Platform ask each enabled participant what a deletion does to its references. The answer distinguishes five dispositions:

Proposed Disposition	Architectural Meaning	Example in the Record
Block	The subject cannot be removed while an unresolved dependency holds.	An open invoice, current seat, or portal login.
Retain	The owner keeps its business record and historical identity under a retention policy.	A paid invoice or cast vote.
Detach	The record survives with a deletion tombstone replacing live context.	A task's related contact or an activity link.
Redact	The owner retains its record while removing specifically named personal content.	Free text under an erasure policy where permitted.
Delete	The owner removes information that exists only for the subject and has no retention obligation.	Owned contact details or a search document.

The proposed flow starts with a readable impact preview and approval bound to subject and dependency identities and versions. Execution rechecks the plan, holds the subject against further writes, applies owner dispositions in dependency order, and removes the owner's record last. A missing reference declaration fails closed rather than supplying an empty answer. Bulk removal uses the same contract rather than a less protected path.

Andrew's recorded financial-retention ruling means a CRM deletion does not authorize erasure of regulated financial or governance history. His activity ruling means an interaction is not reassigned to the deleted person's employer and is not removed solely because its last live contact link disappears. The proposal makes that activity discoverable as orphaned work with a tombstone; explicit erasure policy controls content redaction.

Andrew's deletion-audit ruling calls for a result containing operation metadata and participant outcomes without the removed person's personal content. The proposal also redacts CRM revisions under the deletion policy. Who approves, retention duration, permitted free-text redaction, and related lifecycle defaults remain questions for the deferred design. The area page preserves the questions instead of establishing new capability rules for an unbuilt feature.

Console and Portal Experience

Today the console hosts CRM pages whose ownership follows their records: contacts and organizations, duplicate review and merge, regional configuration, interactions, and task work. The architecture combines these surfaces around constituent context and uses Platform's shared presentation systems. It proposes that staff can discover a record, understand it, perform an authorized action, and inspect the result without encountering sample data or inert controls in live operation.

Discovery and Lists

The architecture records Platform ownership of Quick Search, datasets, query compilation and execution, saved queries, exports, and Explorer infrastructure. CRM contributes meaningful record definitions, field descriptions, recipes, and permitted actions. Today the module contracts describe registered views and hosted lists. Quick Search's result freshness and an Explorer query's completeness remain different verification questions.

Andrew's search ruling requires committed changes to reach search without resurrecting removed identities or allowing one customer's bulk work to stall another's indexing. The architecture proposes a freshness bound; it does not provide a measurement at this job's pins. Earlier console assessments in the record remain evidence behind the proposal, not a current test result reproduced here.

Andrew's query rulings preserve grouped and negated criteria when a saved query is opened and require natural-language query changes to explain their effects and support undo. Relationship-aware criteria belong in the shared semantic query designer rather than a CRM-only filter implementation. The architecture proposes recipes for constituents, organizational relationships, role holders, work, and remediation. A consultant needs the query's business meaning preserved when moving between list and query views.

The Record Page as a Composition

The architecture records Andrew's direction to compose record pages from shared cards and actions. Contact identity and CRM context come from CRM; membership, finance, commerce, governance, and other application cards come from their owners. An application's licensing and live capability determine whether its contributed card belongs on the page. A visible tab is not evidence that CRM owns or has implemented the underlying business process.

The proposed contact page makes status, communication cautions, primary organizational context, preferred channels, archive state, duplicates, and merged history understandable. Affiliations are shown with their effective current, upcoming, or past context. Interactions, tasks, custom fields, region, and history remain connected to the record. The organization page uses the same architectural system for hierarchy, related contacts, compliance, and channels rather than requiring a separate presentation framework.

The architecture proposes independent card loading and distinct empty, error, and permission states. A failure to load a finance card should not erase the constituent header or imply that the contact has no invoices. That resilience is a proposed experience requirement. Current screen contracts and their findings determine what the examined console actually does.

Editing and Results

Product's recorded directions use type-selected forms, live reference data, server-backed pickers, retained dirty drafts after session expiry, and explicit handling of conflicts. The architecture explains why pickers should not preload an entire enterprise population. A coordinator adding an organization relationship needs a current, authorized choice, not a truncated in-browser catalogue whose absence looks like proof that the organization does not exist.

Today the modules describe record pages, configuration editors, drawers, duplicate-block refusal, merge workspaces, and regional preview. Their service and screen qualifications are retained here instead of copying older statements such as “no archive exists” from a record written at an earlier baseline. The architecture's visible actions are target directions; this job does not claim a live crawler or browser acceptance run proves every one.

Andrew's live-console ruling uses one product-wide live or mock mode and removes sample-backed or nonfunctional actions from live experiences. Print Profile and Alerts remain hidden until designed, with their future evaluation assigned to shared presentation and attention systems. His ruling is broader than simply changing a label or disabling a button: staff must be able to trust that a visible operation has a real effect.

Portal Authority and the Narrow Current Seam

Today the established portal seam is registration contact matching and login coordination with Platform. CRM's authorization model does not give the built-in Portal Member role blanket CRM access. A route declaration supporting portal reads still requires its declared authority. The record's broader portal profile and organization-roster experience remains a proposed contract and presentation design.

The architecture assigns pages to Web Experience, resolved identity and grants to Platform Security, and record validation to CRM. Organizational roles may supply facts to a published derivation, but they are not security permissions in themselves. Andrew's portal-last decision shapes the sequence without changing those ownership boundaries.

The household proposal extends this approach with distinct manager, guardian, and authorized-representative grants. The enrichment proposal extends it with transparency and suppression controls, still subject to an open member-control decision and permitted field display. Both depend on the same separation: a person's business relationship describes context; a security assignment establishes authority; the owner checks the requested operation.

Data Operations

Today CRM supplies operations to Platform's Data Job Engine rather than owning an independent import framework. The architecture uses this shared path for external files, upserts, selected bulk changes, migration, and integration batches. Platform supplies admission, uploads, execution controls, progress, results, and the console wizard. CRM retains responsibility for the records the operation creates or changes.

Validation and Application

The architecture proposes that validation and application run the same owning behavior, with validation using a rolled-back transaction. Today the record documents registered contact, organization, classification, and activity operations and source-key crosswalks. The module responsibilities also describe region imports behind hosted routes with Platform execution. These registrations establish boundaries; they do not imply identical validation and rollback coverage for every operation.

Andrew's recorded data-job rulings require versions captured at validation to be checked at application, patch source revisions to be respected, and conflicts to be named rather than silently overwrite newer work. Dependency-ordered atomic import groups must either resolve their relationships or produce actionable errors. The architecture assigns those shared behaviors to the engine's owner, with CRM supplying operations. It does not resolve a shared-engine gap by inventing a CRM-only implementation.

For example, an importer receives a corporate roster with new organizations and affiliated contacts. Source keys establish which incoming records refer to each other. Creating the organizations, people, and relationships in a planned dependency order differs from guessing an organization by its display name. The architecture's proposed error path preserves uncertainty when two organizations match rather than quietly choosing one.

Mapping Business Information

Andrew's typed-column ruling makes ordinary association spreadsheets useful for preferred email, phone, and address data, including several values per row. His untyped-column ruling uses explicitly configured defaults with visible resolution; an absent default is not permission to invent a new classification. Email type choices must correspond to the actual model, which remains an open product choice.

The architecture proposes a mapper that can split a full-name column for preview, translate fixed legacy contact slots into the typed model, and use source keys for affiliations and roles. The domain owner still supplies validation. This keeps a spreadsheet convenience from becoming a competing definition of contact identity or a different relationship rule.

Today the architecture and responsibilities distinguish a source-key crosswalk from a CRM record number. The former connects imported identities to their source; the latter belongs to CRM. That distinction is useful when a consultant repeats an import, changes a source file, or needs to trace the job that introduced a record. It avoids treating an external row label as the authority for the association's internal identity.

Bulk Changes, Cancellation, and Receipts

Today selected work enters a shared wizard and owning operations. The architecture records separate bulk authority and operation authority, explicit confirmation for irreversible deletion, and per-item outcomes. Andrew's cancellation ruling requires prompt acknowledgement while committed counts settle, rather than representing unknown committed work as zero. His upload ruling requires checksum verification inside the processing job regardless of file size.

The architecture proposes result totals that account for each input row and give staff a reason for a skipped or failed item. It also records job attribution in revisions with a readable label and link. A successful job start does not establish that every row applied, and cancellation does not roll back earlier committed batches. The exact engine controls and CRM operation outcomes remain with their owning contracts.

Rollback Has a Different Boundary from Delete

Product's rollback direction restores changes only where subsequent work does not conflict. The architecture records partial contact rollback at its source baseline and proposes broader restoration for stable owned collections and custom-field values, including organizations. It explicitly keeps merge and hard deletion outside ordinary data-job rollback. This document does not claim broader coverage from the presence of a Rollback button.

An association can import a job title and later correct the person's record manually. A safe rollback needs to distinguish the import's contribution from the later correction. The architecture's reason for version and outcome tracking is to preserve that work. If the owning operation cannot reverse a collection change, the result must make that boundary visible rather than restore only some information without explanation.

Exports and External Sources

Today CRM supplies export datasets and participant data, while Platform owns export orchestration and query-based export. The architecture separates a list export from a complete workspace export and proposes compatible descriptions for references that have merged or been deleted. A CRM dataset provider alone is not proof that a complete workspace export runs at the pinned environment.

The household design proposes household, member, and relationship operations and crosswalks when implementation is authorized. The enrichment design adds another distinction: fetching provider evidence is queued durable work, while bulk application uses owning data operations. A licensed provider field requires an export-use decision even after staff accept it into CRM. The security and enrichment chapters explain why an ordinary query export cannot be assumed to remove that restriction.

Security, Audit, and Privacy

Today Platform evaluates identity, grants, application access, and workspace authority; CRM then checks the operation and the target's state. The CRM authorization model is the current catalogue of permissions and consuming surfaces. Actors describe staff responsibilities, and contact roles describe organizational responsibilities. Neither actor labels nor affiliation roles independently confer security authority.

Workspace and Role Boundaries

Today ordinary CRM authority is workspace-scoped, with customer-wide assignments resolved through Platform where applicable. Record reach supplies additional checks for specified history and merge reads. Regions, affiliation roles, and task queues organize customer records and work; the CRM model does not establish an organizational-unit permission scope simply because one of those concepts exists.

Today the authorization model projects Platform's shipped roles onto CRM's permission tiers and allows customer-composed policies. Applicable denies and scope remain part of the evaluated answer. The architecture's proposed Contacts Editor and Data Steward policies are future directions rather than additional built-in CRM roles. Record-level staff scoping and sensitive-field permission support remain open product and Platform design work.

Today the model also records bounded authorization freshness, so changing an assignment is not a demonstrated instant refusal at every cached gateway. CRM consumes Platform's propagation contract. The same care is needed in future guardian and manager revocation: a derivation change and the effective authorization response are distinct mechanisms that require the owner's contract.

Permissions and Business Guards

Today merge access, duplicate-block exceptions, locking, queue and role claims, recalculation, and settings have specific permission and guard combinations. An authorized caller may still encounter a stale version, held record, protection, invalid state, or ineligible relationship. The authorization model points to capability guards instead of defining their rules again.

Andrew's recorded access rulings reserve customer-access approval to security administrators and require a reusable explanation of effective grants, policy sources, scope, and entitlement. Today Rhythm staff enter customer work through Platform's explicit customer-access mechanisms; an HQ role alone does not authorize console operations. Trusted service invocation is another boundary, not a way to inherit unrestricted customer authority.

Four Different Records of Change

Today aggregate revision history, merge outcomes, Platform audit, and communication outcomes answer different questions. Revisions explain what changed on a record and who or what changed it. A merge outcome retains original constituent information, choices, and participant results. Platform audit explains security and operation events. A delivery outcome explains whether a prepared communication actually reached its recipient.

Today Entities describes contact and organization revisions, and Activities and Tasks describes activity history while retaining a task-history gap. Classification records and regional definitions do not uniformly share those facilities. The architecture proposes broader history coverage and readable references when associated information is renamed or archived. That target is not a claim that every configuration edit already has equivalent revision detail.

Andrew's recorded history rulings require meaningful actor and reference labels, job-linked attribution, actual owned-row changes rather than misleading replacement, and readable merge detail for permitted readers. Privacy constraints still apply to retained personal snapshots. The deferred deletion design needs a separate redaction and tombstone policy; retaining history cannot itself settle an erasure request.

Privacy and Communication Boundaries

The architecture classifies contact details and personal relationship data as information requiring protection. Today CRM stores communication preferences and operational flags; Platform supplies sending. The architecture proposes that delivery honor the constituent's choices and deceased state rather than infer permission from a populated email address. A stored preference and an enforced send gate remain distinct evidence.

The proposed household model protects adults' separate identities and keeps consent per person. The enrichment model controls outgoing lookup disclosures, provider licenses, field display, and suppression. These topic designs do not establish current field-level security or a completed consent ledger. Their open decisions and provider-specific confirmations remain visible later in the document.

Operations and Verification Limits

The architecture proposes structured operational context without personal payloads, measured projection freshness, durable progress, and visible dead-letter outcomes. Today the modules record activation switches, stuck-run risks, and incomplete delivery or refusal-audit coverage. Those qualifications matter to operators: a captured event is evidence of commitment, while delivery and successful handling need their own result.

The architecture record also names dated compliance exceptions and administrative settings at its research baseline. This job does not inspect those external settings or claim that an exception remains active, expired, or resolved at the pinned service revision. The responsible milestone record and control evidence must establish the current answer. The proposed operational architecture and the current coverage findings are kept apart.

Cross-Application Contracts

The CRM architecture organizes cross-application integrity around published reads, merge participation, and the proposed deletion-impact contract. Today CRM owns constituent identity; every application owns its business records. The architecture records the standing rule that physical cross-schema reads remain allowed, while only an owner writes its tables. It proposes a compatibility promise for published views and service functions so consumers can avoid depending on physical layout.

Published Reads and Events

The architecture proposes stable answers for names, effective addresses, current affiliations, and discoverability. Consumers can then ask for the information they need without keeping a competing copy. That is especially useful for a billing display or event recipient: the consumer needs a current readable identity without becoming the owner of contact naming or address-link resolution.

The architecture also proposes published lifecycle events with record identities and changed field names. Those events notify consumers and automation; they do not replace synchronous integrity for merge reference changes. Internal captured-change handlers can refresh projections or re-evaluate derived work, but a promised compatibility contract needs explicit ownership and publication.

Today the responsibilities establish local handlers and declared external seams. The architecture record's evidence reports show direct physical reads, incomplete participants, and unwired ports at their research baselines. Those reports remain evidence behind this page. The composition does not reproduce their column-by-column assessment as if it were a new inventory of every application today.

Business Records Keep Their Owners

The architecture proposes Membership participation for ownership, applications, rosters, and snapshots, plus affiliation-driven changes to derived memberships. Membership decides how overlapping membership records consolidate; CRM does not decide entitlement during a merge. Its future beneficiary design likewise consumes CRM facts while keeping the coverage rule and recorded benefit basis in Membership.

The architecture proposes Accounting participation that preserves issued financial identity and handles unresolved receivables under Accounting policy. Commerce handles open checkout, placed order, and active entitlement differently. Committees handles appointments and governance history; Submissions handles open work and retained review decisions. These owner examples explain why one universal “replace every identity everywhere” operation would be insufficient.

Andrew's merge-block ruling governs unimplemented participation. CRM's plan can explain that an application holds references it cannot yet handle. Shipping that application's participant lifts the relevant gap; CRM does not assume that another application's inactivity in the delivery focus means it has no records or references.

Identity, Work, and Presentation Handoffs

Today Platform supplies portal account linking and merge-time login participation. Activities and Tasks receives workflow delegation through its own task service. Queries and search receive registered CRM data and committed changes. Communications receives requests whose acceptance and delivery have different records. Attention and Responsibilities route work based on their shared infrastructure and CRM's declarations.

The architecture proposes other applications contributing their own record-page cards. A constituent page can give staff a combined view while preserving these handoffs. Reading an invoice card on a contact page does not authorize CRM to change the invoice or turn the card into a second finance specification.

Future Household and Enrichment Handoffs

Andrew decides that a household may hold a membership in programs that allow it, and that Commerce recipient and entitlement-holder vocabulary gains the household case. The household remains outside financial party vocabulary: buyer, bill-to, payment owner, and Accounting party remain a person or organization. The original household appendices retain a narrower recommendation in some tables; the explicit holder ruling changes those tables' interpretation.

Andrew decides that enrichment is CRM-owned but calls ordinary Integration Platform adapters. A future non-CRM enriched record needs an owner-supplied service seam; it is not permission for CRM to write arbitrary application records. Household recognition, audience selection, guardian registration, and provider-derived information all require explicit consumers. Their topic chapters describe proposed contracts without assigning the other applications' detailed business rules to this area.

Households and Constituent Relationships

A Decided Direction with a Deferred Delivery Gate

Andrew decides that household identity and typed person-to-person relationships belong in CRM. He also defers household delivery until a signed customer requires it. Those are separate decisions: the ownership and model direction are established, while the architecture described here remains a proposal for a future delivery. Today the area’s four module charters do not establish a shipped household module, household editor, guardian derivation, or household membership holder.

The household architecture addresses a different question from an organization affiliation. An affiliation explains how a person relates to an organization. A household explains an explicitly maintained domestic grouping, shared contact arrangements, naming, and administrative context. A personal relationship explains a connection between two people, whether or not they live together. The architecture proposes keeping these three concepts separate so that one cannot silently substitute for another.

For example, a museum may know that Elena and Marcus share a household, that Elena is guardian of Maya, and that Marcus works for a sponsoring company. A household address helps send one letter. The guardian relationship may support a narrowly defined authorization process. The affiliation supports corporate contact work. None of those facts alone establishes who receives membership benefits, who pays an invoice, or who may edit another adult’s record.

The architecture record originally considers households represented by an organization classification and relationships implemented through Platform associations. Andrew’s later rulings select a first-class, deliberately narrow household and CRM-owned person relationships instead. The area follows those rulings. Generic organization relationships and customer-defined object relationships continue to belong to Platform’s association facilities; CRM’s exception does not transfer all association ownership.

Household Identity and Composition

The architecture proposes a household identity with its own type, status, naming configuration, shared contact information, custom fields, and dated membership rows. Andrew explicitly approves household custom fields and membership in several households. A contact’s designated primary household supplies a deliberate default for consumers that need one grouping; it does not erase other household memberships.

The household’s primary contact and a contact’s primary household answer different questions. The first identifies a contact within one household for administration and the proposed billing default. The second identifies one household among a person’s several groupings. Neither replaces the primary organization affiliation that existing CRM maintains. A consumer must choose the relevant relationship rather than use a generic “primary” flag without context.

The proposed member row records role, effective period, naming participation, managerial eligibility, and primary designation. These are independent facets. A child can be a member without being an administrator. An adult can remain in a household without appearing in its public recognition name. A former member remains in dated history after departure. The architecture proposes changes that close or adjust membership periods instead of rewriting the household’s entire past composition.

The proposed model allows empty households at the service boundary, supporting staged imports and explicit administration, while the proposed console creation recipe begins with a member. Those are interface choices rather than competing definitions of a household. The record’s proposed member limits are safeguards to validate in implementation, not evidence that the existing area enforces a household size limit.

Relationships with Meaning and Periods

Andrew selects CRM-owned relationship types and contact relationships. The architecture proposes types that declare symmetry or direction, labels for either endpoint, a stable system meaning where one exists, and whether a relationship can contribute to access derivation. A symmetric connection such as spouse or partner represents one relationship rather than two independently editable assertions. A directed connection such as guardian and dependent has distinguishable endpoints and labels.

The architecture proposes canonical storage for symmetric pairs, dated validity, and prevention of self-relationships and conflicting overlaps. It also proposes history visible from both contacts and merge handling that reassigns endpoints, consolidates equivalent connections, and reports relationships that would collapse into self-links. These safeguards are proposed business behavior; their precise validation and operation rules need their own capability homes when delivery is authorized.

A relationship type that contributes to access is materially different from a decorative label. The architecture proposes limiting the access-authorizing meaning to defined semantics and appropriate authority. A customer changing a display label should not manufacture guardianship. Conversely, not every useful relationship needs an access consequence: former classmates, professional mentors, and emergency contacts may provide context without any permission to act.

The record proposes converting existing spouse information into relationship evidence and reporting inconsistent or one-sided legacy links for review. That proposal does not make an incomplete historical link authoritative. Migration must distinguish an established relationship, a candidate needing reconciliation, and an unknown effective period. The deferred delivery gate also means this page does not promise that such a conversion has run.

Names and Shared Contact Information

Andrew decides that household naming uses closed formats with separately maintained computed values and explicit overrides. The architecture proposes family-name, member-name, and primary-contact formats, with configurable presentation such as connectors and suffixes. Its four name and salutation outputs support different correspondence uses rather than one universal string.

Under the proposed design, changes to member names, composition, naming participation, or relevant life status recompute derived strings. An override remains in force until a user clears it; the newly computed alternative remains available for review. This makes a household’s preferred addressee stable without losing the ability to restore computation after a family change. The service computes names at changes rather than relying on every reader to reproduce the formula.

The architecture proposes household-owned shared addresses and explicit links to participating contacts. A linked contact can retain the source relationship to the household address; a local edit can detach the link deliberately. Ending household membership disconnects applicable shared links without silently deleting the person’s retained contact information. Shared phones likewise need explicit linkage and ownership choices rather than an assumption that every contact field inherits.

Andrew’s model does not create inherited email identity or inherited communication consent. Two adults sharing an address still have separate login identities and consent decisions. A household mailing name cannot authorize disclosure to every member, and a primary contact cannot opt another adult into a campaign merely by being primary. Marketing must select recipients through its own eligibility and consent policy.

Lifecycle and Exceptional Change

The architecture proposes explicit operations for joining, leaving, changing primary designation, dissolving, reinstating, archiving, and combining households. A departure changes current composition but preserves dated membership and history. Changing the primary contact requires a coherent successor where one is required, so a multi-step user workflow does not leave downstream consumers with an unexplained gap.

Dissolution is more than archiving. The proposed operation closes active memberships, disconnects shared links, freezes appropriate names, and preserves historical identity. Reinstitution is selective: only eligible, nonconflicting memberships and links return. Archiving instead sets the household aside without asserting that every family relationship or membership ends. Person-to-person relationships remain independent of household dissolution.

Andrew’s household-holder ruling adds a further consequence: a household with memberships it holds cannot be dissolved as though only CRM rows exist. Membership must transfer or end those holdings according to its own operations. CRM presents the impact and coordinates the necessary handoff; it does not invent Membership’s transfer policy.

The architecture proposes death handling that retains historical membership, removes the person from relevant computed names, ends applicable derived access, and identifies a replacement primary contact where needed. It does not propose deleting the deceased person’s financial or participation history. Separation likewise requires deliberate household and relationship changes rather than a global inference that all shared relationships end together.

A future household merge combines household identity; a contact merge combines people. They need distinct plans and safeguards. The household design recommends warning when a contact merge brings together different household contexts, rather than refusing every such merge. Conflicting membership periods, primary selections, shared links, and names still need a reviewed plan. Andrew’s existing cross-application merge block remains the safeguard until owners can handle the references.

Console, Reporting, and Consumer Boundaries

The proposed console makes a household a navigable record with composition, names, shared channels, custom fields, and history. A contact page presents personal relationships as a meaningful card and a focused editor. This is not a proposal to regenerate existing contact pages wholesale. Other applications contribute their own household-related cards without making CRM the owner of the displayed membership or gift.

The architecture proposes household imports as dependency-aware data operations: contacts and households need stable crosswalks before membership rows or relationships can resolve. This uses shared import infrastructure rather than introducing a household-specific import engine. Export and reporting need an explicit grain. Counting members across all households differs from counting contacts once by primary household, especially when a person participates in several households.

Fundraising’s proposed recognition uses household composition at the gift’s relevant date and preserves the gift’s recorded credit basis. It must avoid counting both a gift and its associated recognition credits as separate money. Marketing’s proposed householding chooses an eligible recipient and applicable consent; it does not treat a household as a consent subject. Events’ proposed family registration distinguishes buyer, attendee, guardian, and beneficiary. Mobile membership cards identify the person entitled to enter rather than turning a family name into an admission credential.

These consumer contracts are not delivered solely by creating a household table. Each owner must implement its participation, and portal use remains a later controlled surface. Andrew’s signed-customer gate preserves that distinction: a coherent approved direction can remain deferred without claiming that its dependent experiences exist today.

Membership Coverage and Delegated Family Access

A Holder Is Different from a Beneficiary

Andrew decides that a household may hold a membership when the membership program permits it. This changes the record’s original recommendation that only contacts and organizations hold memberships. The standing decision also adds household recipient and entitlement-holder cases in Commerce, while retaining people and organizations as the financial parties used for buying, billing, and payment. A household’s billing contact defaults to its primary contact under the proposed implementation; renewal notices use that person, and automatic renewal follows the payer’s authority.

A membership holder and an entitled person are different subjects. The household is not itself a person who enters a museum or attends a program. Membership owns explicit beneficiaries and the basis of each benefit. A household membership can therefore support a family product without an implicit rule that every person ever listed in CRM automatically receives every entitlement.

The architecture proposes designated beneficiaries and derived coverage as distinct mechanisms. A package can permit staff to designate a capped number of beneficiaries, derive beneficiaries from qualifying household or affiliation facts, or combine these mechanisms according to its rules. Membership owns caps, dependent ages, additional-seat benefits, and whether a child membership or a direct entitlement represents coverage. CRM supplies composition and relationships; it does not decide a membership package’s eligibility.

Consider a science center’s family membership held by the Rivera household. The package may admit two designated adults and children who satisfy its age and relationship conditions. A visiting grandparent can be a recorded household member without consuming an adult seat automatically. Conversely, a separately designated beneficiary can have a recorded entitlement without becoming part of CRM’s household. The example illustrates the proposed separation; the package’s actual eligibility and pricing rules remain Membership’s responsibility.

Recorded Grounds and Recalculation

The architecture proposes a recorded basis for coverage: the granting membership, beneficiary, evaluated rule, effective dates, and reason the relationship qualifies. Readers use recorded entitlements rather than recomputing inheritance independently at a gate, on a portal page, or in an event checkout. This gives Membership a single place to explain why someone is covered and to withdraw or change that coverage coherently.

The proposed evaluator responds to relevant changes and also performs periodic reconciliation. Household membership, affiliation, age boundaries, source membership status, and coverage policy can all change. An event initiates timely work; a sweep catches missed or stale evaluation. The design proposes idempotent comparison so repeated evaluation does not create repeated child records or repeated revocation activity.

The record distinguishes a policy that follows the qualifying predicate from one that preserves coverage pending review. Its recommended default favors attention and human resolution when composition changes rather than surprising a family with an immediate removal. This is proposed Membership policy, not a current CRM entitlement rule. Turning off a coverage rule must also have a declared meaning rather than becoming an accidental command to revoke every derived benefit.

Age-at-date belongs in Membership’s coverage semantics, with shared computation where other eligibility facilities use the same age fact. Term-start evaluation and later birthday evaluation can produce different outcomes; a package must say which basis applies. CRM cannot resolve that choice simply by providing a birth date. Unknown age is a visible uncertainty, not a license to infer a child’s eligibility or a guardian’s authority.

Authority to Act Is a Separate Contract

Andrew approves the direction of derived household-manager and guardian access, owned by Platform authorization with CRM as the factual source. This remains proposed delivery. A household member row does not itself grant portal authority. The derivation must evaluate the applicable role, effective period, maturity, relationship semantics, and scope, then produce authority that Platform can enforce and revoke.

The architecture proposes household managers acting within a household scope and guardians acting for minors through an access-authorizing relationship. A birthday, relationship end, role change, or departure can remove the basis. Adult representation requires a separate consented or staff-confirmed arrangement with renewed review; ordinary adult co-membership provides no general right to edit another adult’s identity or consent.

The proposed access design treats unknown birth date conservatively for guardianship. It does not derive guardian power merely because a household administrator describes someone as a child. A future portal can request missing information or staff review. The proposal’s minor-login restriction is also a future design choice, not an assertion about all current Platform account behavior.

For example, a guardian may register a child for an event while another adult in the household remains an independently authenticated attendee. Event registration needs to preserve who registered, who signed consent, and who receives the ticket. The CRM relationship explains the candidate authority; Platform determines access, and Events records the business action. Sharing a mailing address does not collapse these roles.

Delivery and Open Owner Work

The household architecture’s testing appendix and migration plan remain evidence behind the proposal, not chapters of this page. Its architectural dependencies still matter: Membership needs its own beneficiary and merge participation, Platform needs the derivation seam, and consumer applications need their named operations. Andrew’s household deferral prevents these dependencies from being treated as an active area milestone merely because the model is described here.

Unresolved work includes Membership’s benefit catalogue and owner-transfer design, Events’ guardian registration and consent recording, Marketing’s recipient-selection policy, Fundraising’s dated recognition basis, and Mobile’s person-level credential presentation. Some relationship and association dependencies in the original record assume Platform ownership of contact relationships; Andrew’s later CRM ownership decision removes that assumption for those relationships while leaving generic associations with Platform. These distinctions need to be reflected in the eventual owner specifications before implementation begins.

Data Enrichment: Ownership and the Information Model

CRM Owns the Product, Integration Owns Provider Execution

Andrew decides that enrichment belongs inside CRM. The enrichment record originally recommends a Platform module, and its alternatives chapter still explains that recommendation. The later ownership ruling governs the final architecture: CRM owns enrichment policy, requests, claims, suggestions, provenance, suppression, and allowance accounting. Platform’s Integration facilities continue to own provider contracts, connections, credentials, invocation, rate limiting, and adapter execution.

This is a decided direction for a proposed product, not evidence of a shipped enrichment module. Today’s contact enrichment integration does not establish the proposed claim vocabulary, review process, licensing controls, or household-independent enrichment application. Andrew decides on a new enrichment contracts category and a separate application entitlement so licensing and permissions can distinguish this product even while deployment belongs to CRM.

The architecture proposes local application of accepted information through CRM’s owning persistence. The accepted suggestion, record change, revision, and enrichment provenance should settle in one transaction. This replaces the record’s earlier proposal to begin with a cross-service or data-job-only application path. Bulk human decisions can still use the Data Job Engine for durable work and receipts; a local individual apply does not need an artificial service hop.

Andrew’s ownership ruling also removes dependence on a future shared business-event feature for every CRM change trigger. The proposed CRM module can react to changes it captures locally. It still uses ordinary Integration adapters rather than embedding provider SDKs or credentials in the contact service. A future second application’s enriched record requires an explicit owner contract; the generic subject address is not permission to write any application’s tables.

Evidence Is Not the Record Value

The architecture proposes separate concepts for the subject being enriched, a request attempt, a provider claim, a suggested change, and the provenance of an applied value. These answer different questions. A subject tracks the state of enrichment for a particular record. A request explains an attempted lookup and its outcome. A claim records what a source reports. A suggestion explains what Rhythm proposes to change. Provenance explains where the current field or collection value comes from.

A provider’s claim can remain useful evidence even when staff reject its proposed application. Conversely, an accepted claim does not authorize use in every output. The architecture proposes retaining source, observation and receipt times, licensing class, expiry, and value identity alongside claims. The record’s confidence vocabulary and supporting identifiers help the matcher explain why it associates evidence with a subject; confidence is not a general truth score about the person.

For example, an association administrator can see a proposed new job title with a company name and a verification date. The stored contact may still show the member-confirmed title. Staff can accept, reject, or defer the suggestion, while the claim remains separate according to retention policy. A later independent member correction should have different provenance from a provider value that staff merely accept.

The architecture proposes current-value provenance for scalar fields and collection members, including source kind, value digest, applicable lock, and expiry. Staff entry, member entry, imports, providers, AI research, and unknown historical origin remain distinguishable. Unknown origin is not relabeled as staff-verified simply because an old field has no source record. Independent verification can change the basis; ordinary acceptance preserves the provider’s restrictions.

Policies, Suppression, and Allowances

The architecture proposes an explicit policy per subject configuration, with eligible field groups, provider order, disclosure tiers, match criteria, application mode, refresh controls, and spending limits. Andrew decides that person information defaults to suggestions, while limited missing organization brand and identifier fields may be filled automatically. Automatic filling does not overwrite existing values. Employment changes and AI-derived claims always require human review.

The proposed safe initial configuration is disabled with no spending allowance. Enabling a policy does not enable every disclosure tier or every provider. More sensitive tiers require explicit administrative choices and the required attestation. This makes permission to invoke enrichment, provider connectivity, eligible policy, and remaining allowance distinct conditions rather than one “connected” switch.

Suppression is an independent privacy control. The architecture proposes checking suppression before cache lookup and before any outgoing provider request, using workspace-scoped identifier protection that can continue to prevent re-enrichment after erasure. Suppressing a subject removes applicable cached answers, claims, and suggestions while retaining a minimal basis to honor the suppression. Its exact relationship to an erasure request needs the decided privacy policy; deleting a contact must not inadvertently make the same person eligible for rediscovery.

The proposed allowance ledger distinguishes reserved and settled units. A request reserves capacity before billable execution, then settles actual usage or releases an unused reservation. Monthly grants, administrator adjustments, per-provider budgets, and in-flight requests need consistent accounting. Threshold notices should not become repeated messages on every lookup. Customer-provided keys also need a visible budget: paying the provider directly does not remove the risk of unexpected consumption.

Local Consistency and Provider Boundaries

The proposed apply transaction checks that the suggestion still corresponds to the relevant record version and value, confirms authority and policy, applies through the owning record operation, and settles the suggestion and provenance together. A changed contact or an already modified field needs review rather than silent stale application. An enrichment label on the revision identifies the operation’s origin without changing its authorization requirements.

The architecture proposes asynchronous provider work outside record-write transactions. Requests carry correlation and reserved usage through queued execution. Integration supplies credential handling, retry and rate-limit behavior, and adapter health; enrichment interprets the typed result. A slow provider must not hold an open contact transaction while an administrator edits the record.

Bulk runs manage selection, scheduling, progress, cancellation, and request fan-out. Applying selected suggestions is a separate durable operation with preview and receipts. A run that fetched claims successfully can still contain rejected matches, expired proposals, or failed applications. The console should show those outcomes separately rather than report “enriched” as though every source answer changed CRM.

Data Enrichment: Matching, Workflows, and Experience

A Bounded Provider Plan

The architecture proposes an ordered plan of at most three steps: baseline, a primary provider, and a fallback when the stop conditions permit it. It does not propose a per-field marketplace or an autonomous search for the cheapest source. A readable policy tells an association what it discloses, which provider it tries, when it stops, and what it can spend.

Provider contracts return Rhythm’s typed claim vocabulary rather than arbitrary provider field names. Andrew decides on person enrichment, organization enrichment, email verification, and change-watch capabilities within the new contracts category. Each adapter maps the provider’s result into this vocabulary and carries the source, match information, and license metadata needed by the consumer.

The proposed orchestrator stops when the policy’s required groups and accepted match are satisfied. It retains contradictory source claims for review rather than averaging them into an invented consensus. A fallback can improve missing information without implying that every provider sees the subject. The policy and allowance must permit each attempted disclosure and charge.

The architecture record’s provider comparison and license research remain supporting evidence. A provider’s advertised coverage is not a verified match rate for association records. Andrew’s premium-provider ruling is conditional on a consented sample evaluation and written terms. The page therefore does not turn the research’s assumed match rates or illustrative unit economics into performance promises.

Matching Is Explainable and Conservative

The architecture proposes rules-based acceptance that considers the provider’s score where available and corroborating identifiers such as name, employer, and location. A personal email address alone may produce a claim without enough evidence to recommend changes. Providers without a comparable score need an explicit corroboration rule rather than a fabricated numerical confidence.

A changed family name need not invalidate a match when independent evidence supports identity. A shared household mailbox, however, is not proof that the returned person is the contact being enriched. Ambiguous matches create review context or a duplicate hint; they do not merge contacts automatically. The shared normalization facilities can support both enrichment and duplicate evidence while the two decisions remain distinct.

The proposed suggestion compares current and reported information at the field-group level. It can distinguish filling a missing value, changing an existing value, adding a collection member, and proposing a relationship change. A rejected suggestion should not return unchanged after every scheduled refresh without a declared renewal condition. A new claim may warrant a new review, but provider repetition is not proof that staff’s earlier rejection was wrong.

Employment Is a Relationship Change

The architecture treats an employment change as a proposed affiliation operation, not a string update to a contact’s organization field. Today CRM’s affiliations already carry relationship meaning. The proposed enrichment workflow identifies or creates the organization through an authorized path, shows the affected affiliation and effective period, and asks staff whether the prior relationship ends or remains alongside the new one.

For example, a professional society learns that a member appears to have moved from a hospital to a medical school. Staff may confirm a new primary employment affiliation while retaining the hospital relationship as an adjunct appointment. A provider cannot infer that every prior role or compliance consequence ends. The reviewer needs the same business choices that ordinary affiliation administration requires.

Andrew decides that employment proposals are always reviewed. The proposed local apply must use explicit owning operations and preserve role and date safeguards. Where the normal editor does not yet expose a needed operation, the eventual capability must establish the operation before an enrichment shortcut claims to support it. No provider response justifies bypassing record locks, version checks, or compliance processing.

Entry Points and Review Work

The architecture proposes manual requests from a record, follow-up after creation or import, selected bulk requests, scheduled refresh, workflow initiation, and watch-triggered changes. Each entry point uses the same policy and privacy checks. A manual request can give quick feedback for a short operation while transitioning to a running state for slower work; it does not require the create form to wait for every provider.

The proposed record panel shows current and proposed values, understandable confidence, applicable source information, and review actions. Staff can accept, reject, or defer changes within their authority. The design limits detailed provider scores, usage units, and administrative source information to the users who need them; routine constituent work should not require interpreting a provider’s API response.

The proposed review queue supports meaningful filters, grouping, preview, and controlled bulk acceptance. A contact-level attention item can summarize several suggestions without generating one interruption per field. The data-quality context helps reviewers distinguish uncertain identity from a credible information update. Successful review does not imply successful apply; progress and receipts preserve that difference.

The proposed administration surface combines sources, rules, disclosure tiers, attestations, budgets, refresh settings, and suppression. A connected key is shown as a prerequisite, not as a guarantee of permission to use every returned field. Headquarters operations may need cross-workspace usage and adapter health, but such visibility requires its own authority and should not expose claim content implicitly.

Portal and AI Boundaries

The architecture proposes staff review first and a later member-facing transparency experience. A member’s future “keep my record” control, source notice, or correction workflow needs its own authority, licensed display policy, and suppression semantics. A provider claim that staff can see is not automatically suitable for a member portal.

AI research remains an open decision. The proposal uses Platform’s existing AI execution facility, opt-in operation, allowlisted public research, minimal context, and citations. It does not propose autonomous personal profiling, searching behind authentication walls, collecting personal phone or email data through research, or applying AI output without review.

The architecture proposes separating source evidence from generated interpretation so a reviewer can see what supports an assertion. A citation establishes where information is found, not necessarily that it describes the correct person. Licensing and disclosure checks apply to the prompt and output as well as to the eventual CRM value. Andrew has not approved the unresolved AI product direction simply by approving CRM ownership of enrichment.

Data Enrichment: Privacy, Licensing, and Economics

Disclosure and Use Are Different Checks

Andrew decides that tier controls and attestation are part of the first enrichment release. The architecture proposes classifying outgoing disclosure before a provider call, with higher tiers requiring explicit enablement, administrative attestation, and certified adapters. The ruling excludes the highest tier in the named regions for the initial release and conditions the intermediate tier on the required notice date. A budget or an API key cannot override those controls.

The proposed design excludes sensitive-category inference, biometrics, precise location, and enrichment-driven eligibility or credential decisions. It does not infer that a professional role authorizes investigation of a person’s private life. The architecture record’s legal and provider-license evidence informs these boundaries; it is not a general declaration that every proposed use is lawful in every customer situation.

Incoming information has a separate allowed-use test. A claim can be licensed for staff display but prohibited in export, mailing, webhook payloads, member presentation, or an AI prompt. The architecture proposes default-deny checks for each output and source class. Applying a value to a contact does not erase those restrictions. Independent staff or member verification can establish a new basis only through a declared verification operation.

The record contains inconsistent shorthand about customer-application use in some model descriptions and stricter output checks in its privacy chapter. The final design must reconcile those descriptions before implementation; this page follows the stricter proposed boundary without declaring the unresolved permission matrix approved. The same caution applies to education vocabulary, photo treatment, and retention of applied licensed values after source expiry.

Retention, Deletion, and Provider Exit

The architecture proposes retention bounded by both product policy and provider terms. Claims, pending suggestions, cached answers, and accepted values have different lifetimes and obligations. A shorter license limit must prevail over a longer product default. Removing a claim alone cannot satisfy a term that also limits continued display or use of an applied value.

The proposed cache is scoped to a workspace, provider connection, operation, and identifier. It does not share provider answers across customers. Cache life is the shorter applicable policy or license period, with separate treatment of unsuccessful lookups. Suppression is checked before cache use, so a cached answer cannot defeat a privacy choice.

On suppression or erasure, the architecture proposes removing applicable source content while retaining minimal noncontent audit and suppression data. A provider exit or contract termination requires a retention and usage sweep, not merely disabling the adapter. Applied values, previews, cache entries, and outbound uses need an explicit resolution according to the license and independent verification basis.

The proposed generic retention defaults remain an open decision. In particular, the record recommends a claim period and a shorter pending-review period while also proposing long-lived suggestion history. The permitted content of that history after licensed evidence expires is not settled. A retained decision event can be useful without retaining a prohibited provider payload, but the exact distinction needs a product and privacy decision.

Photos Need Their Own Acceptance Path

The open photo proposal separates a provider preview from a stored CRM asset. It recommends previewing first, then importing only an accepted image whose terms permit copying. The asset pipeline preserves the existing ownership and storage boundary; a third-party URL is not silently treated as a permanent contact photo.

A self-published avatar has a different source basis from a scraped personal photo or an organization logo. The proposal includes periodic rechecking for self-published avatars, while organization brand filling needs consistency with the separate photo-review decision. Andrew has not settled every photo and logo exception. The implementation must not resolve that tension by making every image automatic simply because organization identifiers can be filled automatically.

No photo operation authorizes facial recognition or biometric profiling. Staff review still needs match confidence, source rights, and a clear distinction between preview and persistence. If a provider does not permit storage, the proposed design keeps the result preview-only rather than relying on acceptance as permission to copy.

Included Baseline, Customer Keys, and Managed Premium

Andrew decides on an enrichment application with an included baseline and licensed premium capability. The architecture proposes low-cost baseline sources, customer-provided keys for premium data first, and Rhythm-managed premium credits only after provider-specific written agreements. These are three commercial arrangements sharing the same policy and usage controls, not three independent enrichment engines.

With a customer-provided key, the association holds and pays for its provider account. Rhythm still needs to confirm that the provider allows use through the application; a key alone does not establish that right. With a managed provider account, Rhythm also needs rights to display, retain, and supply results to customers, plus the required customer obligations and attribution of usage.

Andrew’s provider direction names a conditional premium candidate rather than an unconditional vendor commitment. The proposed evaluation uses a consented sample and written terms before selection. Baseline logos, avatars, public identifiers, and email verification likewise require their actual terms and output restrictions to be checked. The record’s evidence reports distinguish published prices from assumptions; no assumed association match rate becomes a cost guarantee here.

The architecture proposes shared-key rate protection and a Rhythm-level cap in addition to per-workspace allowance. Without both, one large run could exhaust capacity needed by other customers. Customer attribution remains necessary even when Rhythm pays the bill. The proposed system does not aggregate licensed answers into a cross-customer data asset or use one customer’s cache to subsidize another lookup.

The economic boundary also explains the ordered plan: administrators should be able to understand and cap cost without running a specialist orchestration environment. More elaborate per-field routing, provider optimization, and managed resale remain later options needing their own decisions. None is implied by the first-release ownership or licensing ruling.

Area-Level Invariants

Today the area’s responsibility model keeps record ownership with the module that maintains the record. Coordination does not transfer ownership. Entities can coordinate a merge without acquiring Accounting’s financial policy; Regions can determine placement without becoming the contact repository; Activities and Tasks can record follow-up without becoming Platform’s identity directory. The architecture preserves those boundaries in its proposed extensions.

Andrew’s authorization direction separates workspace authority, application entitlement, and authority over a particular operation. Today the area enforces workspace-bounded access through Platform and service guards. The architecture proposes further record-scoped and delegated access through that same owner. Knowing an identifier, sharing a household, appearing on a task, or supplying an integration key does not independently establish authority.

Andrew’s lifecycle and audit direction preserves the meaning of each operation. Archive, inactivate, merge, and hard delete are different actions with different historical consequences. The current safe-delete gap remains visible rather than being hidden behind an archive label. Retained history must also respect privacy: explaining an action does not require preserving every personal value indefinitely.

Our reading is that the architecture treats durable work as a sequence of explicit outcomes. Preview is not execution, provider lookup is not application, cancellation acknowledgment is not final settlement, and a candidate match is not a decision to combine identities. This is an architectural interpretation of the records’ safeguards, supported by their operation and integrity designs; it does not add a second rule contract beside the capabilities.

Andrew’s knowledge standard keeps built behavior, recorded decisions, proposals, and unknowns separate. The four module charters establish the current area boundary; the architecture records explain the direction and tradeoffs. Deferred households and proposed enrichment cannot be counted as shipped capabilities merely because their decisions are recorded. The absence of an area product acceptance suite also remains an explicit coverage gap.

Decisions

The following register names the decisions that shape the area and their outcomes. A ruling describes Andrew’s intent; it does not certify implementation or change this page’s draft status. The CRM architecture record collects the standing constraints and internal design choices, the household record contains its later model rulings, and the enrichment record contains its later ownership and release-gate rulings. The frontmatter identifies those records and the acceptance directives behind the register.

Standing Architecture Constraints

Decision name	Outcome and architectural consequence	Recorded source
Affiliation-centered organization relationships	Andrew places primary organization meaning on the affiliation, with reference-based channels, type-driven links, and affiliation defaults. A contact’s organization relationship is explained through that aggregate rather than a second organization pointer.	CRM record’s standing affiliations decisions
Transactional record merging	Andrew requires participant-owned changes in one transaction, a single-login transfer with incompatible logins blocking, survivor navigation for absorbed identities, restrictive consent reconciliation, retained merge evidence, and reviewed dependent state. Long-running merges are permitted with warnings; the organization employee ceiling remains part of the merge design. Historical calibration data is excluded.	CRM record’s standing merge decisions
Computed contact names	Andrew selects computed display names without parsing names during writes.	CRM record’s standing names decision
Organization classifications without key roles	Andrew removes key roles from organization types; the area does not reconstruct that configuration through prose.	CRM record’s standing classification decision
Configuration and record identity	Andrew distinguishes configuration identifiers from generated record identifiers using the shared identity standard.	CRM record’s standing identifier decision
Unified live console	Andrew requires one console-wide live or sample mode and meaningful live controls.	CRM record’s standing console decision
Stabilize before extending	Andrew requires acceptance of existing work before new building.	CRM record’s standing stabilization decision
Focused application delivery	Andrew focuses building and acceptance on CRM, Accounting, and Integration; other applications still need merge participation where they hold references.	CRM record’s standing focus decision
Approved vertical delivery	Andrew requires an approved vertical-slice plan, one implementation milestone per application, and hands-on acceptance. Writing this architecture does not authorize a new implementation milestone.	CRM record’s standing milestone standard
Current deletion until safe deletion	Andrew retains existing API and console bulk deletion until the safe-delete delivery. The architecture continues to expose the production-readiness limitation for customers relying on hard deletion.	CRM record’s safe-delete timing and hard-delete ruling
Cross-customer payment allocation	Andrew directs a later payment that allocates across customers. Accounting owns that work; it does not broaden CRM’s financial ownership.	CRM record’s standing payment decision
Physical reads and promised contracts	The standing read decision allows physical-table reads. The architecture recommends published compatibility contracts without inventing a prohibition on existing readers.	CRM record’s service-read decision

Acceptance Decisions: Record Experience and Integrity

The acceptance directives record product direction across service, shared infrastructure, and console. These decisions remain named here because they explain why the architecture separates those owners. Current module qualifications still apply; this table does not mark the associated repairs complete.

Decision name	Andrew’s outcome	Recorded source
Stored Contact 360 details	Present stored contact context and communication restrictions through shared record cards, including typed channels and prominent life-status restrictions.	First acceptance directive, contact presentation
Real toolbar actions	Expose backed actions and genuine archive semantics; hide unsupported live controls.	First acceptance directive, toolbar actions
Manually selected merge partner	Support selecting a second contact through the normal picker and reviewed merge flow.	First acceptance directive, selected contact merge
Rich-text custom fields	Retain rich text with a reusable sanitized editor and safe shared rendering.	First acceptance directive, rich text
Versioned and quiet writes	Standardize missing and stale preconditions and avoid revision noise for unchanged saves, with client migration before breaking enforcement.	First acceptance directive, concurrency
Understandable sample-mode absence	Explain missing sample records within the unified mode model.	First acceptance directive, sample record absence
Archived organizations and affiliation history	Preserve organization identity and distinguish current, past, and all affiliations.	First acceptance directive, historical affiliations
Authorized reversible locks	Separate customer locks from protected configuration and make transitions narrow and auditable.	First acceptance directive, locks
Intentional affiliation mutations	Preserve omitted relationships and use deliberate authorized operations for relationship changes.	First acceptance directive, omitted affiliations
Upcoming affiliations	Present future, current, and past relationship periods consistently.	First acceptance directive, affiliation classification
Visible role and type descriptions	Maintain descriptions through shared configuration forms and lists.	First acceptance directive, descriptions
Workspace business calendar	Interpret effective relationship dates through the workspace calendar.	First acceptance directive, effective dates
Customer-scoped grants	Resolve scope centrally without expanding every workspace into the token.	First acceptance directive, token scope
Administrator approval of staff access	Remove that approval authority from the Power User baseline and enforce the boundary in the service.	First acceptance directive, staff access
Explain effective access	Show grant and deny sources, scope, and separate application enablement through shared access presentation.	First acceptance directive, effective permissions
Available sign-in choices	Hide federation choices until they work.	First acceptance directive, Microsoft sign-in
Recover dirty forms	Prefer shared refresh and safe draft recovery with version checks over warning-only handling.	First acceptance directive, session recovery
Placeholder access roles	Permit draft roles that grant nothing and identify them clearly.	First acceptance directive, empty roles
Canonical spouse connection	Use one relationship visible from both endpoints; a reciprocal interim pointer remains a compatibility measure.	First acceptance directive, spouse relationship
Absorbed identity navigation	Provide consistent survivor resolution and accessible merged-from history.	First acceptance directive, absorbed routes
History for permitted readers	Separate reading merge details from authority to execute a merge.	First acceptance directive, read-only history
Accurate channel-edit audit	Distinguish editing an existing entry from replacing it with another entry.	First acceptance directive, phone audit
Visible record attribution	Present creation and modification information through normal record metadata.	First acceptance directive, attribution
Query negation	Preserve group negation and structured-query meaning through the visual editor.	First acceptance directive, negation
Disconnected source channels	Retain a last-known value with explicit disconnected provenance when its source disappears.	First acceptance directive, removed address source
User timestamp preferences	Separate user timestamp display from workspace business-date interpretation.	First acceptance directive, time-zone preference
Intent-aware AI query edits	Change the current structured query selectively with a visible explanation and undo.	First acceptance directive, AI Ask
Canonical links with navigation context	Keep helpful new-tab trails without embedding sensitive or excessive query state in shared links.	First acceptance directive, Explorer navigation
Durable search deletion	Prevent stale replay from resurrecting removed records without exhausting provider quota through long-lived search markers.	First acceptance directive, search deletion
Explain merge outcomes	Show material retained, discarded, and filled values through shared audit presentation.	First acceptance directive, merge detail
Approval of dependent identity and state	Fingerprint the relevant dependent records and versions, so equal counts do not hide changes.	First acceptance directive, merge fingerprint
Strict duplicate creation with explicit override	Keep existing evidence visible and require separate authority, reason, and audit for an allowed creation override.	First acceptance directive, duplicate blocking
Renewed approval after source changes	Preserve source selection while requiring review of its changed value.	First acceptance directive, merge selection drift
Repeat dismissal clarity	Treat an already-handled duplicate dismissal as an understandable repeat outcome.	First acceptance directive, repeated dismissal
Conflict without hidden version advancement	Keep stale edits stale until explicit reload or resolution.	First acceptance directive, Keep Editing
Organization channel parity	Reuse shared typed channel editors and preserve affiliation link behavior.	First acceptance directive, organization channels
Bulk target concurrency	Capture versions during validation and report changed targets rather than overwrite them.	First acceptance directive, bulk updates
Source and target import ordering	Protect against both late source revisions and newer independent target edits.	First acceptance directive, patch imports
Safe rollback and retry controls	Expose authorized controls with explicit conflicts and bounded rollback semantics.	First acceptance directive, data-job controls
Realistic collection mapping	Support usable preferred channels and a mapper that can represent multiple typed values.	First acceptance directive, spreadsheet channels
Cross-owner deletion impact	Preview affected records, retention, and blockers without treating contact deletion as financial deletion authority.	First acceptance directive, deletion impact
Privacy-qualified deletion audit	Preserve authorized action evidence under the hard-delete policy while archive retains full record history.	First acceptance directive, deleted history
Recognizable retries	Reuse client-generated identity and confirm ambiguous responses, alongside further operation-specific retry contracts.	First acceptance directive, lost responses
Retained independent activity	Do not automatically move a private activity to an organization or destroy it merely because its final contact link disappears.	First acceptance directive, orphan activities
Readable merge pointers	Connect actor, absorbed identity, survivor, and field outcomes into understandable history.	First acceptance directive, merge pointer
Effective affiliation roles	Reconcile starts, ends, and retroactive corrections instead of granting future roles early.	First acceptance directive, role automation
Evidence-specific candidate retirement	Remove unsupported duplicate candidates while retaining candidates supported independently.	First acceptance directive, stale pairs
Reconciled baseline configuration	Bring old and new workspaces to the versioned baseline without losing customer changes.	First acceptance directive, activity and task defaults
Shared activity exploration and history	Use Explorer and common audit views for activity queries and revision inspection.	First acceptance directive, activity visibility
Deliberate primary activity link	Let staff choose the primary linked record instead of fixing it to launch context.	First acceptance directive, primary link
Optional activity ownership	Keep owner distinct from creator and performer and allow ownerless activity editing.	First acceptance directive, activity owner
Versioned task transitions	Require concurrency protection on task state changes in service and console.	First acceptance directive, task state
Real Commerce composition	Hide nonfunctional order prototypes until the owner’s composer and datasets are integrated.	First acceptance directive, order prototype

Acceptance Decisions: Configuration, Shared Writes, and Operations

Decision name	Andrew’s outcome	Recorded source
Compliance after organization reclassification	Recalculate and explain compliance when the selected type changes.	Second acceptance directive, type-change compliance
Referenced role protection	Block removal while roles are used by compliance or notification configuration and show the dependencies.	Second acceptance directive, referenced roles
Administrative affiliation default	Treat the default affiliation type as a workspace administrative setting.	Second acceptance directive, default authority
Meaningful compliance minima	Do not persist rules that require only a zero minimum; the remaining type can still save.	Second acceptance directive, zero minima
Configuration custom fields	Use shared metadata forms across supported configuration objects.	Second acceptance directive, custom fields
Recurring seasonal dates	Store month and day boundaries and define cross-year behavior and conflicts.	Second acceptance directive, seasons
Readable retained references	Preserve useful history for archived and renamed records while leaving hard-delete personal retention to privacy design.	Second acceptance directive, historical references
Job-attributed revisions	Give data-job revisions meaningful labels and an originating-job link.	Second acceptance directive, revision attribution
Ordinary updates and explicit replacement	Leave omitted properties unchanged, distinguish clearing, and define complete replacement separately.	Second acceptance directive, shared update contract
Authoritative task assignees	Validate assignment through Platform while preserving historical attribution.	Second acceptance directive, assignee validation
Dependency-aware atomic imports	Order dependent operations inside an atomic group and report cycles or missing references.	Second acceptance directive, import ordering
Immediate cancellation acknowledgment	Acknowledge cancellation while final committed counts settle.	Second acceptance directive, cancellation
Ordinary defaults are editable	Reserve protection for genuine system invariants rather than protecting all seeded defaults.	Second acceptance directive, default protection
Audited lock transitions	Use the consistent lock operation for each transition without freezing unrelated list order.	Second acceptance directive, lock history
Explicit untyped-column defaults	Show resolved mapping, reject absent defaults, and preserve deterministic preferred-channel selection.	Second acceptance directive, import defaults
Processing-time checksum verification	Verify large uploads in the job before any data modification.	Second acceptance directive, checksums
Shared relationship-aware criteria	Deliver related-record predicates as shared semantic-query behavior in a later prioritized effort.	Second acceptance directive, relationship queries
Hidden undesigned profile actions	Keep Print Profile and Alerts unavailable pending design against existing presentation and attention facilities.	Second acceptance directive, profile actions

Recorded CRM Design Choices and Open Product Choices

The CRM record’s internal architecture choices are recommendations and design commitments within that record, not additional Andrew approvals. The one explicit merge-block ruling is distinguished below. Earlier descriptions of current gaps do not establish that the same gaps remain at the pinned module baseline.

Decision name	Outcome or remaining choice	Recorded source
One home for subsidiary contracts	The record adopts existing affiliation, merge, lifecycle, and write designs subject to later rulings rather than recreating them.	CRM internal sub-specification choice
Reference-owner participation	The record proposes each referencing application delivering its own merge and later deletion participation, with a coverage gate.	CRM internal participant choice
Shared match-or-create	The record proposes one duplicate-aware creation seam across entry points.	CRM internal creation choice
Deliberate update semantics	The internal choice follows Andrew’s partial-update and relationship rulings; client compatibility must be addressed before enforcement.	CRM internal update choice
Compatibility-promised reads	The record recommends stable views and functions while respecting the standing allowance for physical reads.	CRM internal read choice
Queryable organization hierarchy	The record proposes a maintained ancestor relation; measurement chooses closure storage or recursive access.	CRM internal hierarchy choice
Shared import execution	The record delegates engine behavior to its owner and registers CRM operations rather than creating another import framework.	CRM internal data-job choice
Query-based quality indicators	The record proposes saved queries and remediation instead of a general quality rules engine.	CRM internal quality choice
Organization channel evolution	The record proposes preferred organization phones and a typed email collection; email typing remains a product question.	CRM internal channel choice
Integration engagement as activity	The record proposes system activity types through the activity service rather than a separate engagement store.	CRM internal engagement choice
Platform portal authority	The record keeps scoped portal grants and possible affiliation derivation with Platform Security.	CRM internal portal choice
Block uncovered references during merge	Andrew requires blocking only merges that would strand uncovered references, with named impact, no override, and the block lifted by owner participation.	CRM merge-block ruling
Task pools and saved views	Open: the record recommends keeping pools but replacing special queue screens with ordinary saved views. Current implementation alone does not decide this.	CRM task-queue question
Relationship and household direction	The earlier organization-type recommendation is changed by the household rulings: narrow household identity and CRM-owned contact relationships, with delivery deferred. Broader organization relationship questions remain outside that exception.	CRM relationship question and household rulings
Safe member directories	Open: the record recommends a controlled CRM projection after portal self-service, with privacy filtering before presentation.	CRM directory question
Engagement scoring	Open: the record recommends deferring scoring rather than treating sample screens as a backend.	CRM engagement question
Email address types	Open: choose configurable types or retain ordered untyped addresses with honest import labels.	CRM email-type question
Exclusive organization roles	Open: choose optional enforced single-holder roles or retain advisory compliance.	CRM exclusive-role question
Record-scoped staff access	Open: decide launch scope, with implementation owned by Platform and CRM declaring record attributes.	CRM staff-scope question
Inapplicable affiliation roles	Open: decide whether to reject across channels or retain picker-only filtering.	CRM role-applicability question
Existing hard deletion	Decided: Andrew retains the current path until safe delete. Acceptance closure is not a declaration of safe cross-application deletion.	CRM hard-delete ruling
Sales product scope	Open: customer usage is not established; the record recommends a separate application if needed.	CRM Sales question

Household Rulings and Internal Choices

Andrew’s household decisions establish direction and explicitly defer implementation. The internal choices below remain proposals within that deferred design, including choices whose Platform assumptions need adjustment after the CRM-owned relationship ruling.

Decision name	Outcome	Recorded source
CRM-owned person relationships	Andrew assigns type semantics, rows, history, and participation to CRM as a specific exception to generic Platform associations.	Household relationship-ownership ruling
Narrow household identity	Andrew selects a first-class household rather than an organization classification or generic constituent group.	Household identity ruling
Household membership holder	Andrew allows household holdings in eligible programs and household Commerce recipients and entitlement holders, with a contact for billing; financial party kinds remain closed.	Household holder ruling
Explained beneficiaries	Andrew selects explicit coverage grounds with designated and derived bases.	Household coverage ruling
Household custom fields	Andrew approves the household as a supported configurable business object.	Household customization ruling
Multiple households and one primary	Andrew allows several household memberships and an explicit primary grouping.	Household composition ruling
Dated delegated authority	Andrew selects Platform-derived manager and guardian grants; membership alone supplies no authority.	Household delegation ruling
Signed-customer gate	Andrew defers planning and implementation until a signed customer needs the product.	Household sequencing ruling
Closed naming formats	Andrew selects defined formats and per-household overrides rather than a household template language.	Household naming ruling
Empty household service case	The internal proposal permits staged empty identity while console creation starts with a member.	Household internal empty-state choice
Editable types and roles	The internal proposal uses stable configuration meanings without requiring a particular seeded row forever.	Household internal configuration choice
Referenced shared addresses	The internal proposal uses explicit source links and disconnected provenance.	Household internal address choice
No inherited consent or identity channels	The internal proposal rejects automatic inheritance; explicit shared channel links need their own semantics.	Household internal inheritance choice
Canonical symmetric relationships	The internal proposal stores one ordered pair. Its original Platform-storage assumption yields to CRM ownership.	Household internal symmetry choice
Distinct household merge	The internal proposal adds a household planner and warns about different household contexts during contact merge.	Household internal merge choice
Reasoned dissolution and reinstatement	The internal proposal distinguishes composition-ending operations from archive.	Household internal lifecycle choice
Membership-owned age evaluation	The internal proposal keeps coverage ages with Membership and recommends term-start evaluation pending wider eligibility work.	Household internal age choice
One entitlement answer	The internal proposal directs consumers to Membership’s entitlement contract.	Household internal consumer choice

Enrichment Rulings and Open Choices

Decision name	Outcome	Recorded source
CRM ownership	Andrew places enrichment inside CRM, changing the original Platform recommendation and enabling local transactional apply.	Enrichment ownership ruling
Provider-neutral claim vocabulary	Andrew selects the new contracts category and four capability families.	Enrichment contract ruling
Conservative default application	Andrew selects person suggestions, narrow missing organization brand and identifier filling, no automatic overwrite, and reviewed employment and AI information.	Enrichment application ruling
Customer keys and conditional provider	Andrew selects customer keys first, baseline inclusion, a conditional first premium provider, and managed resale only after terms.	Enrichment commercial ruling
Photo treatment	Open: preview then copy only after acceptance where licensed, with self-published avatar rechecking and no face processing, is recommended.	Enrichment photo question
Initial higher-tier controls	Andrew permits the highest tier from the first release behind attestation, certification, suppression, and regional controls. The privacy chapter retains the named regions’ initial highest-tier exclusion and intermediate-tier notice condition.	Enrichment disclosure ruling and privacy design
Member transparency	Open: a portal notice and preservation control, early staff suppression, and access-request history are recommended.	Enrichment transparency question
Distinct application packaging	Andrew selects a baseline grant for all workspaces and separately licensed premium capability.	Enrichment licensing ruling
AI-assisted public research	Open: optional, cited, individual, always-reviewed research through Platform AI is recommended.	Enrichment AI question
Employment review responsibility	Open: configurable data-quality review is recommended. The reviewer choice remains open while the default-application ruling already requires review.	Enrichment review-routing question
Refresh and retention defaults	Open: bounded claim and pending-suggestion periods, refresh initially off, and annual refresh when enabled are recommended, subject to shorter license limits.	Enrichment retention question
Initial adapters	Open: the record recommends the conditional premium provider, a logo source, an avatar source, and an email verifier selected after retention review.	Enrichment adapter question

Deferred Lifecycle Choices

The CRM lifecycle design leaves seven named choices for the safe-delete plan: archive permission tier; whether a second approver is required; deletion-audit retention; treatment of personal information in free-text activity; treatment of disconnected email; whether merge actions share deletion-audit presentation; and whether ending an affiliation disconnects linked information. The record recommends minimal audit content, explicit privacy treatment, and no silent relationship-policy change, but these recommendations do not settle the choices. Computed custom fields also remain a separately owned future decision rather than a capability created by this area page.

Open Ownership Questions

Today the area has no product-area acceptance suite in the supplied corpus. The feature suites and journeys establish useful evidence within modules, but it is not established who owns the integrated product proof spanning creation, affiliation effects, region recalculation, follow-up, and merge safeguards. The area acceptance owner needs to resolve that gap without treating the architecture record’s proposal testing appendix as executed qualification.

The write-contract owner and CRM need to reconcile ordinary partial updates, explicit complete replacement, intentional affiliation operations, stale unchanged writes, and retry recognition against the pinned contracts. Andrew’s intent is recorded; individual observed exceptions remain findings or capability qualifications. The shared owner must establish how every client migrates and how application-specific mutation authority composes with the common persistence contract.

Platform and CRM still need a complete division for record-scoped staff access and later portal delegation. Staff access, household managers, guardians, organization administrators, and adult representatives have different scopes and sources. A shared household or affiliation role is factual input, not sufficient authorization. The expiry, revocation, privacy, and audit behavior must be specified by the access owner before the proposed portal experiences ship.

The safe-delete owner needs a published participant contract and an explicit privacy policy for retained identity, free-text activity, financial references, and suppression. Other applications must supply their own impact actions. Existing hard deletion remains Andrew’s decided interim behavior; it does not answer the retention choices or authorize CRM to delete another owner’s records.

The task owner and Platform need an authoritative assignee seam and a settled product decision on pools. The current work-pool implementation establishes what staff can do today, while the open decision establishes that its future presentation is unsettled. History, inactive users, role-holder consistency, and claim authority need to remain distinct from list presentation.

Household delivery remains gated by a signed customer. When that gate opens, CRM, Membership, Commerce, Platform, Events, Marketing, Fundraising, and Mobile need owner specifications reflecting the actual rulings. Membership still owns its benefit catalogue, coverage evaluator, owner transfer, and entitlement answer; Commerce must distinguish a household recipient from a financial buyer; Platform must derive authority; the other consumers must choose dated composition and reporting grain deliberately.

The household record retains original assumptions that relationships use Platform associations and that households never hold memberships. Those assumptions disagree with later explicit rulings. The eventual owner plans must adjust the affected reference registries, query contracts, lifecycle impact, billing contact, and consumer vocabulary. This page explains the reconciled direction but does not edit the evidence records or claim the dependent owner specifications are already reconciled.

Enrichment has six remaining product choices covering photos, transparency, AI research, review routing, retention, and adapter selection. The provider evaluation and written terms remain prerequisites even for the conditionally selected provider. Baseline terms and customer-key use also need confirmation. No vendor license, contract, or regional legal conclusion is created by this architecture page.

The enrichment record additionally needs a resolved output-permission matrix, retention behavior for applied licensed values and historical suggestions, consistent education vocabulary, and a clear photo or logo exception policy. Its higher-tier ruling and privacy chapter also use different shorthand for the named regions: the privacy chapter separately caps the highest tier and requires notice for the intermediate tier. The policy owner must make those controls explicit rather than implementing the most permissive reading of a summary.

Region recalculation still has observed consistency and settlement qualifications, and cross-owner merge and lifecycle coverage needs continuing maintenance as applications add references. Each owner needs its own findings and acceptance proof. The area page can name these architectural uncertainties while their operative fixes, rules, and tests stay in the owning module.