# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-03T05:55:13Z", "synthesisSha256": "776a6979a65fe67d2f2b16dc8358a0b5b24a6ed1f7a0ef00f0c7f9f3e3b7b5de", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-XCT-024", "registryId": "vr.wm-xct-024", "name": "Contact Point", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.CONTACT" ], "tags": [ "contact", "point", "xct.contact" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-024-contact-point/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-024", "model": { "registry_id": "vr.wm-xct-024", "model_id": "WM-XCT-024", "name": "Contact Point", "entry_kind": "mixin", "purpose": "Provide a reusable, format-neutral mixin that describes one addressable communication channel bound to a subject, together with its medium, canonical address value, purpose/context, preference rank, validity period, verification and reachability state, provenance and disclosure class, so that an agent can decide which channel to use for which purpose and keep the binding correct over time.", "scope_statement": "WM-XCT-024 covers a single addressable endpoint (telephone number, e-mail address, messaging or online-service handle, fax, pager, web endpoint) as attached to a subject such as a person, organisation, role, place, device or service. It owns the endpoint's identity, medium classification, canonical and display forms, purpose/context vocabulary, preference ordering relative to sibling endpoints on the same subject, validity period and lifecycle state, syntactic validation, the recorded state of control-verification and reachability assertions produced elsewhere, capture provenance, stewardship, disclosure sensitivity and disposition of its own records. It does not own the subject, the physical/postal address, the consent or permission record, the message or call itself, the authentication ceremony, the numbering-plan or domain administration, or any evaluation, enforcement or audit-trail machinery: those are referenced, not reproduced.", "in_scope": [ "Endpoint identity and its distinction from the address string, including stable identifiers and multi-source merge identifiers (vCard UID/PID/CLIENTPIDMAP, JSContact uid and Id-keyed maps)", "Medium/system classification and channel capabilities (voice, text/SMS, video, fax, pager, url, other) with URI-scheme binding such as tel: and mailto:", "Canonical storage form versus presentation form of the address value (E.164 canonical digits, tel URI with phone-context for local numbers, RFC 5322 addr-spec, UTF-8/EAI local parts with NFC normalisation, E.123 display notation)", "Purpose/context classification and audience scope (work, private, billing, delivery, support, emergency; role-based versus personal; area served; products supported)", "Preference ranking scoped to sibling endpoints of the same medium on the same subject, plus availability window, time-zone binding and available languages", "Validity period, lifecycle state, succession/replacement, and reassignment or porting of an address to a different subject", "Syntactic and structural validation rules per medium, and the recorded verification and reachability state with pointers to externally owned evidence", "Capture provenance (source, supplier, self-asserted versus third-party), stewardship, master-system designation and revision timestamps", "Disclosure sensitivity class (public directory, restricted, unlisted, safe-contact restrictions) and the reference binding to externally owned permission or suppression decisions", "Interoperability crosswalks and projections to vCard 4.0, jCard, JSContact, FHIR ContactPoint and schema.org ContactPoint" ], "out_of_scope": [ "The subject entity itself (person, organisation, role, device) and its names, identifiers and lifecycle — owned by WM-PER-010 and sibling party models", "Structured postal or physical address content and geocoding, which vCard models as a distinct ADR property and schema.org as PostalAddress", "Consent, lawful basis, opt-in/opt-out record lifecycle and suppression-list execution — this model carries only a reference and the resulting restriction state", "Individual communication events (a sent message, a placed call, a delivered SMS) and their content, delivery pipeline and retry logic", "Authentication and authenticator-binding ceremonies that use a channel out-of-band; NIST SP 800-63B treats registering or changing a telephone number for out-of-band use as authenticator binding governed by the identity model", "Numbering-plan administration, number assignment, portability operations and domain/DNS ownership, which are administered by ITU-T E.164 assignees, national regulators and registries", "Access-control policy evaluation, enforcement engines and audit-trail record semantics, which are referenced by this model and owned by the adopting Dimension's governance models", "Opening-hours/schedule, geographic-area and language-tag registries, which are referenced as external vocabularies rather than redefined", "Campaign, case-management or CRM workflow state that merely happens to be keyed by a contact point" ], "boundary_notes": [ { "neighbor": "WM-PER-010 Person (and sibling Organisation/Role models)", "distinction": "The mixin attaches to a subject and never carries subject attributes; vCard places TEL/EMAIL on a vCard whose KIND declares the entity type, and FHIR places ContactPoint inside Patient/Practitioner/Organization rather than defining the party.", "source_refs": [ "SRC-001", "SRC-004" ] }, { "neighbor": "Postal/Physical Address model", "distinction": "vCard separates ADR from TEL/EMAIL and schema.org separates PostalAddress from ContactPoint; a contact point may reference a place but must not embed structured street/locality components.", "source_refs": [ "SRC-001", "SRC-005" ] }, { "neighbor": "Consent / Permission-to-contact model", "distinction": "GDPR Art. 21 objection rights and 47 CFR 64.1200(d) do-not-call records are permission artefacts with their own lifecycle, retention (five years for a do-not-call request) and enforcement; this model records only a reference and the derived restriction state.", "source_refs": [ "SRC-014", "SRC-015" ] }, { "neighbor": "Communication Event / Message model", "distinction": "RFC 3463 delivery status codes are produced by message transactions; this model stores a summarised last-known reachability state and evidence pointers, not the message, its transaction log or its audit trail.", "source_refs": [ "SRC-012" ] }, { "neighbor": "Identity Verification / Authenticator model", "distinction": "NIST SP 800-63B makes PSTN out-of-band a restricted authenticator and forbids e-mail for out-of-band authentication; channel-as-authenticator policy, risk signals and binding ceremonies stay in the identity model, while this model stores only verified/unverified state and a pointer.", "source_refs": [ "SRC-013" ] }, { "neighbor": "Numbering and domain administration authorities", "distinction": "ITU-T E.164 defines the international numbering plan and assignment is made by national authorities; this model consumes the resulting number as an address value and never asserts assignment authority.", "source_refs": [ "SRC-007" ] }, { "neighbor": "Availability schedule, area and language vocabularies", "distinction": "schema.org hoursAvailable/areaServed and BCP 47 language tags are external vocabularies; the mixin holds the binding and the tag value, not the schedule algebra, the geographic geometry or the subtag registry.", "source_refs": [ "SRC-005", "SRC-011" ] } ] }, "sources": [ { "id": "SRC-001", "title": "RFC 6350: vCard Format Specification", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6350.html", "version_or_date": "RFC 6350, Proposed Standard, August 2011", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:05:00Z", "relevance": "Normative source for TEL/EMAIL/IMPP/LANG/TZ/GEO/URL properties and the TYPE, PREF (1-100, lower is preferred), ALTID, PID, MEDIATYPE, VALUE parameters, plus UID, KIND, SOURCE, REV and CLIENTPIDMAP for multi-source identity." }, { "id": "SRC-002", "title": "RFC 9553: JSContact: A JSON Representation of Contact Data", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9553.html", "version_or_date": "RFC 9553, Standards Track, May 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:07:00Z", "relevance": "Defines Phone, EmailAddress and OnlineService objects with contexts, pref, features and label, mandatory uid, created/updated UTCDateTime and localizations; confirms that preference is scoped per property type." }, { "id": "SRC-003", "title": "RFC 9555: JSContact: Converting from and to vCard", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9555.html", "version_or_date": "RFC 9555, Standards Track, May 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:09:00Z", "relevance": "Normative crosswalk between JSContact objects and vCard TEL/EMAIL/IMPP, TYPE-to-contexts and PREF-to-pref mapping, and explicit statements about non-round-trippable conversions." }, { "id": "SRC-004", "title": "HL7 FHIR R5 Data Types: ContactPoint", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/datatypes.html#ContactPoint", "version_or_date": "FHIR v5.0.0 (R5), 2023-03-26", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:06:00Z", "relevance": "Defines the ContactPoint datatype fields system, value, use, rank and period with cardinality 0..1, required value-set bindings and constraint cpt-2 (a system is required when a value is present)." }, { "id": "SRC-005", "title": "ContactPoint - Schema.org Type", "organization": "Schema.org", "url": "https://schema.org/ContactPoint", "version_or_date": "Schema.org version 30.0, released 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T08:06:30Z", "relevance": "Defines contactType, contactOption, areaServed, availableLanguage, hoursAvailable, productSupported, telephone, email, faxNumber and url; shows that contactType is guidance-based rather than a closed enumeration." }, { "id": "SRC-006", "title": "vCard Elements registry", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml", "version_or_date": "Registry last updated 2026-01-13", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:08:00Z", "relevance": "Authoritative registry of vCard properties, parameters, value data types, property values and parameter values, with Expert Review plus RFC Required for unnamespaced entries; the governing extension point for channel vocabularies." }, { "id": "SRC-007", "title": "ITU-T Recommendation E.164: The international public telecommunication numbering plan", "organization": "International Telecommunication Union (ITU-T)", "url": "https://www.itu.int/rec/T-REC-E.164/en", "version_or_date": "E.164 (02/26), in force", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:10:00Z", "relevance": "Normative basis for the canonical international telephone number form used as the storage form of telephone contact points and for the assignment authority boundary." }, { "id": "SRC-008", "title": "ITU-T Recommendation E.123: Notation for national and international telephone numbers, e-mail addresses and web addresses", "organization": "International Telecommunication Union (ITU-T)", "url": "https://www.itu.int/rec/T-REC-E.123/en", "version_or_date": "E.123 (02/01), with errata and amendment through 2022-06", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:10:30Z", "relevance": "Normative notation for presenting telephone numbers, e-mail addresses and web addresses, establishing the display-form versus canonical-form distinction." }, { "id": "SRC-009", "title": "RFC 3966: The tel URI for Telephone Numbers", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3966.html", "version_or_date": "RFC 3966, Proposed Standard, December 2004", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:11:00Z", "relevance": "Defines global (+E.164) versus local numbers, the mandatory phone-context parameter for local numbers, isub/ext parameters and tel URI equivalence rules used for deduplication." }, { "id": "SRC-010", "title": "RFC 6532: Internationalized Email Headers", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6532.html", "version_or_date": "RFC 6532, Standards Track, February 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:12:00Z", "relevance": "Extends addr-spec to UTF-8 local parts and domains, recommends NFC (not NFKC) normalisation and warns that comparison must use full address length — directly constrains e-mail canonicalisation and matching." }, { "id": "SRC-011", "title": "RFC 5646 (BCP 47): Tags for Identifying Languages", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5646.html", "version_or_date": "RFC 5646 / BCP 47, September 2009", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:12:30Z", "relevance": "Governs the language-tag values used for availableLanguage and for localisation of channel labels, and defines the IANA Language Subtag Registry as the external authority." }, { "id": "SRC-012", "title": "RFC 3463: Enhanced Mail System Status Codes", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3463.html", "version_or_date": "RFC 3463, Standards Track, January 2003", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:13:00Z", "relevance": "Distinguishes 4.X.X persistent-transient from 5.X.X permanent failures and defines X.1.1 bad destination mailbox, X.1.2 bad destination system and X.1.6 mailbox moved — the evidence classes for e-mail reachability state." }, { "id": "SRC-013", "title": "NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://pages.nist.gov/800-63-4/sp800-63b.html", "version_or_date": "Revision 4, published 2025-08-26", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:14:00Z", "relevance": "States that PSTN out-of-band is a restricted authenticator, that setting or changing a pre-registered telephone number is authenticator binding, that risk indicators such as SIM change or number porting SHOULD be considered, and that e-mail SHALL NOT be used for out-of-band authentication." }, { "id": "SRC-014", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng", "version_or_date": "Regulation (EU) 2016/679 of 27 April 2016, OJ L 119, 4.5.2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:15:00Z", "relevance": "Art. 5(1)(d) accuracy (inaccurate data rectified or erased without delay), Art. 17 erasure, Art. 21 objection to direct marketing at any time and free of charge, Art. 25 data protection by design and by default — the legal constraints on holding and disposing of contact points." }, { "id": "SRC-015", "title": "47 CFR 64.1200 — Delivery restrictions (telephone solicitation and do-not-call rules)", "organization": "United States Government Publishing Office / Federal Communications Commission", "url": "https://www.govinfo.gov/content/pkg/CFR-2023-title47-vol3/xml/CFR-2023-title47-vol3-sec64-1200.xml", "version_or_date": "Code of Federal Regulations, Title 47, 2023 annual edition", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:16:00Z", "relevance": "Requires do-not-call requests to be recorded at the time of the request, honoured within 30 days and for five years, national registry versions no more than 31 days old, and provides the Reassigned Numbers Database safe harbour where a number was permanently disconnected after consent was obtained." }, { "id": "SRC-016", "title": "vCard Ontology — for describing People and Organizations", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vcard-rdf/", "version_or_date": "W3C Interest Group Note, 22 May 2014", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T08:17:00Z", "relevance": "RDF projection using hasTelephone/hasEmail with rdf:type-based Work/Home/Cell/Pref classes; explicitly an Interest Group Note and not a W3C Recommendation, so it is an alignment target of limited normative weight." }, { "id": "SRC-017", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "RFC 3339, Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:18:00Z", "relevance": "Requires seconds and an explicit time offset (Z or numeric), and distinguishes -00:00 (offset unknown) from Z/+00:00 — the timestamp rule for all temporal fields in this model." }, { "id": "SRC-018", "title": "FHIR R5 ValueSet: ContactPointSystem", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/valueset-contact-point-system.html", "version_or_date": "FHIR v5.0.0, 2023-03-26, required binding", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T08:19:00Z", "relevance": "Closed required value set of channel media: phone, fax, email, pager, url, sms, other — a concrete counterexample to open-ended medium vocabularies and the basis for medium crosswalks." }, { "id": "SRC-019", "title": "Organization (Organization structured data) — Google Search Central", "organization": "Google", "url": "https://developers.google.com/search/docs/appearance/structured-data/organization", "version_or_date": "Documentation last updated 2026-04-15", "source_type": "first-party-doc", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-09-03T08:20:00Z", "relevance": "Consumer-side profile showing that a major consumer supports only contactPoint.telephone and contactPoint.email and treats the rest as administrative detail — evidence that published vocabularies are consumed as narrow subsets." } ], "structure": { "bundles": [ { "id": "channel-identity-and-value", "name": "Channel Identity and Addressable Value", "description": "What the contact point is, which subject it is attached to, what medium it uses, and what the address value is in canonical and presentation form.", "rationale": "Every standard examined separates the endpoint instance from the subject and from the literal address string: vCard uses UID/PID plus a repeatable TEL/EMAIL property, JSContact uses Id-keyed maps under a Card uid, and FHIR nests ContactPoint inside a resource. Identity and value must therefore be modelled before purpose or preference.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "layers": [ { "id": "endpoint-identification", "name": "Endpoint Identification and Subject Binding", "description": "Stable identity of the endpoint instance, its distinction from the address string, and the mixin attachment to a subject.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "findings": [ { "id": "contact-point-identity", "name": "Identity of the contact point instance", "description": "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "cpi-q-master-id", "text": "Which authoritative master system issues the identifier for this contact-point instance, and what is that identifier?", "kind": "identity", "answer_data": [ "master system name or registry reference", "master-system record identifier", "identifier scheme or namespace" ] }, { "id": "cpi-q-local-id", "text": "When no master-system identifier exists, what governed IRI or UUID/ULID does the adopting Dimension assign?", "kind": "identity", "answer_data": [ "assigned UUID or ULID", "assignment authority", "assignment timestamp" ] }, { "id": "cpi-q-value-vs-instance", "text": "Is the address string treated as an identifier, a matching key, or purely as an attribute of the instance?", "kind": "definition", "answer_data": [ "identity policy flag", "canonical match key derived from value", "statement that value alone is not the identity" ] }, { "id": "cpi-q-merge", "text": "Which source-instance identifiers from contributing systems map onto this instance for merge and de-duplication?", "kind": "provenance", "answer_data": [ "contributing source URI list", "source-local instance identifiers (PID/CLIENTPIDMAP style)", "merge decision reference" ] } ], "data_elements": [ { "id": "de-contact-point-id", "name": "contact_point_id", "description": "Primary identifier of the contact-point instance, resolved by the identity priority rule.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-source-instance-id", "name": "source_instance_ids", "description": "Identifiers of the same endpoint instance in contributing source systems, used for merge, mirroring vCard PID/CLIENTPIDMAP pairs.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-match-key", "name": "canonical_match_key", "description": "Derived, non-authoritative key computed from the canonical address value for duplicate detection only.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Identity here is a set of scalar identifier fields and merge references carried inline on the instance; no standard examined produces a separate identity document for a contact point, and creating one would duplicate the master system's record." }, { "id": "subject-attachment-binding", "name": "Attachment of the mixin to a subject", "description": "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.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ], "questions": [ { "id": "sab-q-subject", "text": "Which subject record does this contact point attach to, and by which reference?", "kind": "composition", "answer_data": [ "subject model identifier and record reference", "subject kind (person, organisation, role, place, device, service)", "attachment reference type" ] }, { "id": "sab-q-shared", "text": "Is the endpoint shared by more than one subject, and how is a shared or role-based binding represented?", "kind": "relationship", "answer_data": [ "shared indicator", "role or function the endpoint serves", "co-attached subject references" ] }, { "id": "sab-q-cardinality", "text": "How many contact points of the same medium may a subject hold at once, and is any medium mandatory for that subject type?", "kind": "constraint", "answer_data": [ "per-medium cardinality rule", "mandatory-medium rule by subject type", "policy owner of the rule" ] } ], "data_elements": [ { "id": "de-subject-ref", "name": "subject_ref", "description": "Reference to the subject record to which this contact point is attached.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-subject-kind", "name": "subject_kind", "description": "Kind of subject holding the endpoint, aligned with vCard KIND values (individual, group, org, location) extended by the adopting Dimension.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-shared-flag", "name": "is_shared_endpoint", "description": "Indicates the endpoint is knowingly reachable by more than one natural person, which changes disclosure and safe-contact handling.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "The attachment is a reference plus qualifiers; the subject record itself is owned by WM-PER-010 and sibling party models, so producing any subject-bearing artefact here would reproduce another model's content." } ] }, { "id": "address-value-and-form", "name": "Medium, Capability and Address Value Form", "description": "Classification of the communication medium, the capabilities of the endpoint, and canonical versus presentation forms of the address value.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-010", "SRC-018" ], "findings": [ { "id": "channel-medium-classification", "name": "Medium and scheme of the channel", "description": "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.", "source_refs": [ "SRC-004", "SRC-018", "SRC-001", "SRC-002" ], "questions": [ { "id": "cmc-q-medium", "text": "Which medium code classifies this endpoint, and from which controlled vocabulary is that code drawn?", "kind": "classification", "answer_data": [ "medium code value", "vocabulary identifier and version", "closed or extensible binding strength" ] }, { "id": "cmc-q-scheme", "text": "Which URI scheme, if any, expresses this endpoint unambiguously for machine dispatch?", "kind": "interoperability", "answer_data": [ "URI scheme", "full endpoint URI", "media type hint where the value dereferences a resource" ] }, { "id": "cmc-q-required", "text": "Must a medium be recorded whenever an address value is present, and what happens when the medium is unknown?", "kind": "constraint", "answer_data": [ "mandatory-medium rule equivalent to FHIR cpt-2", "fallback code for unclassifiable endpoints", "escalation or review flag" ] } ], "data_elements": [ { "id": "de-medium-code", "name": "medium_code", "description": "Coded communication medium of the endpoint (phone, fax, email, pager, url, sms, other, or an extension code).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-endpoint-uri", "name": "endpoint_uri", "description": "Scheme-qualified URI form of the endpoint where one exists (tel:, mailto:, sip:, https:).", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-service-name", "name": "online_service_name", "description": "Name of the online or messaging service for handle-based endpoints, per the JSContact OnlineService object.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Medium classification is a single coded field plus a URI; the vocabulary itself is registered externally (IANA, FHIR value set) and is referenced rather than reproduced as a local artefact." }, { "id": "canonical-address-value", "name": "Canonical and presentation forms of the address value", "description": "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.", "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-010", "SRC-002" ], "questions": [ { "id": "cav-q-canonical", "text": "What is the canonical stored form of this address value, and which rule produced it?", "kind": "constraint", "answer_data": [ "canonical value string", "canonicalisation rule identifier and version", "source form before canonicalisation" ] }, { "id": "cav-q-context", "text": "If the value is a local or extension-bearing number, what phone-context or extension qualifies it?", "kind": "spatial", "answer_data": [ "phone-context domain or global-number prefix", "extension or ISDN subaddress", "validity area of the local number" ] }, { "id": "cav-q-display", "text": "Which presentation form should be shown to a human, and in which locale convention?", "kind": "quality", "answer_data": [ "display string", "presentation convention reference", "locale or region used for formatting" ] }, { "id": "cav-q-normalisation", "text": "How are internationalised or case-varying values normalised before comparison?", "kind": "validation", "answer_data": [ "Unicode normalisation form applied", "case-handling rule for local part and domain", "comparison scope statement" ] } ], "data_elements": [ { "id": "de-canonical-value", "name": "canonical_value", "description": "Canonical machine form of the address value (E.164 global number, addr-spec, or scheme-qualified handle).", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "de-display-value", "name": "display_value", "description": "Human presentation form of the address value following E.123 or a locale convention.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-phone-context", "name": "phone_context", "description": "Scope qualifier required for local (non-global) telephone numbers.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-extension", "name": "extension_or_subaddress", "description": "Extension or ISDN subaddress; at most one of the two may be present.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "canonicalisation-ruleset", "name": "Channel canonicalisation ruleset", "description": "Versioned, machine-readable ruleset mapping raw captured values to canonical storage forms and display forms per medium and region, including normalisation and equivalence rules.", "media_or_form": [ "structured rule table", "machine-readable ruleset document" ], "serial": true, "identity_strategy": "Governed ruleset identifier assigned by the adopting Dimension plus a monotonically increasing version number; each published version is immutable.", "source_refs": [ "SRC-008", "SRC-009", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "channel-capabilities", "name": "Capabilities and accessibility features of the endpoint", "description": "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-006" ], "questions": [ { "id": "cc-q-features", "text": "Which capabilities does this endpoint support, and which are asserted versus observed?", "kind": "measurement", "answer_data": [ "capability flags (voice, text, video, fax, pager, cell)", "assertion basis per capability", "observation reference where capability was tested" ] }, { "id": "cc-q-accessibility", "text": "Does the endpoint carry an accessibility or assistive-communication characteristic that constrains its use?", "kind": "exception", "answer_data": [ "accessibility feature code such as textphone", "required intermediary or relay indicator", "handling instruction reference" ] }, { "id": "cc-q-mismatch", "text": "What must happen when a requested interaction is incompatible with the endpoint's capabilities?", "kind": "decision", "answer_data": [ "capability-to-interaction compatibility matrix", "fallback selection rule", "rejection reason code" ] } ], "data_elements": [ { "id": "de-capability-flags", "name": "capability_flags", "description": "Set of supported channel capabilities, modelled as independent booleans rather than as purpose codes.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-accessibility-feature", "name": "accessibility_feature", "description": "Coded assistive-communication characteristic of the endpoint, such as textphone.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-media-type-hint", "name": "media_type_hint", "description": "Media type hint for URI-valued endpoints, mirroring the vCard MEDIATYPE parameter.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Capabilities are boolean and coded attributes of the instance; the capability vocabulary is registered with IANA and referenced, so no separate artefact is warranted." } ] } ] }, { "id": "purpose-and-preference", "name": "Purpose, Audience and Preference", "description": "Why the channel exists, who may use it for what, how it ranks against sibling channels, and when and in which language it is reachable.", "rationale": "schema.org contactType, FHIR use, vCard TYPE and JSContact contexts all encode purpose, while PREF/rank encodes ordering; these are separate axes that are routinely conflated in practice and must be modelled distinctly.", "source_refs": [ "SRC-005", "SRC-004", "SRC-001", "SRC-002" ], "layers": [ { "id": "purpose-and-context", "name": "Purpose Classification and Audience Scope", "description": "Controlled classification of what the channel is for and the audience or territory it serves.", "source_refs": [ "SRC-005", "SRC-004", "SRC-002" ], "findings": [ { "id": "purpose-classification", "name": "Purpose and context vocabulary", "description": "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-002", "SRC-005" ], "questions": [ { "id": "pc-q-purpose", "text": "Which governed purpose codes apply to this endpoint, and may more than one apply at once?", "kind": "classification", "answer_data": [ "purpose code set", "multi-valued indicator", "governed vocabulary version" ] }, { "id": "pc-q-authority", "text": "Who governs the purpose vocabulary and by which procedure are new codes admitted?", "kind": "authority", "answer_data": [ "vocabulary owner", "extension procedure and review requirement", "namespace for local extensions" ] }, { "id": "pc-q-conflation", "text": "How are lifecycle-flavoured or device-flavoured codes such as old and mobile prevented from overloading purpose?", "kind": "constraint", "answer_data": [ "mapping rule from external code to purpose plus state plus capability", "prohibited local code list", "migration note for legacy values" ] } ], "data_elements": [ { "id": "de-purpose-code", "name": "purpose_codes", "description": "Governed purpose or context codes for the endpoint (for example work, private, billing, delivery, support, emergency).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "de-purpose-vocab", "name": "purpose_vocabulary_ref", "description": "Reference to the governed vocabulary and version from which purpose codes are drawn.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "purpose-code-list", "name": "Contact purpose code list", "description": "Governed, versioned code list of purpose/context values with definitions, deprecations and crosswalk columns to FHIR use, vCard TYPE, JSContact contexts and schema.org contactType.", "media_or_form": [ "controlled code list", "crosswalk table" ], "serial": true, "identity_strategy": "Namespaced vocabulary IRI plus semantic version; individual codes carry stable code IRIs that are never reused after deprecation.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "audience-and-use-scope", "name": "Audience, territory and permitted use scope", "description": "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.", "source_refs": [ "SRC-005", "SRC-019" ], "questions": [ { "id": "aus-q-audience", "text": "Which audience is this endpoint published to, and is it internal, partner-facing or public?", "kind": "access", "answer_data": [ "audience class", "publication surface list", "internal-only indicator" ] }, { "id": "aus-q-area", "text": "Which served area or jurisdiction limits the endpoint's applicability?", "kind": "spatial", "answer_data": [ "area-served reference to the geography model", "jurisdiction code", "toll or accessibility restriction note" ] }, { "id": "aus-q-subject-matter", "text": "Which products, services or case types is this endpoint scoped to handle?", "kind": "relationship", "answer_data": [ "supported product or service references", "excluded subject matter", "routing note for out-of-scope contacts" ] } ], "data_elements": [ { "id": "de-audience-class", "name": "audience_class", "description": "Audience for which the endpoint is intended (public, partner, internal, restricted).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-area-served", "name": "area_served_ref", "description": "Reference to the geographic area or jurisdiction the endpoint serves, resolved in an external geography model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-product-supported", "name": "product_supported_ref", "description": "Reference to products or service lines the endpoint supports.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Audience and territory are coded values and outbound references; the geographic and product definitions belong to external models, so no artefact is produced here." } ] }, { "id": "preference-and-availability", "name": "Preference Order and Reachability Window", "description": "Relative ordering among sibling endpoints and the temporal and linguistic conditions under which the endpoint is usable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-011" ], "findings": [ { "id": "preference-rank", "name": "Preference ranking among sibling endpoints", "description": "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "pr-q-rank", "text": "What is the preference value of this endpoint and within which comparison set is it interpreted?", "kind": "measurement", "answer_data": [ "preference integer", "comparison set definition (subject plus medium plus purpose)", "direction convention statement" ] }, { "id": "pr-q-ties", "text": "How are equal or absent preference values resolved deterministically?", "kind": "decision", "answer_data": [ "tie-break ordering rule", "treatment of missing preference", "deterministic fallback key" ] }, { "id": "pr-q-who-sets", "text": "Who may set preference — the subject, the steward, or an inference process — and how is that recorded?", "kind": "ownership", "answer_data": [ "preference author role", "assertion basis (declared or inferred)", "assertion timestamp" ] }, { "id": "pr-q-purpose-scope", "text": "Does preference vary by purpose, so that one endpoint is preferred for billing and another for support?", "kind": "constraint", "answer_data": [ "per-purpose preference entries", "default preference", "conflict rule between global and per-purpose preference" ] } ], "data_elements": [ { "id": "de-preference-rank", "name": "preference_rank", "description": "Integer preference where lower values are more preferred, scoped to sibling endpoints of the same subject and medium.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "de-preference-scope", "name": "preference_scope", "description": "Declared comparison set within which the rank is meaningful.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-preference-basis", "name": "preference_basis", "description": "Whether the preference was declared by the subject, set by a steward, or inferred.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Preference is a single relative integer plus scope and basis qualifiers held on the instance; materialising an ordering document would freeze a value that is only meaningful relative to the live sibling set." }, { "id": "availability-and-language", "name": "Availability window, time zone and languages", "description": "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.", "source_refs": [ "SRC-005", "SRC-001", "SRC-011" ], "questions": [ { "id": "al-q-hours", "text": "During which published window is this endpoint attended, and which schedule record defines it?", "kind": "temporal", "answer_data": [ "schedule reference in the external availability model", "attended or unattended indicator", "exception-day handling reference" ] }, { "id": "al-q-timezone", "text": "Which time zone governs interpretation of the endpoint's availability and of contact attempts?", "kind": "temporal", "answer_data": [ "IANA time-zone identifier or UTC offset", "source of the time-zone assertion", "effective date of the assertion" ] }, { "id": "al-q-language", "text": "Which language tags may be used at this endpoint, and which is preferred?", "kind": "interoperability", "answer_data": [ "BCP 47 language tags", "preferred tag", "tag validation status against the subtag registry" ] } ], "data_elements": [ { "id": "de-hours-ref", "name": "hours_available_ref", "description": "Reference to an availability schedule owned by an external schedule model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-timezone", "name": "operative_time_zone", "description": "Time zone identifier or UTC offset governing the endpoint's attended window.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-available-language", "name": "available_languages", "description": "BCP 47 language tags usable at the endpoint, with an optional preferred tag.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "These are bindings to externally governed vocabularies and schedule records; producing a local schedule artefact would duplicate the availability model that owns opening-hours semantics." } ] } ] }, { "id": "validity-state-and-evidence", "name": "Validity, Lifecycle State and Evidence", "description": "Whether the endpoint is currently usable: its period and state, its succession or reassignment, its syntactic conformance, its verification state and its observed reachability.", "rationale": "FHIR period, vCard REV, the FCC reassigned-numbers safe harbour and RFC 3463 status classes together show that a contact point is a time-bounded assertion whose truth decays; state and evidence must be first-class rather than derived at read time.", "source_refs": [ "SRC-004", "SRC-015", "SRC-012", "SRC-013" ], "layers": [ { "id": "lifecycle-and-period", "name": "Lifecycle State, Period and Succession", "description": "Time-bounded validity of the endpoint binding, its state transitions, and what happens when a value is reassigned to someone else.", "source_refs": [ "SRC-004", "SRC-015", "SRC-013" ], "findings": [ { "id": "lifecycle-state", "name": "Lifecycle state and validity period", "description": "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.", "source_refs": [ "SRC-004", "SRC-001" ], "questions": [ { "id": "ls-q-state", "text": "What is the current lifecycle state of this contact-point binding and which transition produced it?", "kind": "state", "answer_data": [ "state code", "previous state", "transition reason code and actor" ] }, { "id": "ls-q-period", "text": "From when until when is this binding asserted to be valid?", "kind": "lifecycle", "answer_data": [ "period start timestamp", "period end timestamp or open-ended flag", "basis for the end date" ] }, { "id": "ls-q-transitions", "text": "Which state transitions are permitted, and which require evidence or approval before they take effect?", "kind": "process", "answer_data": [ "allowed transition matrix", "evidence requirement per transition", "approving role" ] }, { "id": "ls-q-history", "text": "Are superseded bindings retained as history, and for how long are historical bindings readable?", "kind": "retention", "answer_data": [ "history retention rule reference", "readability class for historical bindings", "owner of the retention decision" ] } ], "data_elements": [ { "id": "de-lifecycle-state", "name": "lifecycle_state", "description": "Coded state of the binding (proposed, active, suspended, superseded, retired).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-valid-from", "name": "valid_from", "description": "Timestamp from which the binding is asserted valid, recorded as an RFC 3339 value with seconds and explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-017" ] }, { "id": "de-valid-to", "name": "valid_to", "description": "Timestamp after which the binding is no longer asserted valid.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "State and period are inline scalar assertions on the instance; the transition history is a record-versioning concern handled by the storage projection and the adopting Dimension's records model rather than by a document produced here." }, { "id": "succession-and-reassignment", "name": "Succession, porting and reassignment to a different subject", "description": "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.", "source_refs": [ "SRC-015", "SRC-013", "SRC-012" ], "questions": [ { "id": "sr-q-successor", "text": "Which endpoint supersedes this one for the same subject and purpose?", "kind": "relationship", "answer_data": [ "successor contact-point reference", "supersession reason", "effective timestamp of supersession" ] }, { "id": "sr-q-reassignment", "text": "What signal indicates the address value may now belong to a different subject, and what state change does it force?", "kind": "event", "answer_data": [ "reassignment or disconnection signal source", "signal observation timestamp", "forced state transition (suspend or retire)" ] }, { "id": "sr-q-porting", "text": "How are porting, SIM change or mailbox-moved signals recorded without asserting they were evaluated by this model?", "kind": "evidence", "answer_data": [ "signal type code", "external evidence reference", "recording timestamp and recorder" ] }, { "id": "sr-q-safe-harbour", "text": "Which external check was performed before use, and what did it return?", "kind": "provenance", "answer_data": [ "external check reference identifier", "check result and timestamp", "checking party" ] } ], "data_elements": [ { "id": "de-successor-ref", "name": "supersedes_or_superseded_by", "description": "References linking an endpoint to its predecessor or successor for the same subject and purpose.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-reassignment-signal", "name": "reassignment_signal", "description": "Recorded signal that the value may have been disconnected, ported or reassigned, with its external evidence pointer.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Only the summarised signal and its pointer are held here; the reassigned-numbers query, its result record and any liability determination are produced and retained by external authorities and the adopting Dimension's compliance model." } ] }, { "id": "validation-and-evidence", "name": "Validation, Verification and Reachability Evidence", "description": "Syntactic conformance rules, recorded control-verification state, observed reachability and the resulting quality assessment.", "source_refs": [ "SRC-009", "SRC-010", "SRC-012", "SRC-013", "SRC-014" ], "findings": [ { "id": "syntactic-conformance", "name": "Syntactic and structural conformance", "description": "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.", "source_refs": [ "SRC-007", "SRC-009", "SRC-010", "SRC-004" ], "questions": [ { "id": "sc-q-rules", "text": "Which validation rules apply to this endpoint's medium, and at which version were they applied?", "kind": "validation", "answer_data": [ "rule profile identifier and version", "per-rule outcome", "validation timestamp" ] }, { "id": "sc-q-severity", "text": "Which validation failures block acceptance and which are recorded as warnings?", "kind": "constraint", "answer_data": [ "severity classification per rule", "acceptance threshold", "override authority" ] }, { "id": "sc-q-limits", "text": "What does passing validation explicitly not prove about the endpoint?", "kind": "definition", "answer_data": [ "statement separating well-formedness from reachability and ownership", "known false-positive classes", "required follow-up checks" ] } ], "data_elements": [ { "id": "de-validation-status", "name": "validation_status", "description": "Outcome of syntactic and structural validation for the endpoint value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-validation-findings", "name": "validation_findings", "description": "Per-rule findings with severity, produced when the value was validated.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-validated-at", "name": "validated_at", "description": "Observation time at which validation was performed, in RFC 3339 form with seconds and explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "validation-rule-profile", "name": "Channel validation rule profile", "description": "Versioned machine-readable profile of syntactic and structural validation rules per medium and region, with severities and rule provenance to the governing standard.", "media_or_form": [ "machine-readable rule profile", "rule catalogue table" ], "serial": true, "identity_strategy": "Profile identifier assigned by the adopting Dimension plus semantic version; each rule carries a stable rule identifier and a citation to its governing standard.", "source_refs": [ "SRC-007", "SRC-009", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "control-verification-state", "name": "Recorded control-verification state", "description": "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.", "source_refs": [ "SRC-013", "SRC-002" ], "questions": [ { "id": "cvs-q-status", "text": "Is control of this endpoint currently verified, and which external verification record establishes that?", "kind": "evidence", "answer_data": [ "verification status code", "external verification record reference", "verifying party" ] }, { "id": "cvs-q-time", "text": "When was verification performed and when does it lapse?", "kind": "temporal", "answer_data": [ "verification event time", "recording or ingestion time", "expiry or revalidation due time" ] }, { "id": "cvs-q-invalidate", "text": "Which changes to the endpoint reset verification to unverified?", "kind": "lifecycle", "answer_data": [ "change classes that reset verification", "reset rule owner", "post-reset state" ] }, { "id": "cvs-q-boundary", "text": "What is this model forbidden from recording about the verification ceremony itself?", "kind": "security", "answer_data": [ "prohibited fields such as codes, secrets and risk scores", "pointer-only recording rule", "owner of ceremony data" ] } ], "data_elements": [ { "id": "de-verification-status", "name": "verification_status", "description": "Recorded state of endpoint control verification (unverified, verified, lapsed, failed).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-verification-ref", "name": "verification_record_ref", "description": "Pointer to the externally owned verification record that substantiates the status.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-verified-at", "name": "verified_at", "description": "Event time of the verification outcome, distinct from the time this model recorded it.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Only a status, a pointer and timestamps are held; the verification evidence, one-time secrets and risk signals are owned by the identity and authentication model, and reproducing them here would create a second, unauthorised source of authentication evidence." }, { "id": "reachability-observation", "name": "Summarised reachability observations", "description": "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.", "source_refs": [ "SRC-012", "SRC-015" ], "questions": [ { "id": "ro-q-last", "text": "What was the last observed reachability outcome for this endpoint and when did it occur?", "kind": "state", "answer_data": [ "outcome class (success, transient failure, permanent failure)", "status code where available", "event time and observation time" ] }, { "id": "ro-q-threshold", "text": "Which observed outcomes force a state change, and after how many occurrences?", "kind": "constraint", "answer_data": [ "threshold rule per outcome class", "resulting state transition", "rule owner" ] }, { "id": "ro-q-evidence", "text": "Where is the underlying delivery or call evidence held, and how is it referenced without copying it?", "kind": "provenance", "answer_data": [ "evidence store reference", "evidence record identifiers", "retention owner of the evidence" ] } ], "data_elements": [ { "id": "de-reachability-state", "name": "reachability_state", "description": "Latest summarised reachability classification for the endpoint.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-last-outcome-code", "name": "last_outcome_code", "description": "Standard status code of the most recent observation, such as an enhanced mail status code.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-observation-refs", "name": "observation_evidence_refs", "description": "Pointers to externally owned delivery, bounce or call-disposition evidence records.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "The model holds a rolled-up state and evidence pointers only; delivery attempts, bounce processing and their audit trails are executed and retained by the messaging and audit models, which own those semantics." }, { "id": "quality-and-confidence", "name": "Quality, staleness and confidence assessment", "description": "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.", "source_refs": [ "SRC-014", "SRC-004", "SRC-012" ], "questions": [ { "id": "qc-q-metrics", "text": "Which quality metrics are computed for this endpoint and how is each defined?", "kind": "measurement", "answer_data": [ "metric definitions (completeness, staleness, duplication, failure rate)", "current metric values", "computation timestamp" ] }, { "id": "qc-q-staleness", "text": "How long since the endpoint was last confirmed by the subject or by a successful interaction, and when does it become stale?", "kind": "quality", "answer_data": [ "last confirmation time", "staleness threshold by medium and purpose", "current staleness classification" ] }, { "id": "qc-q-action", "text": "Which quality thresholds trigger review, revalidation or suppression from selection?", "kind": "decision", "answer_data": [ "threshold-to-action mapping", "action owner", "record of the triggered action reference" ] } ], "data_elements": [ { "id": "de-confidence", "name": "confidence_value", "description": "Recorded confidence that the binding is currently correct, with its computation basis.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-last-confirmed", "name": "last_confirmed_at", "description": "Most recent time the binding was confirmed by the subject or by a successful interaction.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-quality-flags", "name": "quality_flags", "description": "Coded quality conditions such as stale, duplicate-suspect or unverifiable.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Quality values are computed attributes stored on the instance; publishing a quality report would duplicate the adopting Dimension's data-quality reporting model, which owns metric governance and reporting cadence." } ] } ] }, { "id": "provenance-authority-and-disclosure", "name": "Provenance, Stewardship and Disclosure", "description": "Where the endpoint came from, who is accountable for it, which externally owned permissions restrict it, and how sensitive its disclosure is.", "rationale": "vCard SOURCE and REV, JSContact created/updated and the GDPR and FCC permission regimes make provenance and restriction references mandatory context for any lawful use of a contact point.", "source_refs": [ "SRC-001", "SRC-002", "SRC-014", "SRC-015" ], "layers": [ { "id": "provenance-and-stewardship", "name": "Capture Provenance and Stewardship", "description": "How the endpoint entered the record, from whom, and who is accountable for maintaining it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-017" ], "findings": [ { "id": "capture-provenance", "name": "Capture provenance and time separation", "description": "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-017" ], "questions": [ { "id": "cp-q-source", "text": "From which source system, form or interaction was this endpoint captured?", "kind": "provenance", "answer_data": [ "source system or directory URI", "capture channel or form reference", "capturing actor" ] }, { "id": "cp-q-assertion", "text": "Who asserted the endpoint, and is the assertion first-party, third-party or inferred?", "kind": "authority", "answer_data": [ "asserting party reference", "assertion basis code", "supporting document reference where third-party" ] }, { "id": "cp-q-times", "text": "What are the event time and the observation or ingestion time of this assertion, and why do they differ?", "kind": "temporal", "answer_data": [ "assertion event time", "observation or ingestion time", "reason for divergence such as batch load or backfill" ] } ], "data_elements": [ { "id": "de-source-ref", "name": "source_ref", "description": "Reference to the originating system, directory or capture interaction.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-assertion-basis", "name": "assertion_basis", "description": "Whether the endpoint was self-asserted, third-party supplied, or inferred.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-asserted-at", "name": "asserted_at", "description": "Event time of the assertion, recorded separately from ingestion time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-ingested-at", "name": "ingested_at", "description": "Time this model's record observed or ingested the assertion.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Provenance is a set of references and timestamps on the instance; capture forms, consent receipts and source extracts are records of other models and are pointed at, not copied." }, { "id": "stewardship-and-master-system", "name": "Stewardship, master system and change authority", "description": "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.", "source_refs": [ "SRC-001", "SRC-014" ], "questions": [ { "id": "sms-q-master", "text": "Which system is authoritative for this endpoint's value, and which systems merely hold copies?", "kind": "ownership", "answer_data": [ "master system identifier", "replica system list", "synchronisation direction" ] }, { "id": "sms-q-steward", "text": "Which role is accountable for correcting and revalidating this endpoint?", "kind": "ownership", "answer_data": [ "steward role name", "escalation contact reference", "accountability scope" ] }, { "id": "sms-q-override", "text": "Who may override an automated suspension or a validation failure, and what must be recorded?", "kind": "authority", "answer_data": [ "override authority role", "required justification fields", "override reference identifier" ] } ], "data_elements": [ { "id": "de-master-system", "name": "master_system_ref", "description": "Designated authoritative system for the endpoint value.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-steward-role", "name": "steward_role", "description": "Role accountable for the accuracy and maintenance of this contact point.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Stewardship is expressed as role and system references on the instance; the role catalogue and the system register are governed by the adopting Dimension and are referenced rather than restated." } ] }, { "id": "permission-and-disclosure", "name": "Restriction References and Disclosure Sensitivity", "description": "Externally owned permission decisions that restrict use, and the sensitivity class governing who may see the endpoint.", "source_refs": [ "SRC-014", "SRC-015", "SRC-013" ], "findings": [ { "id": "permission-reference-binding", "name": "Binding to externally owned permission and suppression decisions", "description": "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.", "source_refs": [ "SRC-014", "SRC-015" ], "questions": [ { "id": "prb-q-refs", "text": "Which permission, objection or suppression records currently apply to this endpoint?", "kind": "relationship", "answer_data": [ "permission record references", "record type and issuing regime", "effective dates" ] }, { "id": "prb-q-state", "text": "What derived restriction state does this model carry, and which purposes does it block?", "kind": "state", "answer_data": [ "restriction state code", "blocked purpose codes", "state derivation timestamp and source record" ] }, { "id": "prb-q-staleness", "text": "How fresh must the referenced permission state be before an agent may rely on it?", "kind": "constraint", "answer_data": [ "maximum permitted age of the cached restriction state", "refresh trigger", "behaviour when the state is stale or unavailable" ] }, { "id": "prb-q-boundary", "text": "Which permission concepts must never be stored in this model?", "kind": "privacy", "answer_data": [ "excluded fields such as lawful basis, consent text and proof", "owning model reference", "fail-closed instruction on missing reference" ] } ], "data_elements": [ { "id": "de-permission-refs", "name": "permission_record_refs", "description": "References to externally owned consent, objection or suppression records applying to this endpoint.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-restriction-state", "name": "restriction_state", "description": "Derived, cached restriction state used as an input to channel selection.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-restriction-refreshed-at", "name": "restriction_refreshed_at", "description": "Time the cached restriction state was last refreshed from the owning model.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Only references and a cached derived state are held. Consent records, objection handling, suppression-list execution and the legal five-year retention of do-not-call requests belong to the permission and compliance models, which own their lifecycle and enforcement." }, { "id": "disclosure-sensitivity", "name": "Disclosure sensitivity and safe-contact restrictions", "description": "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.", "source_refs": [ "SRC-014", "SRC-005", "SRC-013" ], "questions": [ { "id": "ds-q-class", "text": "What disclosure class applies to this endpoint and which default applies when it is unset?", "kind": "access", "answer_data": [ "disclosure class code", "restrictive default statement", "classifying authority" ] }, { "id": "ds-q-surfaces", "text": "On which publication surfaces may this endpoint appear, and which are explicitly forbidden?", "kind": "access", "answer_data": [ "permitted surface list", "forbidden surface list", "approval reference for public publication" ] }, { "id": "ds-q-safe-contact", "text": "Are there handling restrictions such as no voicemail, no message content or contact only within a window?", "kind": "exception", "answer_data": [ "handling restriction codes", "reason category recorded at an appropriate sensitivity", "review date for the restriction" ] } ], "data_elements": [ { "id": "de-disclosure-class", "name": "disclosure_class", "description": "Classification governing how widely the endpoint may be disclosed (public, restricted, unlisted, sealed).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "de-handling-restrictions", "name": "handling_restrictions", "description": "Coded safe-contact handling restrictions attached to the endpoint.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Disclosure class and handling restrictions are coded attributes consumed by the access layer; the access policy itself and its evaluation are owned by the adopting Dimension's access-governance model." } ] } ] }, { "id": "relations-and-interoperability", "name": "Relations, Alternates and Interoperability", "description": "How this mixin links to other models, how alternate representations of one logical endpoint are grouped, and how the model projects onto and receives from external standards.", "rationale": "RFC 9555 defines an explicit, partly lossy conversion between JSContact and vCard, and FHIR, schema.org and the W3C Note each carry different vocabularies; interoperability therefore needs an owned crosswalk and an explicit conflict policy.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-016" ], "layers": [ { "id": "model-relationships", "name": "Model Relationships and Alternate Representations", "description": "Outbound bindings to sibling models and the grouping of alternate or localised representations of the same logical endpoint.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ], "findings": [ { "id": "related-model-bindings", "name": "Outbound bindings to sibling models", "description": "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.", "source_refs": [ "SRC-004", "SRC-005", "SRC-014", "SRC-013" ], "questions": [ { "id": "rmb-q-links", "text": "Which sibling models does this contact point reference, and with what link type?", "kind": "composition", "answer_data": [ "target model identifiers", "link type per target", "required or optional flag" ] }, { "id": "rmb-q-owned", "text": "For each link, which concepts remain owned by the target and must not be modelled here?", "kind": "authority", "answer_data": [ "target-owned concept list per link", "local carry-only fields", "boundary citation" ] }, { "id": "rmb-q-unresolvable", "text": "How should an agent behave when a referenced target record cannot be resolved?", "kind": "exception", "answer_data": [ "fail-open or fail-closed rule per link", "degraded-mode behaviour", "escalation route" ] } ], "data_elements": [ { "id": "de-link-type", "name": "outbound_link_type", "description": "Typed relation to a target model (mix-in, reference, align).", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-link-target", "name": "outbound_link_target", "description": "Identifier of the target model or record for the relation.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Bindings are typed references held on the instance and mirrored in the model's composition ledger; materialising them as artefacts would create a second, divergent copy of the relation contract." }, { "id": "alternate-representation-grouping", "name": "Alternates, localisation and grouping of one logical endpoint", "description": "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-011" ], "questions": [ { "id": "arg-q-alternate", "text": "Which records are alternative representations of the same logical endpoint rather than distinct endpoints?", "kind": "identity", "answer_data": [ "logical endpoint group identifier", "member record references", "basis for grouping" ] }, { "id": "arg-q-localisation", "text": "Which endpoint labels are localised, and under which language tags?", "kind": "interoperability", "answer_data": [ "localised label values", "BCP 47 tag per localisation", "default label" ] }, { "id": "arg-q-dedup", "text": "When do two endpoint records with equal canonical values count as duplicates that must be merged?", "kind": "validation", "answer_data": [ "duplicate criteria including subject, purpose and context", "merge or keep-both decision rule", "surviving record selection rule" ] } ], "data_elements": [ { "id": "de-logical-group-id", "name": "logical_endpoint_group_id", "description": "Identifier grouping records that represent one logical endpoint in alternate or localised form.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-localised-labels", "name": "localised_labels", "description": "Language-tagged labels for the endpoint, keyed by BCP 47 tag.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Grouping and localisation are inline keys and maps on the records themselves; there is no separate deliverable, and the language subtag registry that governs the keys is external." } ] }, { "id": "interoperability-projection", "name": "Standards Alignment and Projection", "description": "Crosswalks to external contact standards, export projections, and the policy for irreconcilable vocabulary conflicts.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-016", "SRC-019" ], "findings": [ { "id": "standards-crosswalk", "name": "Crosswalk and export projections", "description": "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.", "source_refs": [ "SRC-003", "SRC-001", "SRC-002", "SRC-004", "SRC-005" ], "questions": [ { "id": "scw-q-mapping", "text": "How does each local element map to the corresponding element in each target standard?", "kind": "interoperability", "answer_data": [ "element-level mapping rows", "target standard and version", "unmapped element list" ] }, { "id": "scw-q-loss", "text": "Which information is lost or approximated in each projection, and is a round trip faithful?", "kind": "quality", "answer_data": [ "loss profile per target", "round-trip fidelity statement", "mitigation such as extension parameters" ] }, { "id": "scw-q-conformance", "text": "What evidence would be required before claiming conformance rather than alignment to a target standard?", "kind": "evidence", "answer_data": [ "conformance test evidence requirement", "current claim status (alignment only)", "test artefact reference" ] } ], "data_elements": [ { "id": "de-mapping-target", "name": "mapping_target", "description": "Identifier and version of the external standard a projection targets.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-loss-profile", "name": "projection_loss_profile", "description": "Declared information loss for a given projection direction.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "standards-crosswalk-table", "name": "Contact point standards crosswalk", "description": "Element-level crosswalk between this model and vCard 4.0, JSContact, FHIR ContactPoint, schema.org ContactPoint and the W3C vCard Ontology, including unmapped elements and loss annotations.", "media_or_form": [ "mapping table", "machine-readable mapping document" ], "serial": true, "identity_strategy": "Crosswalk identifier plus semantic version; each row cites the target standard version it was validated against.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-016" ] }, { "id": "contact-card-projection", "name": "Contact card projection", "description": "Exported projection of a subject's contact points in an interchange form such as vCard 4.0, jCard or JSContact, produced for exchange or portability and stamped with its loss profile.", "media_or_form": [ "interchange contact card", "structured export payload" ], "serial": true, "identity_strategy": "Projection identifier derived from the subject reference plus an export sequence number and generation timestamp; the projection is never treated as the identity of the underlying records.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "vocabulary-conflict-handling", "name": "Vocabulary conflicts and degradation policy", "description": "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-002", "SRC-005", "SRC-016", "SRC-019" ], "questions": [ { "id": "vch-q-conflicts", "text": "Which specific vocabulary conflicts affect this endpoint's classification, and how is each recorded?", "kind": "interoperability", "answer_data": [ "conflict entries with the conflicting standards", "local resolution decision", "unresolved marker where no resolution is defensible" ] }, { "id": "vch-q-degrade", "text": "How does an export degrade when the target vocabulary cannot express a local value?", "kind": "decision", "answer_data": [ "degradation rule per target", "substituted or omitted value", "warning emitted with the export" ] }, { "id": "vch-q-normative", "text": "Which alignments rest on normative sources and which on non-normative notes or consumer practice?", "kind": "authority", "answer_data": [ "normative status per alignment", "citation and version", "confidence rating" ] } ], "data_elements": [ { "id": "de-conflict-entry", "name": "vocabulary_conflict_entry", "description": "Recorded conflict between external vocabularies affecting a local field, with resolution status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-alignment-status", "name": "alignment_normative_status", "description": "Whether an alignment target is normative, non-normative or consumer practice.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "Conflict entries are records held with the model and surfaced in the coverage report; they annotate the crosswalk artefact rather than forming a separate deliverable." } ] } ] }, { "id": "operating-surface", "name": "Agent Operating Surface and Disposition", "description": "How an agent uses, changes and eventually disposes of contact-point records, expressed as decision inputs and record rules rather than as enforcement.", "rationale": "An agent needs a deterministic way to choose a channel and to change one safely; NIST treats changing a registered telephone number as a binding event, and GDPR Art. 17 and the FCC five-year rule create competing disposition obligations that must be surfaced, not silently resolved.", "source_refs": [ "SRC-013", "SRC-014", "SRC-015" ], "layers": [ { "id": "agent-operating-procedures", "name": "Selection Inputs and Change Procedure", "description": "The data an agent needs to choose a channel for a purpose, and the controlled procedure for adding, correcting or replacing one.", "source_refs": [ "SRC-001", "SRC-004", "SRC-013", "SRC-015" ], "findings": [ { "id": "channel-selection-inputs", "name": "Inputs for selecting a channel for a purpose", "description": "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-015", "SRC-005" ], "questions": [ { "id": "csi-q-filters", "text": "Which filters must be applied before an endpoint is eligible for a given purpose?", "kind": "decision", "answer_data": [ "ordered filter list", "data element consulted per filter", "fail-closed default when an input is missing" ] }, { "id": "csi-q-order", "text": "How are eligible endpoints ordered, and what is returned when none is eligible?", "kind": "process", "answer_data": [ "ordering key sequence", "empty-result behaviour", "fallback or escalation reference" ] }, { "id": "csi-q-explain", "text": "What explanation data must accompany a selection so the decision is reproducible?", "kind": "evidence", "answer_data": [ "inputs snapshot with their timestamps", "rule version applied", "excluded candidates with exclusion reasons" ] } ], "data_elements": [ { "id": "de-eligibility-inputs", "name": "eligibility_inputs", "description": "Snapshot of the state, restriction, capability and availability values consulted for a selection.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-selection-order", "name": "selection_order_key", "description": "Deterministic ordering key sequence used to rank eligible endpoints.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "This finding supplies decision inputs and an ordering rule only; the contact attempt, its authorisation and its audit record are executed and retained by the messaging, permission and audit models, so no selection or execution artefact is produced here." }, { "id": "change-and-correction", "name": "Adding, correcting and replacing an endpoint", "description": "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.", "source_refs": [ "SRC-013", "SRC-014", "SRC-001" ], "questions": [ { "id": "cac-q-kind", "text": "Is this change a correction of a mistyped value, a replacement by a new endpoint, or a purpose reclassification?", "kind": "process", "answer_data": [ "change kind code", "prior and new values with their canonical forms", "effect on the predecessor record" ] }, { "id": "cac-q-authority", "text": "On whose instruction and under whose authority was the change made?", "kind": "authority", "answer_data": [ "instructing party reference", "executing actor and role", "instruction evidence reference" ] }, { "id": "cac-q-side-effects", "text": "Which dependent states must be reset or re-derived when the value changes?", "kind": "constraint", "answer_data": [ "verification reset rule", "reachability and quality reset rule", "preference and restriction re-derivation requirement" ] }, { "id": "cac-q-notification", "text": "Which downstream models must be informed that the endpoint changed, and by what mechanism?", "kind": "relationship", "answer_data": [ "dependent model list", "notification or republication mechanism", "acknowledgement expectation" ] } ], "data_elements": [ { "id": "de-change-kind", "name": "change_kind", "description": "Classification of the change applied to the endpoint record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-change-instruction-ref", "name": "change_instruction_ref", "description": "Reference to the instruction or request that authorised the change.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-changed-at", "name": "changed_at", "description": "Time the change was applied to this model's record, with the instruction time recorded separately.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [], "inline_only_rationale": "Change data is inline versioned record content; the immutable change log and any authentication of the requester are owned by the audit and identity models respectively and are referenced rather than reproduced." } ] }, { "id": "retention-and-disposition", "name": "Retention and Disposition of Contact-Point Records", "description": "How long contact-point records persist, what remains after erasure, and who owns the execution of disposition.", "source_refs": [ "SRC-014", "SRC-015" ], "findings": [ { "id": "retention-and-disposition-binding", "name": "Retention class, erasure and residual tombstone", "description": "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.", "source_refs": [ "SRC-014", "SRC-015" ], "questions": [ { "id": "rdb-q-class", "text": "Which retention class applies to this contact-point record and what triggers its disposition?", "kind": "retention", "answer_data": [ "retention class code", "trigger event and retention period", "policy reference and owner" ] }, { "id": "rdb-q-residual", "text": "What remains after erasure, and does the residue permit re-contact?", "kind": "privacy", "answer_data": [ "tombstone field list", "irreversibility statement for the value", "re-contact impossibility assertion" ] }, { "id": "rdb-q-conflict", "text": "How is an erasure request reconciled with a suppression obligation that requires keeping a key?", "kind": "exception", "answer_data": [ "conflict resolution rule", "owning model of the retained suppression key", "record of the decision reference" ] }, { "id": "rdb-q-execution", "text": "Who executes disposition across replicas and projections once it is decided?", "kind": "ownership", "answer_data": [ "executing role or system", "replica and export propagation list", "completion evidence reference" ] } ], "data_elements": [ { "id": "de-retention-class", "name": "retention_class", "description": "Retention classification assigned to the contact-point record by the governing policy.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "de-disposition-state", "name": "disposition_state", "description": "Current disposition state of the record (retained, minimised, tombstoned, purged).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-disposed-at", "name": "disposed_at", "description": "Time disposition was applied, recorded separately from the time it was decided.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "disposition-tombstone", "name": "Contact point disposition tombstone", "description": "Minimal residual record left after erasure of a contact point: instance identifier, subject reference class, medium, disposition state, decision reference and timestamps, with the address value irreversibly removed.", "media_or_form": [ "minimal residual record", "structured disposition entry" ], "serial": false, "identity_strategy": "Retains the original contact_point_id so references remain resolvable; carries no recoverable address value and no derived match key.", "source_refs": [ "SRC-014", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-attach-contact-point", "name": "Attach contact point to subject", "description": "Create the mixin binding between a subject record and a new endpoint, establishing identity, medium and initial state.", "inputs": [ "subject reference and subject kind", "raw address value and asserted medium", "capture provenance including source and assertion basis" ], "outputs": [ "contact-point instance with resolved identifier", "initial lifecycle state and ingestion timestamp" ], "preconditions": [ "subject record resolves in the owning party model", "a medium is supplied or derivable, satisfying the mandatory-medium rule", "identity priority has been applied to select the identifier" ], "effects": [ "a new contact-point record exists in proposed or active state", "source instance identifiers are recorded for later merge" ], "source_refs": [ "SRC-004", "SRC-001", "SRC-002" ] }, { "id": "fn-canonicalise-value", "name": "Canonicalise address value", "description": "Derive the canonical storage form and the display form of an address value from its raw captured form using the versioned canonicalisation ruleset.", "inputs": [ "raw address value", "medium code", "region or phone-context hint" ], "outputs": [ "canonical value", "display value", "canonical match key" ], "preconditions": [ "the applicable ruleset version is resolvable", "for local telephone numbers a phone-context is supplied" ], "effects": [ "canonical and display forms are stored alongside the original captured value", "the ruleset version used is recorded for reproducibility" ], "source_refs": [ "SRC-007", "SRC-008", "SRC-009", "SRC-010" ] }, { "id": "fn-validate-syntax", "name": "Validate address syntax", "description": "Evaluate the endpoint value against the medium's syntactic and structural rule profile and record per-rule findings with severities.", "inputs": [ "canonical value and medium code", "validation rule profile version" ], "outputs": [ "validation status", "per-rule findings with severity", "validation observation timestamp" ], "preconditions": [ "a canonical value exists", "a rule profile exists for the medium" ], "effects": [ "validation status and findings are recorded on the instance", "blocking failures prevent transition to active state" ], "source_refs": [ "SRC-009", "SRC-010", "SRC-004" ] }, { "id": "fn-classify-and-rank", "name": "Classify purpose and set preference", "description": "Assign governed purpose codes, audience and area scope, and set the preference rank within the correct comparison set.", "inputs": [ "governed purpose vocabulary version", "proposed purpose codes and audience class", "proposed preference value and its basis" ], "outputs": [ "stored purpose codes and audience scope", "stored preference rank with declared scope" ], "preconditions": [ "purpose codes exist in the governed vocabulary version", "the comparison set of sibling endpoints is known" ], "effects": [ "purpose and preference are recorded with their author and basis", "sibling ranks are re-checked for ties under the declared tie-break rule" ], "source_refs": [ "SRC-005", "SRC-004", "SRC-001", "SRC-002" ] }, { "id": "fn-record-verification", "name": "Record control-verification assertion", "description": "Record the outcome of an externally performed verification of subject control over the endpoint, as a status, pointer and timestamps.", "inputs": [ "external verification record reference", "outcome code and verifying party", "verification event time" ], "outputs": [ "updated verification status", "expiry or revalidation due time" ], "preconditions": [ "the referenced verification record resolves in the identity model", "no secret, code or risk score is included in the payload" ], "effects": [ "verification status and pointer are stored with event and ingestion times separated", "channel selection may treat the endpoint as verified until expiry" ], "source_refs": [ "SRC-013", "SRC-017" ] }, { "id": "fn-record-reachability", "name": "Record reachability observation", "description": "Record a summarised reachability outcome derived from an externally owned delivery or call-disposition evidence record.", "inputs": [ "outcome class and standard status code", "evidence record reference", "event time and observation time" ], "outputs": [ "updated reachability state", "threshold evaluation result" ], "preconditions": [ "the evidence record reference resolves in the owning messaging model", "the outcome class distinguishes transient from permanent failure" ], "effects": [ "the rolled-up reachability state is updated", "a permanent-failure threshold may trigger a lifecycle transition to suspended" ], "source_refs": [ "SRC-012", "SRC-017" ] }, { "id": "fn-supersede-contact-point", "name": "Supersede or retire contact point", "description": "Close the validity period of an endpoint binding, record its successor where one exists, and set the terminal state.", "inputs": [ "reason code and effective timestamp", "successor contact-point reference where applicable", "authorising role" ], "outputs": [ "updated lifecycle state and period end", "supersession relationship record" ], "preconditions": [ "the transition is permitted by the transition matrix", "required evidence for the transition is referenced" ], "effects": [ "the endpoint stops being eligible for selection from the effective time", "dependent models are notified that the binding changed" ], "source_refs": [ "SRC-004", "SRC-015", "SRC-013" ] }, { "id": "fn-rank-candidates", "name": "Rank candidate channels for a purpose", "description": "Return an ordered, explained list of eligible endpoints for a stated purpose, applying eligibility filters then the preference ordering. Decision support only: it neither authorises nor performs contact.", "inputs": [ "subject reference and purpose code", "required capabilities and evaluation time", "freshness bound for cached restriction state" ], "outputs": [ "ordered candidate list with ordering keys", "exclusion reasons for rejected candidates", "inputs snapshot for reproducibility" ], "preconditions": [ "restriction state is within the declared freshness bound or the call fails closed", "the ordering rule version is resolvable" ], "effects": [ "a reproducible ranking is produced without changing endpoint state", "no contact is initiated and no permission decision is made" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-015" ] }, { "id": "fn-project-contact-card", "name": "Project contact points to an interchange form", "description": "Generate a vCard 4.0, jCard, JSContact, FHIR or schema.org projection of a subject's contact points using the crosswalk, stamped with its loss profile.", "inputs": [ "subject reference and target standard with version", "disclosure filter for the requesting audience", "crosswalk version" ], "outputs": [ "projection payload", "declared loss profile and unmapped element list" ], "preconditions": [ "the disclosure class permits inclusion of each endpoint on the requested surface", "a crosswalk row exists for every included element or the element is listed as unmapped" ], "effects": [ "an export projection is produced without altering source records", "the projection records the crosswalk version used" ], "source_refs": [ "SRC-003", "SRC-001", "SRC-002", "SRC-004", "SRC-005" ] }, { "id": "fn-apply-disposition", "name": "Apply disposition decision", "description": "Apply a disposition decision made under the governing retention policy to this model's own contact-point records, leaving a tombstone where references must remain resolvable.", "inputs": [ "disposition decision reference and retention class", "scope of records and replicas", "decision and execution timestamps" ], "outputs": [ "updated disposition state", "tombstone record where applicable", "propagation list for replicas and projections" ], "preconditions": [ "the disposition decision was made by the policy owner named in the retention binding", "any suppression key required by law is retained in the permission model, not here" ], "effects": [ "the address value is irreversibly removed or minimised in this model's records", "the contact-point identifier remains resolvable for referential integrity" ], "source_refs": [ "SRC-014", "SRC-015" ] } ], "composition": [ { "target": "WM-PER-010 Person", "relation": "MIX-IN", "purpose": "Attach contact points to a person record. The person's identity, names and lifecycle stay in WM-PER-010; this model carries only the endpoint binding and its qualifiers.", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Organisation / Legal Entity world model (target not yet registered in this registry)", "relation": "MIX-IN", "purpose": "Attach the same mixin to organisations and organisational units, as vCard KIND org and FHIR Organization.telecom both require.", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Role / Function assignment model (target not yet registered)", "relation": "MIX-IN", "purpose": "Support role-based endpoints such as a shared support mailbox or duty phone without duplicating the endpoint per person.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "Postal / Physical Address model (target not yet registered)", "relation": "REFERENCE", "purpose": "Reference a place associated with an endpoint. Structured address components and geocoding remain in the address model, mirroring vCard's separation of ADR from TEL/EMAIL.", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "target": "Consent / Permission-to-contact model (target not yet registered)", "relation": "REFERENCE", "purpose": "Carry a reference to permission, objection and suppression records and a cached derived restriction state. Consent lifecycle, lawful basis, proof and suppression execution remain in the target.", "required": true, "source_refs": [ "SRC-014", "SRC-015" ] }, { "target": "Identity Verification / Authenticator model (target not yet registered)", "relation": "REFERENCE", "purpose": "Carry the verification status and a pointer to the verification record. Ceremonies, out-of-band secrets, restricted-authenticator policy and risk evaluation remain in the target.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "Communication Event / Message Delivery model (target not yet registered)", "relation": "REFERENCE", "purpose": "Reference delivery, bounce and call-disposition evidence that substantiates reachability state. Message content, delivery execution, retries and audit trails remain in the target.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Availability Schedule model (target not yet registered)", "relation": "REFERENCE", "purpose": "Bind an attended-hours schedule to an endpoint, as schema.org hoursAvailable does, without implementing schedule or exception-day algebra locally.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "Geographic Area / Jurisdiction model (target not yet registered)", "relation": "REFERENCE", "purpose": "Resolve the area served by an endpoint and the jurisdiction whose contact rules apply, without holding geometry.", "required": false, "source_refs": [ "SRC-005", "SRC-015" ] }, { "target": "IETF BCP 47 / IANA Language Subtag Registry", "relation": "ALIGN", "purpose": "Constrain available-language and localisation keys to valid language tags governed by an external registry.", "required": true, "source_refs": [ "SRC-011" ] }, { "target": "IETF vCard 4.0 (RFC 6350) and IANA vCard Elements registry", "relation": "ALIGN", "purpose": "Align property, parameter and type vocabularies and the PREF semantics with the registered vCard element set; extensions follow the registry's Expert Review procedure.", "required": true, "source_refs": [ "SRC-001", "SRC-006" ] }, { "target": "IETF JSContact (RFC 9553) and the vCard conversion rules (RFC 9555)", "relation": "ALIGN", "purpose": "Align object shapes and preference semantics with JSContact and adopt its normative, partly lossy conversion rules for projections.", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "target": "HL7 FHIR R5 ContactPoint datatype", "relation": "ALIGN", "purpose": "Align medium, use, rank and period with the FHIR datatype for healthcare interoperability, recording where the FHIR use value set conflates purpose, lifecycle and device class.", "required": false, "source_refs": [ "SRC-004", "SRC-018" ] }, { "target": "Schema.org ContactPoint", "relation": "ALIGN", "purpose": "Align purpose, area served, languages and availability with the published-web vocabulary, noting that major consumers read only a narrow subset.", "required": false, "source_refs": [ "SRC-005", "SRC-019" ] }, { "target": "W3C vCard Ontology (Interest Group Note)", "relation": "ALIGN", "purpose": "Provide an RDF projection target while recording that the Note is non-normative and therefore a weak alignment.", "required": false, "source_refs": [ "SRC-016" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name one accountable owner for WM-XCT-024 and one steward role per subject class the mixin is attached to, since the mixin has no standing outside a host subject.", "The Dimension must pin one governed purpose vocabulary version, one canonicalisation ruleset version and one validation rule profile version, and must publish the crosswalk it treats as current.", "The Dimension must declare which system is authoritative for each medium's values, and must own the retention policy and the permission model that this mixin references but does not execute.", "The Dimension must state its regional profile: which numbering, marketing and privacy regimes apply, so that region-specific rules such as do-not-call periods are not applied silently outside their jurisdiction." ], "namespace_guidance": "Local extension codes are namespaced under the adopting Dimension's own URI space (for example dimension-namespace:contact/purpose/); values drawn from external vocabularies keep their source namespace and version and are never re-minted locally. Unnamespaced vCard-style extensions must follow the IANA registry's Expert Review plus RFC Required procedure before being treated as standard.", "registry_links": [ "IANA vCard Elements registry for properties, parameters, value data types and parameter values (SRC-006)", "IANA Language Subtag Registry via BCP 47 for language tags (SRC-011)", "HL7 FHIR ContactPointSystem value set for medium codes used in healthcare exchange (SRC-018)" ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical record holds the canonical address value, the medium code and the original captured value; display forms are derived and never authoritative.", "Telephone values canonicalise to E.164 global form expressed as a tel URI; local numbers are only canonical when accompanied by a phone-context, and visual separators are removed before comparison.", "E-mail values canonicalise to addr-spec with NFC normalisation where non-ASCII characters are present; NFKC is not used, the domain is compared case-insensitively, and comparison uses the full address.", "Timestamps canonicalise to RFC 3339 with seconds and an explicit offset; an offset of -00:00 is reserved for UTC values whose local offset is unknown and is not equivalent to Z.", "Code values are stored as vocabulary identifier plus version plus code, never as bare display labels." ], "patch_rules": [ "Patches address one contact-point instance by its identifier; the canonical address value is replaced only through a change operation that records the change kind and instructing party.", "Any patch that alters the canonical value resets verification status to unverified and clears derived reachability and quality state.", "Patches to purpose, preference or disclosure class must carry the vocabulary or policy version they were authored against; a patch authored against a superseded version is rejected for review.", "Tombstoned records accept no patches other than disposition-state corrections made by the retention policy owner.", "Patches record ingestion time on this model's record and preserve any distinct event time supplied by the source." ], "compatibility_rules": [ "Adding an optional data element, a new capability flag or a new namespaced purpose code is backward compatible.", "Narrowing a vocabulary binding, changing preference direction, or making an optional element required is breaking and requires a new model version plus a migration note.", "Deprecated purpose or medium codes remain resolvable and are never reused for a different meaning; consumers must tolerate unknown codes by treating them as unclassified rather than discarding the record.", "Projections declare the target standard version they were produced against; a change in the crosswalk version that alters loss behaviour is a breaking change for downstream consumers." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the designated system of record for the contact-point instance", "Governed global identifier or IRI from a recognised registry or namespace where the endpoint is registered externally", "UUID or ULID assigned by the adopting Dimension when neither of the above exists", "The canonical address value is never an identifier; it may serve only as a non-authoritative match key, because the same value can be reassigned to a different subject" ], "timestamp_rule": "All time values use RFC 3339 with seconds and an explicit offset (Z or a numeric offset); -00:00 means the UTC value is known but the local offset is not. Event time (when the endpoint was asserted, verified, changed, superseded or observed) is recorded separately from observation or ingestion time (when this model's record learned of it), and both are stored whenever they differ; a date alone is never accepted where an instant is required.", "serial_naming_rule": "Serial artefacts (canonicalisation ruleset, purpose code list, validation rule profile, crosswalk, contact card projection) are named @ for governed rulesets and @# for generated projections; published versions are immutable, sequence numbers never repeat, and no date is used as the version identity.", "integrity_rule": "Every artefact records its generating function, the input record identifiers, the ruleset or crosswalk versions applied and a content digest; a projection whose source records have since changed is stale by definition and must be regenerated rather than edited, and a tombstone artefact must be verifiable as containing no recoverable address value." }, "policies": [ "Reference-only policy: for every REFERENCE and ALIGN target, this model stores identifiers, bindings and subject-specific parameters only; it never reproduces the target's lifecycle, evaluation, enforcement or audit-trail semantics, and a stale or unresolvable required reference causes selection to fail closed.", "Alignment-not-conformance policy: alignments to vCard, JSContact, FHIR, schema.org and the W3C Note are declared as mappings with loss profiles; no conformance claim is made without recorded test evidence, and conflicts between target vocabularies are recorded rather than silently resolved.", "Restrictive-default policy: an endpoint whose disclosure class is unset is treated as restricted, and an endpoint whose verification or restriction state cannot be resolved is not offered for purposes that require it.", "Value-is-not-identity policy: matching, merging and suppression on the address value alone is prohibited as an identity assertion, because numbers are ported and reassigned and mailboxes are recycled." ], "crud": { "read": [ "Reading a contact point returns the medium, canonical value, purpose, preference, state and the freshness of any cached restriction state, so a consumer can tell whether the value is safe to act on.", "Reads that will lead to contact must request the restriction state within its declared freshness bound; a stale bound yields a degraded response that omits the value.", "Bulk reads and exports are filtered by disclosure class and requesting audience before projection." ], "create": [ "Creation requires a resolvable subject reference, a medium, a canonicalised value and a capture-provenance block including assertion basis and ingestion time.", "A newly created endpoint starts unverified, with no preference implied by insertion order, and enters active state only after blocking validation rules pass.", "Creating a duplicate canonical value for the same subject and purpose requires an explicit merge or keep-both decision recorded against the duplicate criteria." ], "update": [ "Value changes are recorded as a typed change with instructing party and authority, and reset verification, reachability and quality state.", "Preference, purpose and disclosure updates record the vocabulary or policy version and the asserting role.", "Lifecycle transitions follow the declared transition matrix; automated suspensions arising from permanent-failure or reassignment signals may only be overridden by the named override authority with a recorded justification." ], "delete": [ "This model's own contact-point records are disposed of by minimisation and tombstoning rather than silent hard deletion: the address value and any derived match key are irreversibly removed while the contact-point identifier, subject reference class, medium, disposition state, decision reference and timestamps are retained so existing references stay resolvable.", "Hard purge of a tombstone is permitted only when the retention class has expired and no referencing model requires resolvability; purge propagates to replicas and cached projections listed in the propagation list.", "Execution of the deletion decision is not owned by this model: the retention schedule and erasure decision are owned by the adopting Dimension's retention policy and, for personal data, by the privacy or data-protection model applying GDPR Art. 17; any suppression key that must survive an erasure — such as the record supporting a do-not-call request honoured for five years under 47 CFR 64.1200(d)(6) — is retained by the permission model, never by this model.", "Deletion of the host subject cascades to disposition of its contact-point bindings, but the cascade decision and its audit record belong to the party and audit models; this model records only the resulting disposition state and time." ] }, "roles": [ { "name": "Model owner", "responsibilities": [ "Owns WM-XCT-024's specification, its boundaries and its version history", "Approves breaking changes, new alignments and conformance-evidence claims" ] }, { "name": "Contact data steward", "responsibilities": [ "Maintains accuracy, resolves duplicates and drives revalidation of stale endpoints", "Executes corrections and records the instructing party and authority" ] }, { "name": "Vocabulary and crosswalk custodian", "responsibilities": [ "Maintains the governed purpose code list, canonicalisation ruleset, validation rule profile and standards crosswalk with their versions", "Records vocabulary conflicts and deprecations, and blocks reuse of retired codes" ] }, { "name": "Privacy and retention officer", "responsibilities": [ "Sets retention classes and disclosure classes and adjudicates erasure requests against competing suppression obligations", "Owns the disposition decision that this model then applies to its own records" ] }, { "name": "Interoperability engineer", "responsibilities": [ "Builds and tests projections to vCard, JSContact, FHIR and schema.org and maintains their loss profiles", "Validates that imports preserve provenance and do not overwrite verified state with unverified assertions" ] } ], "access": { "default_rule": "Deny by default. Read access to a contact-point value requires an explicit grant naming the purpose; metadata such as medium, state and disclosure class may be readable at a lower level than the address value itself, and an endpoint with an unset disclosure class is treated as restricted.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Emergency or safety-of-life purposes may permit reading a restricted endpoint under a break-glass grant that is time-boxed and reason-coded.", "Safe-contact restrictions can forbid an otherwise permitted use, such as leaving voicemail or message content, and override purpose-based grants.", "Regulator or lawful-request disclosures follow the adopting Dimension's legal-hold process and are recorded as exceptions with their legal basis reference.", "Projections to public surfaces are limited to endpoints explicitly classified public and approved for that surface." ], "audit_requirements": [ "Every read of a restricted or sealed endpoint value, every break-glass use and every disclosure-class change must be recorded by the adopting Dimension's audit model, which owns audit-record semantics and retention; this model contributes only the identifiers, purpose and disclosure class needed for that record.", "Every change to the canonical value, verification status or restriction binding must be attributable to an actor, an instructing party and a rule or policy version.", "Exports and projections record who requested them, the disclosure filter applied and the crosswalk version used." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owning Dimension and steward contact reference", "Governed vocabulary, ruleset and crosswalk versions in force" ], "read_order": [ "AGENTS.md — identify the model, its type and the four resolvable URLs before any other action", "Specification URL — read scope, boundary notes and out-of-scope list to learn what this mixin must not do", "Storage type URL — learn the projection in use (document store, graph, repository or collection) and that it carries no semantics", "Interface URL — learn the callable surface and which operations are decision-support only", "Processes URL — learn create, change, verification-recording, disposition and escalation procedures", "Governed vocabulary, ruleset and crosswalk versions — resolve them before classifying, validating or projecting any endpoint" ] } }, "coverage": { "claim": "Single-provider Claude result for WM-XCT-024 Contact Point is structurally defensible and adequately grounded for a reviewable public draft: 6 bundles / 12 layers / 26 findings / 87 questions / 6 artifacts / 10 functions, with instance identity separated from address value, medium and capability, canonical versus display form, purpose and audience, scope-relative preference, validity period and succession, syntactic validation distinguished from control verification and reachability, provenance and stewardship, restriction and disclosure references, crosswalks with declared loss, and tombstoning disposition. Coverage is not universal: telephony reachability signals, per-service handle syntaxes, tariff characteristics, distribution endpoints, anti-abuse heuristics and all non-US/EU regimes are unmodelled, RFC 5322 is relied on without being cited, the frozen relationship contract is empty so no declared outbound binding can be validated, and no independent second-provider review exists.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Instance identity, master-system priority, multi-source merge identifiers and the explicit rule that an address value is a match key and not an identifier (contact-point-identity, artifact_rules.identity_priority)." }, { "dimension": "lifecycle", "status": "covered", "notes": "States, validity period, permitted transitions, supersession and reassignment-driven suspension (lifecycle-state, succession-and-reassignment), grounded in FHIR period and the FCC reassignment rules." }, { "dimension": "relationships", "status": "covered", "notes": "Typed outbound bindings to party, address, permission, verification, messaging, schedule and geography models, plus logical-endpoint grouping for alternates and localisations." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with seconds and explicit offset; event time separated from observation/ingestion time across assertion, verification, reachability, change and disposition; attended windows and time zone bound externally." }, { "dimension": "provenance", "status": "covered", "notes": "Source reference, assertion basis (self, third-party, inferred), asserting party, capture channel and the two-time recording rule (capture-provenance)." }, { "dimension": "ownership", "status": "covered", "notes": "Master-system designation, steward role, override authority and the named owner of disposition execution (stewardship-and-master-system, crud.delete, roles)." }, { "dimension": "validation", "status": "covered", "notes": "Medium-specific syntactic and structural rules with severities and a versioned rule profile, plus an explicit statement that well-formedness proves neither reachability nor ownership." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with purpose-named grants, disclosure classes, safe-contact handling restrictions, break-glass and lawful-request exceptions, and audit contributions delegated to the audit model." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention class, minimisation and tombstoning of this model's own records, referential-integrity preservation, and explicit assignment of erasure-decision and suppression-key ownership to the privacy and permission models." }, { "dimension": "interoperability", "status": "covered", "notes": "Crosswalk artefact and projection function for vCard/jCard/JSContact/FHIR/schema.org with declared loss profiles, plus a recorded-conflict policy and an alignment-not-conformance stance." }, { "dimension": "classification", "status": "covered", "notes": "Medium codes bound to a closed external set where required, and a governed purpose vocabulary that separates purpose from lifecycle and device class." }, { "dimension": "preference and selection", "status": "covered", "notes": "Subject- and medium-scoped relative preference with tie-breaks and basis, and a decision-support ranking function that performs no contact and grants no permission." }, { "dimension": "quality and evidence", "status": "covered", "notes": "Reachability outcome classes from RFC 3463, confidence and staleness metrics driven by the GDPR accuracy principle, with evidence held by reference only." }, { "dimension": "spatial", "status": "covered", "notes": "phone-context for local numbers, area served and jurisdiction references; geometry and geocoding are explicitly external." }, { "dimension": "security", "status": "covered", "notes": "Channel-as-authenticator boundary per NIST SP 800-63B, prohibition on storing verification secrets or risk scores, and reset of verification on value change." }, { "dimension": "measurement units", "status": "not-applicable", "notes": "The model carries no physical quantities; the only numeric fields are ordinal preference and derived quality metrics, whose scales are declared with the metric definition." } ], "known_omissions": [ "No enumeration of national numbering-plan rules, dialling prefixes or emergency-number conventions; only the E.164 canonical form and phone-context mechanism are modelled.", "Messaging-platform and social-handle identifier syntaxes (per-service handle rules, federated identifiers, DID-style endpoints) are handled generically as OnlineService values without per-service validation.", "No treatment of postal, in-person or physical delivery channels beyond a reference to the address model.", "Cost, tariff and toll characteristics of an endpoint (premium-rate, freephone) are not modelled, although they materially affect selection.", "Group and distribution endpoints (mailing lists, broadcast numbers) are only partly covered by the shared-endpoint flag; list membership semantics are out of scope.", "Anti-abuse concerns such as disposable-address detection and role-account heuristics are not modelled and would need a separate risk model.", "No formal conformance test suite or evidence is included, so all standards relations remain alignments." ], "conflicts": [ "FHIR ContactPointUse is a required, closed set that conflates purpose (home, work), lifecycle (old, temp) and device class (mobile) in one field, while this model separates purpose, state and capability; round-tripping through FHIR is therefore lossy in both directions.", "vCard TEL TYPE similarly mixes context values (work, home) with capability values (cell, fax, video, textphone), whereas JSContact separates contexts from features; RFC 9555 maps home/work to private/work but does not remove the underlying conflation.", "schema.org contactType is an open vocabulary with only illustrative values, and Google's consumer documentation reads essentially only contactPoint.telephone and contactPoint.email — published purpose metadata is therefore unreliable downstream.", "Preference semantics are consistent in direction (lower is more preferred) across vCard, JSContact and FHIR, but the comparison set differs: vCard and JSContact scope it to the same property type on the same card, FHIR to the containing resource element; a naive merge across sources produces meaningless global ranks.", "GDPR Art. 17 erasure and the 47 CFR 64.1200(d)(6) five-year do-not-call obligation pull in opposite directions on retaining a suppression key; this model records the conflict and delegates resolution rather than asserting a universal answer.", "The W3C vCard Ontology is an Interest Group Note explicitly lacking W3C endorsement, so RDF projections built on it cannot be treated as normative alignment.", "vCard has no per-property validity period (only card-level REV), while FHIR has period but no per-instance identifier; neither standard alone supports both instance identity and time-bounded validity, which this model requires." ], "regional_assumptions": [ "Do-not-call recording at the time of request, the 30-day honouring window, the five-year retention of a do-not-call request, the 31-day registry refresh and the Reassigned Numbers Database safe harbour are United States rules under 47 CFR 64.1200 and must not be applied as global defaults.", "The right to object to direct marketing at any time and free of charge, the accuracy principle and erasure rights as modelled here derive from EU Regulation 2016/679 and apply where that regulation or an equivalent regime applies.", "NIST SP 800-63B restrictions on PSTN out-of-band authenticators and the prohibition on e-mail for out-of-band authentication are US federal guidance; other jurisdictions may permit practices this model treats as restricted.", "E.164 canonicalisation assumes an internationally dialable number; closed numbering arrangements, short codes and internal extensions require phone-context and are not globally unique.", "Language and script expectations for labels assume BCP 47 tagging; locale-specific presentation conventions beyond E.123 are left to the adopting Dimension." ], "adversarial_checks": [ "Reassignment counterexample: a well-formed, previously verified mobile number can belong to a different person after disconnection and reassignment. The model responds by forbidding value-as-identity, recording reassignment signals and forcing a state change, and by delegating the safe-harbour database query to an external authority.", "Boundary-creep check on consent: an earlier structure would have carried opt-in status, lawful basis and suppression handling locally. That was reduced to a reference plus a cached derived restriction state with a freshness bound, because consent lifecycle, proof and enforcement belong to the permission model and the do-not-call retention obligation is legally owned there.", "Boundary-creep check on delivery and audit: bounce handling, retry logic and access logging were removed from the operating bundle; the model keeps only a summarised reachability state, evidence pointers and the data an external audit model needs, so no evaluation, execution, enforcement or audit-trail semantics are owned here.", "Preference-merge counterexample: merging endpoints from two source systems, each with PREF=1, yields a meaningless ordering because both standards scope preference to a single card. The model responds by requiring an explicit comparison scope and a deterministic tie-break rather than a global score.", "Verification-versus-validation counterexample: a syntactically valid address can be a typo that reaches a real stranger, so validation status is explicitly declared insufficient and a separate control-verification state with reset-on-change is required.", "Closed-vocabulary counterexample: FHIR's required ContactPointSystem set cannot express many modern channels except as url or other, and its use set cannot express billing or delivery contexts, which shows that a single external vocabulary cannot be adopted wholesale and justifies a governed local vocabulary with a crosswalk.", "Erasure-versus-suppression stress test: honouring an erasure request by deleting the contact point can destroy the ability to suppress future contact. The model resolves this by tombstoning locally without a recoverable value while requiring the suppression key to live in the permission model." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Two axes must be kept apart. The record plane is fixed by the frozen registry (registry_id vr.wm-xct-024, record_plane world-model, status candidate, review_state boundary-review-required) and describes how Vercy files the record, not what the subject is; a record-plane token such as standalone-mm would never be a legal subject-model kind. Here the registry's entry_kind value happens to coincide with a valid schema enum member, so the two axes agree by coincidence rather than by derivation, and the subject-model kind was re-derived independently from the evidence. On the subject axis, mixin is the most defensible schema kind: all three tier-1 format sources model an addressable endpoint as a component of a host record rather than as a free-standing thing — vCard places TEL/EMAIL as properties on a card whose KIND declares the party, FHIR R5 defines ContactPoint as a datatype and not a resource and gives it no instance identifier, and JSContact carries Phone/EmailAddress/OnlineService as Id-keyed map entries inside a Card. The model's own owner-package requirement states the mixin has no standing outside a host subject, and disposition cascades from the host. Entity was rejected because independent existence is never asserted; relationship was rejected because the record carries endpoint attributes (medium, capability, canonical value) that no pure binding would hold; aggregate was rejected because the host subject, not the contact point, is the aggregate root and issues the governing identity. The reservation, recorded but not disqualifying, is the shared endpoint case: an endpoint with its own identifier, lifecycle, tombstone and multi-subject attachment starts to behave like an endpoint entity plus a subject-binding relationship, and that split must be adjudicated before the record leaves candidate status." }, "decisions": [ { "concept": "Entry kind of the subject model (mixin)", "disposition": "accepted", "rationale": "vCard property-on-card, FHIR datatype-not-resource with no instance identifier, and JSContact Id-keyed map entries all treat the endpoint as a component of a host record; the owner package confirms it has no standing outside a host subject." }, { "concept": "Aggregate root ownership", "disposition": "rejected as an aggregate root; host subject retained as root", "rationale": "Identity priority defers to the host's master system, disposition cascades from the host subject, and the model explicitly disclaims owning the subject; a mixin that cannot be created or destroyed independently cannot be the aggregate root." }, { "concept": "Shared and multi-subject endpoints (household line, shared support mailbox)", "disposition": "deferred — flagged as the strongest reclassification candidate", "rationale": "subject-attachment-binding requires an explicit multi-subject or role-based attachment while the record also carries its own identifier, lifecycle and tombstone; that combination is an endpoint entity plus a binding relationship and must be adjudicated before promotion past candidate." }, { "concept": "Registry parent_ids limited to WM-PER-010 against a person/organisation/role/place/device/service scope", "disposition": "hold — registry-versus-model drift recorded", "rationale": "nav_path NAV.XCT.CONTACT and domain_tags XCT.CONTACT declare a cross-cutting mixin, but a single party parent implies one host class; either the field means primary host only or the additional host models must be registered." }, { "concept": "Empty frozen relationship contract against seven declared outbound bindings", "disposition": "deferred — nothing to validate against", "rationale": "related-model-bindings and the boundary notes name neighbours in prose (postal address, permission, messaging, identity, availability, geography) without model identifiers, so composition and reference relations are unverifiable and the fail-closed reference-only policy has no registered targets." }, { "concept": "RFC 5322 addr-spec cited in prose but absent from the source list", "disposition": "rejected as adequately supported; explicit source pin required", "rationale": "canonical-address-value and syntactic-conformance both rest on addr-spec conformance, and SRC-010 (RFC 6532) internationalises but does not define it, leaving the e-mail half of the validation rule profile without its governing citation." }, { "concept": "47 CFR 64.1200 pinned to the 2023 annual edition", "disposition": "hold — re-pin to the in-force text before publication", "rationale": "The five-year honouring obligation, the 30-day window, the 31-day registry refresh and the Reassigned Numbers Database safe harbour drive retention, succession and selection findings, and the rule has been amended since that annual edition; a stale pin silently dates the whole compliance surface." }, { "concept": "ITU-T E.164 (02/26) and Schema.org version 30.0 edition pins", "disposition": "hold pending live verification", "rationale": "Both carry normative weight — E.164 for canonicalisation, Schema.org for the purpose, audience and availability vocabulary — and a no-tools audit cannot confirm either edition exists as stated; the IANA vCard registry date of 2026-01-13 needs the same treatment." }, { "concept": "Telephony reachability signals asserted as analogous to RFC 3463 mail status codes", "disposition": "deferred — evidence gap", "rationale": "SRC-012 governs mail only, and no Q.850 cause-code, SIP response-code or call-disposition source is cited, so the voice and SMS half of reachability-observation and its state-forcing thresholds rest on assertion rather than evidence." }, { "concept": "Attended-window filtering in channel-selection-inputs against the no-schedule-algebra boundary", "disposition": "accepted with scope narrowing", "rationale": "availability-and-language disclaims schedule algebra, yet the selection filter eliminates endpoints outside their attended window; the filter must consume an availability verdict from the schedule owner rather than evaluate opening hours locally, or the model imports semantics it declared out of scope." }, { "concept": "Access scopes (bundle, layer, finding, artifact) against the asserted value-versus-metadata granularity", "disposition": "deferred to the adopting Dimension", "rationale": "The default rule promises that medium, state and disclosure class are readable at a lower level than the address value, but the declared scope list has no field-level scope capable of expressing that separation." }, { "concept": "Projection artifact identity embedding a subject reference", "disposition": "deferred — conflicts with immutability plus erasure", "rationale": "The serial naming rule makes projection identity @# and declares published identities immutable, while the tombstone deliberately retains only a subject reference class; an immutable identifier carrying a resolvable subject pointer survives disposition unless it is opaque or explicitly inside the purge propagation list." }, { "concept": "Function-surface gaps: no merge/de-duplicate, no restriction-state refresh, no disclosure-class change", "disposition": "recorded, not added — single-provider mode forbids add_functions", "rationale": "crud.create demands a recorded merge or keep-both decision and arg-q-dedup and cpi-q-merge presuppose one, the cached restriction state carries a freshness bound with nothing to refresh it, and disclosure-class changes are audit-required but have no callable; the omission is a mode limitation, not an endorsement of the surface." }, { "concept": "fn-classify-and-rank bundling purpose assignment with preference setting", "disposition": "deferred split", "rationale": "pr-q-who-sets establishes a separate authority path for preference (subject, steward or inference process) from the vocabulary authority governing purpose codes; one callable hides which authority approved which change and defeats the recorded-basis requirement." }, { "concept": "Question kind 'spatial' applied to cav-q-context (phone-context)", "disposition": "accepted with a re-kind recommendation", "rationale": "phone-context under RFC 3966 is a numbering-plan or domain qualifier rather than a geographic assertion; mis-kinding inflates spatial coverage and understates the constraint and interoperability profile in the question-kind distribution." }, { "concept": "Do-not-call phrasing: 'kept for five years' versus 'honoured for five years'", "disposition": "accepted with a precision fix", "rationale": "The regulation obliges honouring the request for five years, from which retention follows; restating it as a freestanding five-year record-retention rule in permission-reference-binding risks the adopting Dimension implementing the wrong obligation." }, { "concept": "Tombstone residue (identifier, subject reference class, medium, disposition state, timestamps)", "disposition": "accepted", "rationale": "No recoverable address value and no derived match key survive, referential integrity for existing references is preserved, and the suppression key is explicitly relocated to the permission model, which is the defensible resolution of the erasure-versus-suppression collision." }, { "concept": "SRC-019 Google structured-data documentation as tier-3 support for downstream metadata loss", "disposition": "accepted as a dated observation only", "rationale": "Vendor documentation is volatile and non-primary; the claim that only contactPoint.telephone and contactPoint.email are consumed must carry its observation date and must never be projected as a durable property of the Schema.org vocabulary." } ], "publicationHolds": [ "Single-provider hold: grok was waived by the repository owner on 2026-08-29T09:06:27Z after repeated structured-output failures, so no independent second-provider review exists; every published artifact must carry a visible single-provider waiver notice naming the authorising party, the authorisation timestamp and the reason, and the record stays a reviewable draft until independent review is restored or formally retired.", "Live source and version verification hold: all 19 sources must be re-resolved and their pins re-confirmed before publication, with priority on ITU-T E.164 edition (02/26), Schema.org version 30.0 dated 2026-03-19, the IANA vCard Elements registry snapshot of 2026-01-13, NIST SP 800-63B-4 dated 2025-08-26, and 47 CFR 64.1200, which is pinned to the stale 2023 annual edition and must be re-pinned to the in-force eCFR text.", "Citation completeness hold: RFC 5322 addr-spec underpins canonical-address-value and syntactic-conformance but appears nowhere in the source list, and the UUID/ULID identifier fallback in artifact_rules.identity_priority carries no citation; both must be pinned or the corresponding claims softened before the draft is published.", "Relationship contract hold: the frozen relationship contract is empty while the model declares typed outbound bindings to party, postal address, permission, identity, messaging, availability and geography models and names them only in prose; no composition or reference relation can be validated, and the fail-closed reference-only policy has no registered targets to fail closed against.", "Registry state hold: the frozen record is status candidate with review_state boundary-review-required, priority_confidence low and no named owner, so the draft must publish as candidate-with-open-boundary-review rather than as a settled model, and the shared endpoint / multi-subject split question must be visible in that notice.", "Scope-accuracy hold: the coverage claim, known omissions and regional assumptions must be reproduced verbatim in the published draft so that the absence of telephony call-disposition sources, per-service handle syntaxes, tariff characteristics, distribution-list semantics, anti-abuse heuristics and all non-US/EU regimes is not read as covered ground.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Adjudicate the shared and multi-subject endpoint case: decide whether the record stays a pure mixin that forbids sharing and routes household lines and shared mailboxes through a role subject, or splits into an endpoint value object plus an explicit subject-binding relationship with its own lifecycle.", "Source telephony and messaging reachability signals with primary evidence — Q.850 cause codes, SIP response classes and carrier call-disposition or SMS delivery-receipt semantics — so that reachability-observation is not carried entirely by RFC 3463 mail status codes.", "Pin RFC 5322 as an explicit source for addr-spec, and add the identifier standards actually relied on (RFC 9562 for UUID, and a governed reference or removal for ULID) to artifact_rules.identity_priority.", "Re-pin 47 CFR 64.1200 to the in-force eCFR text and re-verify the five-year honouring obligation, the 30-day window, the 31-day registry refresh and the Reassigned Numbers Database safe harbour against the amended rule rather than the 2023 annual edition.", "Register the neighbour models named only in prose (postal address, permission and consent, communication event, identity verification, availability schedule, geography) with model identifiers and link types, then re-validate related-model-bindings against a populated relationship contract.", "Resolve the projection identity conflict: replace in the serial naming rule with an opaque token, or bring projection identifiers explicitly inside the purge propagation list so an immutable artifact identity cannot outlive the subject it points at.", "Close the function-surface gaps in a later revision: a merge/de-duplicate callable that records the duplicate criteria and the keep-both decision, a restriction-state refresh callable bound to the declared freshness window, and a disclosure-class change callable that satisfies the audit attribution requirement.", "Extend the regional profile beyond US and EU regimes — at minimum ePrivacy direct-marketing rules, Canadian CASL, UK PECR and national do-not-call registries such as India's TRAI framework — so that the regional assumptions list stops functioning as an implicit global default.", "Specify field-level access granularity for the address value versus its metadata, since the declared bundle/layer/finding/artifact scopes cannot express the separation the deny-by-default rule promises.", "Model tariff and toll characteristics (premium-rate, freephone, shared-cost) and per-service handle syntaxes for messaging and federated or DID-style endpoints, both of which the omissions list concedes materially affect selection and validation." ] }, "statistics": { "sources": 19, "bundles": 6, "layers": 12, "findings": 26, "questions": 87, "artifacts": 6, "functions": 10 } }