Record relationships and merge review

GTM Brain keeps record identity and relationship changes in the same governed mutation system as campaigns, artifacts, and delivery. Open an account and select Relationships to inspect its related contacts, opportunities, meetings, ownership, lifecycle, and duplicate-review history.

Ownership and lifecycle

An account, contact, opportunity, or meeting can have a tenant-scoped owner and an explicit lifecycle. The current lifecycle values are active, archived, and merged. Ownership and lifecycle updates use optimistic versions, so a stale operator or agent cannot overwrite a newer decision.

These updates are business mutations. The UI and APIs both invoke gtm.assign_record_owner or gtm.set_record_lifecycle; neither writes a query projection directly.

Relationship graph

The record graph combines two sources:

• canonical relationships already present in GTM data, such as an account's contacts, opportunities, and booked meetings; and
• tenant-defined relationship types and their governed relationship instances.

Relationship definitions are versioned schema. Relationship instances have stable endpoint identities, an active/removed lifecycle, optimistic versions, and immutable events. Removing an edge does not erase its audit history.

Duplicate detection and review

Duplicate candidates are deterministic and tenant scoped. The initial rules compare exact normalized domains and names for accounts, exact email or account/name identity for contacts, and account/name identity for opportunities. The server returns the rule, confidence, and exact source/target fingerprints used for the proposal.

Creating a proposal records a pending RecordMergeReview; it does not merge data. Approval requires the record.merge_approver capability and revalidates the exact current fingerprints. An approved merge marks the source as a reversible alias of the target. It does not delete either record or rewrite historical events. A later authorized reversal restores the source as an active canonical record.

This conservative model protects event history, connector identities, campaign bindings, and recovery. A future field-level consolidation flow can build on the approved review without turning deduplication into an irreversible database operation.

People and autonomous agents

People and approved autonomous clients use the same APIs and Fabric Platform actions:

GET  /gtm/records/{objectType}/{recordId}/graph
GET  /gtm/records/{objectType}/duplicate-candidates
GET  /gtm/record-merge-reviews
POST /gtm/record-model/mutate

The external-agent action catalog can expose the proposal action independently from execution actions. An agent may propose a candidate under its registered grant. Ownership changes, lifecycle changes, relationship changes, merge decisions, and reversals additionally require a short-lived capability proof bound to the tenant, agent principal, command, and action. Missing grants fail closed.

Every successful mutation follows:

API or agent → staged Lakebase command → Temporal → Fabric Platform Host
             → policy/capability check → immutable AssetEvent → projection

Authorization proofs are verified by the canonical action and are excluded from event snapshots. Retries reuse the same command identity; a changed payload conflicts rather than creating a second logical mutation.

Events

Approving or reversing a merge also emits the corresponding identity event for the source record. The projection can therefore be rebuilt from listEvents() without a hidden mutable table.

Next: Configurable record model, Meetings and lists, and Governance.