Contact and Organization Model

1. The real problem: one contact row mixes different truths

A consultant can have a personal email, a corporate email, and a history with two organizations. If everything lives in one mutable contact row, a job change can overwrite history, a shared team address can be misattributed to a person, and the source of each asserted value becomes unclear. This lesson builds Contact–Organization Relationship Ledger v1, keeping person, organization, communication point, and relationship evidence distinct.

2. Lesson ownership boundary

PLN-003 does not perform identity resolution. person_id must arrive from valid upstream evidence; deciding whether two handles belong to the same human is owned by PLN-002. This lesson asks which organization a known person is related to, when that relationship is valid, and which entity kind owns each communication point. Opportunity and next-action modeling remain in PLN-004.

3. Separate four concepts

At minimum, model Person, Organization, Relationship, and Communication Point independently. Person holds person-level identity facts. Organization is its own entity. Relationship holds role, affiliation, and validity. Communication Point represents an email, telephone, or address plus its owner kind and owner reference. Collapsing these concepts into one row weakens history and provenance.

4. What RFC 6350 supports—and what it does not

RFC 6350 defines vCard for representing and exchanging information about individuals and other entities, and KIND can represent an individual or an org. The format also includes properties such as EMAIL, TEL, TITLE, ROLE, and ORG. But vCard is an interchange format; it does not require MAKNOW to store person and organization data in one row and it does not establish identity truth.

5. Organization is not a text field on Person

organization_id should reference a distinct organization entity. Company name, domain, and organizational unit are organization attributes, not proof of personal identity. A message from @example.com may be useful evidence, but the domain alone must not bind the person to that organization or erase previous affiliations.

6. Model affiliation as a relationship

A Person↔Organization affiliation gets its own relationship_id, with role, valid_from, valid_to, relationship_status, and source_ref. When a role or employer changes, do not rewrite person identity. Close or update the relationship with evidence and create the new relationship as needed. This is a MAKNOW design contract, not a requirement imposed by RFC 6350.

7. Concurrent and historical affiliations are valid states

A contractor may legitimately have concurrent relationships with two organizations. The model should not delete one merely because validity windows overlap. Each affiliation needs its own identifier, evidence, and validity. Ending one affiliation and starting another on the same day can also be valid when both transitions are explicitly sourced.

8. A communication point has an owner

Every email, phone, or address needs a clear owner_kind and owner reference. A shared mailbox such as support@company.com can belong to the organization, not a person. A corporate address used by an individual may be connected to person or relationship context, but ownership must not be inferred solely from address shape. Do not force shared addresses into person records.

9. Preferred channel is different from ownership

preferred_channel expresses how contact should occur; it does not prove ownership or identity. A person may prefer a telephone line owned by an organization, or an organization-owned mailbox may be the operational channel. Keep ownership, preference, and validity separate so downstream routing does not inherit a false assumption.

10. Attribute- and relationship-level provenance

W3C PROV-O can be specialized for provenance in different applications and domains. Here it is only a lineage boundary: which source or event supports a role, phone, email, validity date, or relationship state. PROV does not define the contact schema itself; it makes asserted data traceable.

11. Do not overwrite a changed phone number

When a new telephone number appears, preserve the old value and its source rather than silently replacing it. The new record needs its own source and validity, while the previous value becomes historical or inactive. If the new value lacks adequate evidence, return REVIEW_REQUIRED. “Latest observed” is not automatically “current truth.”

12. Keep note scope bounded

A contact note must not become an unbounded container for person, organization, and opportunity facts. note_scope should state whether the note concerns the person, organization, or relationship. This improves auditability and prevents semantic leakage into adjacent lessons.

13. Worked example: role change without identity rewrite

Person P-17 leaves organization O-A and starts a relationship with O-B on the same day. P-17 remains unchanged. The old relationship gets an evidenced valid_to; the new one gets its own ID, role, and source. The old corporate email becomes historical, while the personal email remains active. No organization domain is promoted into identity proof. The bounded result is EVIDENCE_CLOSED.

14. Deterministic failure probes

Four shortcuts must fail or require review: (1) record an organization-owned shared mailbox with owner_kind=person → REVIEW_REQUIRED; (2) create a relationship without source/provenance → REVIEW_REQUIRED; (3) merge or delete concurrent affiliations simply because they overlap → invalid modeling; (4) replace a phone without preserving history → REVIEW_REQUIRED. By contrast, a same-day transition with distinct relationship IDs and complete evidence can be valid.

15. Transfer: shared mailbox plus overlapping contractor affiliations

In the transfer case, partners@north.example belongs to an organization and a contractor has concurrent relationships with two companies. Do not copy the baseline decision. Create two independent relationships, recompute each validity window from the changed evidence, bind the shared mailbox to the organization owner kind, and keep the contractor's personal communication point separate. If ownership or provenance is ambiguous, return REVIEW_REQUIRED rather than guessing.