​
Entity Matrix

​
Status

  • document type: mixed current state and planning matrix
  • the Exists now column is authoritative for current implementation
  • if the matrix conflicts with code, trust the code
This page is the practical reference for deciding what to reuse in onelink, what belongs in shared platform code, and what should remain domain-specific.

​
Core Decision Rule

When adding a new feature:
  1. reuse an existing native entity first
  2. extend it with notes, labels, custom attributes, settings, or Captain configuration if possible
  3. add a domain service, policy, workflow, or UI extension if needed
  4. add a new shared entity only if the lifecycle is stable across domains
  5. add a domain-only entity only if the shared model is no longer semantically correct

​
Entity Matrix

EntityExists nowLayerGenericHealthcareConstructionNotes
AccountYesShared platformWorkspace / tenantWorkspace for clinic or medical orgWorkspace for builder / contractor orgUse as the real workspace boundary; do not invent a second internal workspace model
User / AccountUserYesShared platformOperators and adminsOperators, coordinators, adminsOperators, estimators, managers, adminsPer-account access identity already exists
InboxYesShared platformCommunication channelsFront desk, support, intake channelsSales, estimate, support channelsKeep routing and assignment here
ConversationYesShared platformCommunication threadPatient/client communication threadBuyer/client communication threadDo not replace with domain-specific messaging models
CompanyYesShared CRM primitiveCustomer organizationClinic, insurer, employer, partner orgDeveloper, contractor, supplier, buyer orgDefault organization-level entity
ContactYesShared CRM primitivePersonPatient, family contact, coordinatorBuyer, manager, stakeholderDefault person-level entity
NoteYesShared platformInternal notesMedical/operator notesEstimate/project notesUse before inventing a separate note model
LabelYesShared platformSegmentation and tagsIntake/status tagsQualification/project tagsUse for lightweight classification, not primary workflow state
CustomAttributeDefinitionYes, for Contact and ConversationShared variability layerTenant/domain fieldsMedical fieldsConstruction fieldsGood first step; currently not a universal schema system for every entity
TeamYesShared platformOwnership groupsFront desk, support, sales groupsSales, field, estimator groupsReuse for routing and visibility
MacroYesShared platformReusable actionsProtocol or reply shortcutsEstimate/sales shortcutsNative repeatability layer
AutomationRuleYesShared platformWorkflow automationIntake/escalation automationLead/project automationNative event-driven automation layer
Integrations::AppYesShared integration catalogApp definitionSameSameCatalog and capability descriptor, not installed instance
Integrations::HookYesShared integration instanceConnected appConnected medical/ops systemConnected construction/ops systemInstalled integration at account or inbox level
Captain::AssistantYesShared AI layerGeneral assistantDomain-aware medical assistantDomain-aware construction assistantShared AI framework, domain-aware configuration
Captain::DocumentYesShared AI knowledge layerGeneric docsMedical knowledge docsConstruction knowledge docsUse for domain knowledge before building special AI stores
Captain::CustomToolYesShared AI action layerGeneric toolsMedical-safe action toolsConstruction-safe action toolsAccount-scoped action surface for Captain
CopilotThreadYesShared AI collaboration layerOperator copilotMedical operator copilotConstruction operator copilotReuse for internal AI help flows
DealNot yetFuture shared CRMNeededNeededNeededShould be introduced as shared entity, not per-domain clone
TaskNot yetFuture shared CRMNeededNeededNeededSeparate from Deal
ActivityPartial via existing timeline/eventsFuture shared CRMNeededNeededNeededNormalize later as shared CRM timeline layer

​
What Is Already Shared

These should already be treated as common platform primitives:
  • Account
  • User
  • AccountUser
  • Inbox
  • Conversation
  • Company
  • Contact
  • Note
  • Label
  • CustomAttributeDefinition
  • Team
  • Macro
  • AutomationRule
  • Integrations::App
  • Integrations::Hook
  • Captain

​
What Should Be Domain-Specific

Domain-specific behavior should usually mean:
  • field packs
  • validation rules
  • workflow rules
  • UI sections and screens
  • reporting views
  • Captain documents, prompts, scenarios, and tools
Not:
  • a second workspace model
  • a second person model
  • a second organization model
  • a second messaging model

​
Near-Term Build Order

  1. attach domain profile or config to Account
  2. treat Company and Contact as mandatory shared CRM primitives
  3. use notes, labels, and current custom attributes for early domain variance
  4. use teams, macros, automation rules, integrations, and Captain as native extension points
  5. add shared CRM entities such as Deal, Task, and later Activity
  6. add domain-only entities only when the shared primitives stop matching the real business lifecycle