Contact Point

Identity of the contact point instance

A contact point is identified as an instance, not by its address string: the same number may appear on several subjects and one subject may hold the same number under two purposes. vCard identifies instances with PID plus CLIENTPIDMAP for cross-source merging; JSContact requires a Card-level uid (preferably a UUID URN) and Id-keyed map entries; FHIR has no instance identifier at all and relies on position within the resource.

1. Which authoritative master system issues the identifier for this contact-point instance, and what is that identifier? identity
2. When no master-system identifier exists, what governed IRI or UUID/ULID does the adopting Dimension assign? identity
3. Is the address string treated as an identifier, a matching key, or purely as an attribute of the instance? definition
4. Which source-instance identifiers from contributing systems map onto this instance for merge and de-duplication? provenance

Attachment of the mixin to a subject

As a mixin, the contact point exists only in attachment to a subject: a person, organisation, role, place, device or service. vCard binds channels to a vCard whose KIND is individual, group, org or location; FHIR binds ContactPoint into a resource such as Patient or Organization. Shared endpoints (a household line, a shared support mailbox) require an explicit multi-subject or role-based attachment rather than duplication.

1. Which subject record does this contact point attach to, and by which reference? composition
2. Is the endpoint shared by more than one subject, and how is a shared or role-based binding represented? relationship
3. How many contact points of the same medium may a subject hold at once, and is any medium mandatory for that subject type? constraint

Medium and scheme of the channel

The medium determines how the value is interpreted. FHIR binds system to a required closed set (phone, fax, email, pager, url, sms, other) and constraint cpt-2 requires a system whenever a value is present; vCard instead expresses medium through the property name plus TYPE and MEDIATYPE; JSContact separates Phone, EmailAddress and OnlineService objects. A URI scheme (tel:, mailto:, sip:, https:) makes the medium machine-decidable.

1. Which medium code classifies this endpoint, and from which controlled vocabulary is that code drawn? classification
2. Which URI scheme, if any, expresses this endpoint unambiguously for machine dispatch? interoperability
3. Must a medium be recorded whenever an address value is present, and what happens when the medium is unknown? constraint

Canonical and presentation forms of the address value

Storage form must be separable from display form. Telephone values are canonically the E.164 international form, expressed as a tel URI global number; local numbers are only meaningful with a phone-context parameter, and tel URI equivalence ignores visual separators. E-mail values follow RFC 5322 addr-spec, may contain UTF-8 under RFC 6532 with NFC normalisation recommended and comparison over the full address, while E.123 governs human-readable presentation.

1. What is the canonical stored form of this address value, and which rule produced it? constraint
2. If the value is a local or extension-bearing number, what phone-context or extension qualifies it? spatial
3. Which presentation form should be shown to a human, and in which locale convention? quality
4. How are internationalised or case-varying values normalised before comparison? validation

Capabilities and accessibility features of the endpoint

Two endpoints with the same medium can differ in capability: vCard TEL TYPE distinguishes voice, fax, cell, video, pager and textphone, and JSContact models these as a features boolean map independent of context. Capability drives fitness for a purpose (an SMS reminder cannot be sent to a fax line) and carries accessibility meaning, since textphone or relay-reachable endpoints exist for that reason.

1. Which capabilities does this endpoint support, and which are asserted versus observed? measurement
2. Does the endpoint carry an accessibility or assistive-communication characteristic that constrains its use? exception
3. What must happen when a requested interaction is incompatible with the endpoint's capabilities? decision

Purpose and context vocabulary

Purpose is expressed inconsistently across standards: FHIR use is a required closed set (home, work, temp, old, mobile) that mixes purpose with lifecycle and device type; vCard TYPE offers work/home plus capability values; JSContact contexts is an open boolean map with private/work and context-specific values; schema.org contactType is deliberately open-ended. An adopting Dimension must pin one governed vocabulary and record the mapping.

1. Which governed purpose codes apply to this endpoint, and may more than one apply at once? classification
2. Who governs the purpose vocabulary and by which procedure are new codes admitted? authority
3. How are lifecycle-flavoured or device-flavoured codes such as old and mobile prevented from overloading purpose? constraint

Audience, territory and permitted use scope

schema.org qualifies a contact point with areaServed, productSupported and contactOption, which limit who the channel is for. A published support line and an internal escalation number differ not in medium but in audience; a channel may also be valid only for a territory or product family. Google consumes only telephone and e-mail from contactPoint, showing that audience metadata is often lost downstream.

1. Which audience is this endpoint published to, and is it internal, partner-facing or public? access
2. Which served area or jurisdiction limits the endpoint's applicability? spatial
3. Which products, services or case types is this endpoint scoped to handle? relationship

Preference ranking among sibling endpoints

vCard PREF is an integer 1-100 where lower is more preferred and is interpreted only relative to other instances of the same property in the same vCard; JSContact repeats this and states that preferences apply only within the same property type; FHIR rank is a positiveInt with the same lower-is-better semantics. Preference is therefore a relative, subject-scoped and medium-scoped ordering, not an absolute score, and ties must have a deterministic resolution.

1. What is the preference value of this endpoint and within which comparison set is it interpreted? measurement
2. How are equal or absent preference values resolved deterministically? decision
3. Who may set preference — the subject, the steward, or an inference process — and how is that recorded? ownership
4. Does preference vary by purpose, so that one endpoint is preferred for billing and another for support? constraint

Availability window, time zone and languages

schema.org provides hoursAvailable and availableLanguage on ContactPoint; vCard carries LANG and TZ at card level. Reachability is conditional: a staffed line has opening hours, an endpoint has an operative time zone, and the languages usable at it come from BCP 47 tags whose subtags are governed by the IANA Language Subtag Registry. This model binds these values; it does not implement schedule algebra.

1. During which published window is this endpoint attended, and which schedule record defines it? temporal
2. Which time zone governs interpretation of the endpoint's availability and of contact attempts? temporal
3. Which language tags may be used at this endpoint, and which is preferred? interoperability

Lifecycle state and validity period

FHIR gives ContactPoint a period for when the endpoint was or is in use and an old use code; vCard has no per-property period and only a card-level REV, so period must be modelled explicitly. States must distinguish a proposed endpoint, an active one, one temporarily suspended (for example after a bounce), one superseded by a successor, and one retired.

1. What is the current lifecycle state of this contact-point binding and which transition produced it? state
2. From when until when is this binding asserted to be valid? lifecycle
3. Which state transitions are permitted, and which require evidence or approval before they take effect? process
4. Are superseded bindings retained as history, and for how long are historical bindings readable? retention

Succession, porting and reassignment to a different subject

An address value can outlive its binding. The FCC rules recognise that a number can be permanently disconnected and reassigned, and provide a safe harbour only where the database was checked and erroneously answered; NIST directs verifiers to consider SIM change and number porting as risk indicators. So the model must distinguish a replaced endpoint (same subject, new value) from a reassigned value (same value, different subject), and must never silently keep a stale binding active.

1. Which endpoint supersedes this one for the same subject and purpose? relationship
2. What signal indicates the address value may now belong to a different subject, and what state change does it force? event
3. How are porting, SIM change or mailbox-moved signals recorded without asserting they were evaluated by this model? evidence
4. Which external check was performed before use, and what did it return? provenance

Syntactic and structural conformance

Conformance is checkable without contacting anyone: a telephone value must be a valid E.164 global number or a local number with phone-context; an e-mail value must be a valid addr-spec, with UTF-8 permitted only where internationalised handling is supported; a medium must accompany any value. Conformance is necessary but never sufficient — a well-formed address may be unreachable or belong to someone else.

1. Which validation rules apply to this endpoint's medium, and at which version were they applied? validation
2. Which validation failures block acceptance and which are recorded as warnings? constraint
3. What does passing validation explicitly not prove about the endpoint? definition

Recorded control-verification state

Verification answers whether the subject actually controls the endpoint. NIST SP 800-63B constrains how channels may be used for out-of-band purposes — PSTN out-of-band is restricted and e-mail SHALL NOT be used for out-of-band authentication, though confirmation codes for address validation are excluded from that prohibition. This model records the verification outcome, method reference and expiry; the ceremony, the secret and the risk decision belong to the identity model.

1. Is control of this endpoint currently verified, and which external verification record establishes that? evidence
2. When was verification performed and when does it lapse? temporal
3. Which changes to the endpoint reset verification to unverified? lifecycle
4. What is this model forbidden from recording about the verification ceremony itself? security

Summarised reachability observations

Reachability is empirical. RFC 3463 separates 4.X.X persistent-transient from 5.X.X permanent failures and gives X.1.1 bad destination mailbox, X.1.2 bad destination system and X.1.6 mailbox moved; telephony yields analogous disconnection signals. The model stores the latest summarised state and pointers to the transaction evidence, so that a permanent failure can force suspension without this model owning the delivery pipeline.

1. What was the last observed reachability outcome for this endpoint and when did it occur? state
2. Which observed outcomes force a state change, and after how many occurrences? constraint
3. Where is the underlying delivery or call evidence held, and how is it referenced without copying it? provenance

Quality, staleness and confidence assessment

GDPR Art. 5(1)(d) requires personal data to be accurate and kept up to date, with every reasonable step taken so that inaccurate data are rectified or erased. That converts staleness into a governance obligation: a contact point needs a measurable age since last confirmation, a completeness profile and a confidence value that feed review, not a claim of correctness.

1. Which quality metrics are computed for this endpoint and how is each defined? measurement
2. How long since the endpoint was last confirmed by the subject or by a successful interaction, and when does it become stale? quality
3. Which quality thresholds trigger review, revalidation or suppression from selection? decision

Capture provenance and time separation

vCard SOURCE identifies the directory from which information came and REV marks the revision; JSContact carries created and updated as UTC datetimes. Provenance must separate when the subject asserted the endpoint (event time) from when the record observed or ingested it, and must state whether the assertion is self-asserted, supplied by a third party or inferred.

1. From which source system, form or interaction was this endpoint captured? provenance
2. Who asserted the endpoint, and is the assertion first-party, third-party or inferred? authority
3. What are the event time and the observation or ingestion time of this assertion, and why do they differ? temporal

Stewardship, master system and change authority

When several systems hold the same endpoint, one must be designated authoritative for the value and one accountable steward must own corrections. vCard's CLIENTPIDMAP exists precisely because instances arrive from multiple sources and must be reconciled without losing origin. Stewardship also determines who may override an automated state change.

1. Which system is authoritative for this endpoint's value, and which systems merely hold copies? ownership
2. Which role is accountable for correcting and revalidating this endpoint? ownership
3. Who may override an automated suspension or a validation failure, and what must be recorded? authority

Binding to externally owned permission and suppression decisions

GDPR Art. 21 gives a data subject the right to object to direct-marketing processing at any time and free of charge; 47 CFR 64.1200(d) requires a do-not-call request to be recorded when made, honoured within 30 days and kept for five years, and the registry to be refreshed at least every 31 days. Those records have their own lifecycle and enforcement. This model binds a reference and a derived restriction state so that channel selection can respect them.

1. Which permission, objection or suppression records currently apply to this endpoint? relationship
2. What derived restriction state does this model carry, and which purposes does it block? state
3. How fresh must the referenced permission state be before an agent may rely on it? constraint
4. Which permission concepts must never be stored in this model? privacy

Disclosure sensitivity and safe-contact restrictions

Endpoints differ in how far they may be disclosed: a published support line, an unlisted direct number, a shared household line, or an endpoint under a safe-contact restriction where an inadvertent voicemail or message would cause harm. GDPR Art. 25 requires data protection by design and by default, which makes the restrictive class the correct default for personal endpoints.

1. What disclosure class applies to this endpoint and which default applies when it is unset? access
2. On which publication surfaces may this endpoint appear, and which are explicitly forbidden? access
3. Are there handling restrictions such as no voicemail, no message content or contact only within a window? exception

Outbound bindings to sibling models

The mixin is deliberately thin and delegates: subject to the party models, place to the address and geography models, restriction to the permission model, verification to the identity model, evidence to the messaging model, schedule to the availability model, language to BCP 47. Each binding must be typed so an agent knows whether the target is required, and must not import the target's operations.

1. Which sibling models does this contact point reference, and with what link type? composition
2. For each link, which concepts remain owned by the target and must not be modelled here? authority
3. How should an agent behave when a referenced target record cannot be resolved? exception

Alternates, localisation and grouping of one logical endpoint

vCard ALTID marks property instances as alternative representations of the same logical property — typically translations — and instances sharing an ALTID count as one toward cardinality; JSContact instead uses a localizations map keyed by language tag. A number written in two notations, or a label translated into two languages, is one endpoint, not two, and de-duplication must respect that.

1. Which records are alternative representations of the same logical endpoint rather than distinct endpoints? identity
2. Which endpoint labels are localised, and under which language tags? interoperability
3. When do two endpoint records with equal canonical values count as duplicates that must be merged? validation

Crosswalk and export projections

The model must be projectable to vCard 4.0, jCard, JSContact, FHIR ContactPoint and schema.org ContactPoint without asserting conformance to any of them. RFC 9555 gives normative conversion rules and warns that some conversions are not round-trippable, for example group names and certain temporal types, so a projection must declare its loss profile.

1. How does each local element map to the corresponding element in each target standard? interoperability
2. Which information is lost or approximated in each projection, and is a round trip faithful? quality
3. What evidence would be required before claiming conformance rather than alignment to a target standard? evidence

Vocabulary conflicts and degradation policy

The examined standards genuinely disagree: FHIR use mixes purpose (home, work), lifecycle (old, temp) and device class (mobile) in one required set; vCard TYPE mixes context with capability (cell, fax, textphone); JSContact contexts is an open map; schema.org contactType is open-ended and a major consumer reads only telephone and e-mail; the W3C ontology is a non-normative Interest Group Note. These conflicts must be recorded, not resolved by assertion.

1. Which specific vocabulary conflicts affect this endpoint's classification, and how is each recorded? interoperability
2. How does an export degrade when the target vocabulary cannot express a local value? decision
3. Which alignments rest on normative sources and which on non-normative notes or consumer practice? authority

Inputs for selecting a channel for a purpose

Selection is a deterministic filter-then-order problem: eliminate endpoints that are not active, not capability-compatible, restricted for the purpose, or outside their attended window; then order the survivors by preference within the medium, with a declared tie-break. The model supplies the inputs and the ordering; it does not perform, authorise or log the resulting contact.

1. Which filters must be applied before an endpoint is eligible for a given purpose? decision
2. How are eligible endpoints ordered, and what is returned when none is eligible? process
3. What explanation data must accompany a selection so the decision is reproducible? evidence

Adding, correcting and replacing an endpoint

Change is where most harm enters: a typo silently redirects mail to a stranger, and NIST states that setting or changing a pre-registered telephone number is the binding of a new authenticator and must follow the binding rules. Corrections must therefore be distinguished from replacements, must reset verification, and must record who changed what and on whose instruction.

1. Is this change a correction of a mistyped value, a replacement by a new endpoint, or a purpose reclassification? process
2. On whose instruction and under whose authority was the change made? authority
3. Which dependent states must be reset or re-derived when the value changes? constraint
4. Which downstream models must be informed that the endpoint changed, and by what mechanism? relationship

Retention class, erasure and residual tombstone

Two obligations collide: GDPR Art. 17 supports erasure when data are no longer necessary, while 47 CFR 64.1200(d)(6) requires a do-not-call request to be honoured for five years, which normally requires retaining enough of the value to suppress future contact. The defensible resolution is to erase or minimise the contact-point record while the suppression key remains in the permission model, leaving a tombstone here that proves disposition without restoring reachability.

1. Which retention class applies to this contact-point record and what triggers its disposition? retention
2. What remains after erasure, and does the residue permit re-contact? privacy
3. How is an erasure request reconciled with a suppression obligation that requires keeping a key? exception
4. Who executes disposition across replicas and projections once it is decided? ownership