# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-03T00:33:02Z", "synthesisSha256": "dec6a6c2eb366d33034b54ce10332e5941a47490754a2d58fa8bbcb38e4d8f19", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-PER-010", "registryId": "vr.wm-per-010", "name": "Contact Point / Party Profile", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.PER.CON" ], "tags": [ "contact", "point", "party", "profile", "soc.per.con" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-per-010-contact-point-party-profile/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-per-010", "model": { "registry_id": "vr.wm-per-010", "model_id": "WM-PER-010", "name": "Contact Point / Party Profile", "entry_kind": "aggregate", "purpose": "Provide a reusable, format-neutral contact-profile component that any party model (person, organization, role or other party) can mix in, so that addressable channel endpoints, communication preferences and the governance of that contact data are modelled once and consistently, independently of storage format or access interface.", "scope_statement": "WM-PER-010 models the contact profile attached to a party: the stable identity of each contact point and its binding to exactly one owning party; the typed addressable endpoint it carries (telephone, email, postal, web/URI, messaging service and comparable channels) in canonical, display and URI forms with internationalization; the purpose, context and capability facets of that endpoint; verification assertions carried on the endpoint; its validity interval, operational reachability status and supersession chain; the party's communication preferences (preferred channel and rank, language, format, reachability windows and time zone, frequency limits and topic scoping); and the governance of the profile (stewardship, provenance, correction and objection handling, access scoping, retention and disposition, and interoperability mappings). As a mixin it never asserts the identity of the party itself, never carries message content or delivery attempts, and never owns the runtime evaluation, enforcement or audit-trail semantics of the models it references.", "in_scope": [ "Stable contact-point identity that survives change of the endpoint value it carries", "Binding of each contact point to exactly one owning or subject party, including role-based and stewarded arrangements", "Endpoint kind, addressing scheme, purpose/usage context and technical capability facets", "Telephone endpoints in E.164 canonical form, tel URI form and E.123 display notation, including phone-context for local numbers and extensions", "Email mailbox endpoints including internationalized (UTF-8) local parts and IDN domains in A-label and U-label form", "Web/URI endpoints and online-service or messaging handles with scheme-aware normalization", "Postal delivery endpoints as a delivery-role reference to an addressed location, with country template binding", "Unicode normalization, script, transliteration and localized label handling for endpoint values", "Verification assertions carried on a contact point: asserting authority, method class, assurance level, timestamps and expiry", "Validity interval, lifecycle state, operational reachability status and supersession/replacement chains", "Communication preferences: preferred channel and rank, preferred language and format, reachability windows and time zone, frequency limits and topic or purpose scoping", "Governance of the profile: stewardship and ownership, provenance of each value, correction and objection handling, access scoping, retention and disposition rules", "Interoperability mappings to vCard, JSContact, schema.org ContactPoint, public-sector contact vocabularies and postal template libraries" ], "out_of_scope": [ "Identity of the party itself: legal name, birth data, registration numbers, party matching and deduplication (owned by the party/person model)", "Message content, communication events, send/delivery attempts, bounce and engagement logs, campaign or notification execution", "Structured postal address component modelling, address templates, geocoding, place identity and address lifecycle (owned by postal-address and place models)", "Identity credentials, authenticators, multi-factor binding and account recovery flows", "Execution of proofing challenges, one-time-code issuance, evaluation of verification outcomes and the audit trail of those runs", "Consent records, lawful-basis determinations and marketing opt-in legal reasoning", "Customer, account, subscription or contract relationships and CRM role modelling", "Runtime policy evaluation, enforcement engines and audit-record storage", "Telephone number allocation, portability administration, domain registration and DNS operation", "Directory publication, search ranking and reverse lookup services" ], "boundary_notes": [ { "neighbor": "WM-XCT-024 Contact Point (cross-cutting registry entry)", "distinction": "Unresolved potential duplicate. Both entries claim the contact-point concept. The cited vocabularies define exactly one ContactPoint/channel-object concept, so two canonical models cannot both own it; until the registry resolves this, WM-PER-010 scopes itself to the party-attached contact profile (channels plus preferences plus governance) and records the overlap as a conflict rather than freezing a relation.", "source_refs": [ "SRC-013", "SRC-016", "SRC-011" ] }, { "neighbor": "WM-PER-001 Person / Party identity", "distinction": "The party model owns who the party is and its identifiers; WM-PER-010 owns how the party is reached. JSContact separates the Card (the entity) from phones, emails, onlineServices and addresses (the channels); schema.org attaches ContactPoint to Person/Organization rather than merging them. This model carries only a reference to the owning party.", "source_refs": [ "SRC-011", "SRC-013", "SRC-014" ] }, { "neighbor": "Postal address / place model", "distinction": "UPU S42 Part A defines the postal address component set and Part B the country templates and rendition rules; that structure and its maintenance belong to the address/place model. WM-PER-010 carries only the delivery-role attributes (attention line, care-of, mailbox designation), the country binding and a reference to the addressed location.", "source_refs": [ "SRC-012", "SRC-011", "SRC-010" ] }, { "neighbor": "Communication event / message-delivery model", "distinction": "SMTP and related transport specifications own transmission, delivery status and failure reporting. WM-PER-010 may record a derived reachability status and a reference to supporting evidence, but never the attempt log, message content, envelope or bounce record.", "source_refs": [ "SRC-005", "SRC-006" ] }, { "neighbor": "Identity proofing / verification-process model", "distinction": "NIST SP 800-63A owns identity proofing and enrollment procedure and its assurance levels; OpenID Connect providers assert the verified state. WM-PER-010 carries only the resulting assertion (authority, method class, assurance level, timestamps, expiry, evidence reference) and never the challenge issuance, evaluation logic or proofing audit trail.", "source_refs": [ "SRC-017", "SRC-015" ] }, { "neighbor": "Consent and legal-basis model", "distinction": "Neither JSContact nor schema.org ContactPoint carries consent or lawful-basis semantics; declaring a purpose context on an endpoint states intended use, not permission. Permission to contact, its legal basis, withdrawal and objection outcomes stay in the consent model, which WM-PER-010 references.", "source_refs": [ "SRC-011", "SRC-013" ] }, { "neighbor": "Customer / account relationship model", "distinction": "A contact point is attached to a party, not to a commercial relationship. Account-scoped or contract-scoped contact routing is a projection built by the relationship model over contact points; WM-PER-010 exposes purpose context and party binding but does not model accounts, contracts or entitlements.", "source_refs": [ "SRC-016", "SRC-013" ] }, { "neighbor": "Identity credential / authenticator model", "distinction": "A verified phone number or mailbox may also serve as an authenticator channel, but authenticator binding, strength and recovery are credential-model concerns. WM-PER-010 stops at proof of control over the endpoint and does not model authentication use.", "source_refs": [ "SRC-017", "SRC-015" ] } ] }, "sources": [ { "id": "SRC-001", "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-03T12:00:00Z", "relevance": "Names the authoritative numbering plan for telephone endpoints and confirms the currently in-force edition used for canonical telephone form." }, { "id": "SRC-002", "title": "ITU-T Recommendation E.164 (05/97): The international public telecommunication numbering plan (ITU-hosted text)", "organization": "International Telecommunication Union (ITU-T)", "url": "https://www.itu.int/ITU-T/worksem/ip-telecoms/e164/e164.pdf", "version_or_date": "Edition 05/1997", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Verified normative text for the maximum 15-digit international number, the CC (1-3 digits) + NDC + SN structure and the three number categories (geographic areas, global services, networks)." }, { "id": "SRC-003", "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/2001), Amendment 1 (05/08), Erratum 2 (06/2022)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Authority for the human-readable display notation of telephone numbers, email addresses and web addresses, distinct from the canonical machine form." }, { "id": "SRC-004", "title": "RFC 3966: The tel URI for Telephone Numbers", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc3966", "version_or_date": "December 2004", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines global vs local telephone numbers, the mandatory phone-context parameter for local numbers, and the rule that visual separators are ignored when comparing numbers." }, { "id": "SRC-005", "title": "RFC 5321: Simple Mail Transfer Protocol", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc5321", "version_or_date": "October 2008", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Normative source for mailbox local-part@domain syntax and the requirement that local-parts MUST be treated as case sensitive and their case preserved, which constrains email normalization." }, { "id": "SRC-006", "title": "RFC 6068: The 'mailto' URI Scheme", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc6068", "version_or_date": "October 2010", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines the mailto URI projection of a mailbox endpoint, percent-encoding rules and UTF-8 handling for internationalized values." }, { "id": "SRC-007", "title": "RFC 6530: Overview and Framework for Internationalized Email", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc6530", "version_or_date": "February 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Establishes UTF-8 local parts and domains for internationalized email and explicitly removes the requirement for a paired all-ASCII alternate address, which shapes how fallback forms may be recorded." }, { "id": "SRC-008", "title": "RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc5890", "version_or_date": "August 2010", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines A-label, U-label, LDH label, NFC normalization and the A-label/U-label convertibility requirement governing internationalized domains in email and URI endpoints." }, { "id": "SRC-009", "title": "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3986.html", "version_or_date": "January 2005", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines URI components and the normalization/comparison ladder (simple string, syntax-based, scheme-based, protocol-based) applied to web and messaging endpoints." }, { "id": "SRC-010", "title": "RFC 6350: vCard Format Specification", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc6350", "version_or_date": "August 2011", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines TEL, EMAIL, ADR, URL, IMPP, LANG, GEO and TZ properties with TYPE, PREF, PID and ALTID parameters and the seven-component ADR structure; the reference interchange alignment for contact points." }, { "id": "SRC-011", "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": "May 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Current normative contact data model: Card uid/created/updated/kind, Id-keyed maps of Phone, EmailAddress, OnlineService and Address objects, contexts, features, pref, label, countryCode, coordinates, language and localizations." }, { "id": "SRC-012", "title": "Addressing Solutions: Standard S42 International postal address components and templates", "organization": "Universal Postal Union (UPU)", "url": "https://www.upu.int/en/Postal-Solutions/Programmes-Services/Addressing-Solutions", "version_or_date": "S42 standard document published 2020-02-26; page content current as accessed", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "First-party authority for postal address components (S42 Part A), country-specific templates (S42 Part B), the S53 name-and-address exchange standard, and the scale of address-format and script diversity." }, { "id": "SRC-013", "title": "schema.org ContactPoint", "organization": "Schema.org Community Group", "url": "https://schema.org/ContactPoint", "version_or_date": "v30.0, 2026-03-19 (development version)", "source_type": "classifier", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Widely deployed classifier for contact-point purpose (contactType), contactOption, areaServed, availableLanguage, email, telephone, faxNumber and hoursAvailable; demonstrates contact point as a StructuredValue attached to a party." }, { "id": "SRC-014", "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; namespace http://www.w3.org/2006/vcard/ns#", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "RDF alignment showing channels as separately typed resources (Email, Phone subtypes, Address) linked from a Kind via hasEmail, hasTelephone, hasAddress and hasURL; a Note, not a Recommendation." }, { "id": "SRC-015", "title": "OpenID Connect Core 1.0 incorporating errata set 2", "organization": "OpenID Foundation", "url": "https://openid.net/specs/openid-connect-core-1_0.html", "version_or_date": "Errata set 2, 15 December 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Defines the standard claims email, email_verified, phone_number, phone_number_verified and address, establishing that verified state is an assertion made by an issuing provider rather than an intrinsic endpoint property." }, { "id": "SRC-016", "title": "Core Public Organisation Vocabulary (CPOV) 2.1.1", "organization": "European Commission / SEMIC (Interoperable Europe)", "url": "https://semiceu.github.io/CPOV/releases/2.1.1/", "version_or_date": "Version 2.1.1, SEMIC Recommendation, 6 May 2024", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Public-authority model treating ContactPoint as a first-class class with has email, has telephone, contact page, opening hours and availability restriction as TemporalEntity, supporting time-bounded reachability." }, { "id": "SRC-017", "title": "NIST Special Publication 800-63A-4: Digital Identity Guidelines - Identity Proofing and Enrollment", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/63/a/4/final", "version_or_date": "SP 800-63A-4, final, 31 July 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T12:00:00Z", "relevance": "Authority for identity proofing and enrollment requirements at defined identity assurance levels; establishes that proofing procedure and its assurance framing belong to a proofing model, not to the contact record that carries the outcome." }, { "id": "SRC-018", "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, August 2011, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:16:00Z", "relevance": "Normative rules for the PREF parameter (integer 1-100, absence means least preferred, value interpretable only relative to other instances of the same property), the LANG property for contact languages, the TZ property and its caution against fixed UTC offsets, and RELATED type values including agent and emergency." }, { "id": "SRC-019", "title": "RFC 7953: Calendar Availability: A Standard Approach", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7953.html", "version_or_date": "RFC 7953, August 2016, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:17:00Z", "relevance": "Normative model for recurring availability patterns: VAVAILABILITY with AVAILABLE subcomponents, BUSYTYPE defaulting uncovered time to BUSY-UNAVAILABLE, PRIORITY-based resolution of overlapping components with absence or 0 meaning lowest priority, and the equal-priority ordering BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE." }, { "id": "SRC-020", "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, Best Current Practice", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:18:00Z", "relevance": "Normative subtag structure for language, script, region, variant and private use, and the rule that a script subtag SHOULD be omitted when it adds no distinguishing value or when the registry record carries Suppress-Script." }, { "id": "SRC-021", "title": "RFC 8984: JSCalendar: A JSON Representation of Calendar Data", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8984.html", "version_or_date": "RFC 8984, July 2021, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:19:00Z", "relevance": "Normative pattern for timeZone, recurrenceRules, excludedRecurrenceRules and recurrenceOverrides as patch objects on individual occurrences, and freeBusyStatus - the basis for representing temporary overrides without rewriting a standing pattern." }, { "id": "SRC-022", "title": "ContactPointOption - Schema.org Enumeration", "organization": "Schema.org Community Group", "url": "https://schema.org/ContactPointOption", "version_or_date": "Schema.org V30.0, released 2026-03-19", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:21:00Z", "relevance": "Shows the published accessibility-related contact option surface (HearingImpairedSupported, TollFree) and its narrowness relative to functional accommodation vocabularies, used to justify a capability-based rather than enumeration-based accommodation model." }, { "id": "SRC-023", "title": "FHIR Release 5: Data Types (ContactPoint)", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/datatypes.html", "version_or_date": "FHIR R5, v5.0.0, published 2023-03-26", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:22:00Z", "relevance": "Normative definition of ContactPoint with rank (positiveInt, lower values more preferred), period (time period when the contact point was or is in use) and the ContactPointUse value set home, work, temp, old, mobile, grounding preference ranking, validity intervals and temporary use." }, { "id": "SRC-024", "title": "Time Zone Database", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/time-zones", "version_or_date": "Release 2026c, 2026-07-08", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:23:00Z", "relevance": "Authoritative registry of Area/Location time-zone identifiers and their historical rules; updated periodically for political changes, which is why a stated window must cite both a zone identifier and the database release used to interpret it." }, { "id": "SRC-025", "title": "vCard Elements Registries", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml", "version_or_date": "Last updated 2026-01-13", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:24:00Z", "relevance": "Normative registry of vCard properties, parameters (including PREF and LANGUAGE), value data types and property values (TEL types voice, fax, cell, video, pager, textphone, main-number; RELATED types including agent and emergency), plus the registration procedures that govern vendor-namespaced extensions." }, { "id": "SRC-026", "title": "1EdTech AccessForAll Personal Needs and Preferences Description for Digital Delivery Information Model", "organization": "1EdTech Consortium (formerly IMS Global Learning Consortium)", "url": "https://www.imsglobal.org/accessibility/accpnpv2p0/spec/ISO_ACCPNPinfoModelv2p0.html", "version_or_date": "Version 2.0 Final Release, 2010; aligned with ISO/IEC 24751", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:25:00Z", "relevance": "Primary model for expressing accessibility needs functionally rather than diagnostically, organised as display, control and content adaptation preferences, with explicit support for multiple context-specific preference sets that a party switches between." }, { "id": "SRC-027", "title": "Common Alerting Protocol Version 1.2", "organization": "OASIS", "url": "https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html", "version_or_date": "Version 1.2, OASIS Standard, 2010-07-01", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:26:00Z", "relevance": "Sector-neutral urgency vocabulary (Immediate, Expected, Future, Past, Unknown) with time-to-respond definitions, used only as an alignment candidate for urgency tiering; CAP alert dissemination semantics are not adopted." }, { "id": "SRC-028", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union / Publications Office of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "27 April 2016, OJ L 119, 4.5.2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:08:00Z", "relevance": "Article 5(1)(c) minimisation, 5(1)(d) accuracy, 5(1)(e) storage limitation, 5(2) accountability, Art. 6 legal basis, Art. 7 consent and withdrawal, Art. 16 rectification, Art. 17 erasure, Art. 19 notification to recipients, Art. 21 objection to direct marketing, Art. 25 protection by design and by default, Art. 30 records of processing." }, { "id": "SRC-029", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:07:00Z", "relevance": "Entity/Activity/Agent model with wasGeneratedBy, wasAttributedTo, wasDerivedFrom, wasRevisionOf, generatedAtTime and invalidatedAtTime. Grounds assertion provenance, revision chains and the temporal boundaries of an entity's existence." }, { "id": "SRC-030", "title": "Universal Electronic Records Management (ERM) Requirements", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/universalermrequirements", "version_or_date": "Version 3, June 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:09:00Z", "relevance": "Lifecycle requirement groups (Capture, Maintenance and Use, Disposal, Transfer, Metadata, Reporting) with Must Have / Should Have designations and separated program versus system requirements. Grounds disposition, metadata, transfer and reporting obligations." }, { "id": "SRC-031", "title": "RFC 9110: HTTP Semantics", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html", "version_or_date": "RFC 9110 / STD 97, June 2022, Internet Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:10:00Z", "relevance": "Definitions of safe and idempotent methods, entity-tag validators, If-Match with strong comparison for lost-update prevention, 412 Precondition Failed and 409 Conflict. Cited as an alignment for optimistic concurrency and idempotency concepts, not as a mandated interface." }, { "id": "SRC-032", "title": "RFC 9457: Problem Details for HTTP APIs", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9457.html", "version_or_date": "RFC 9457, July 2023, Standards Track (obsoletes RFC 7807)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:11:00Z", "relevance": "Problem type, status, title, detail and instance members, extension-member rules, and the security guidance to vet what a problem object exposes. Grounds non-revealing error semantics for refused or partial disclosure." }, { "id": "SRC-033", "title": "RFC 6902: JavaScript Object Notation (JSON) Patch", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6902.html", "version_or_date": "RFC 6902, April 2013, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:12:00Z", "relevance": "Operation set (add, remove, replace, move, copy, test), the atomic all-or-nothing application rule, and the test operation as a precondition validator. Grounds the model's patch rules as a semantic pattern independent of serialization." }, { "id": "SRC-034", "title": "RFC 9562: Universally Unique IDentifiers (UUIDs)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9562.html", "version_or_date": "RFC 9562, May 2024, Standards Track (obsoletes RFC 4122)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:13:00Z", "relevance": "UUIDv7 time-ordered and UUIDv4 random generation, guidance to treat UUIDs opaquely, and the warning against keys derived from assumed-immutable values. Grounds the third tier of the identity priority and the rule that endpoint values are not identifiers." }, { "id": "SRC-035", "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, July 2002, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:14:00Z", "relevance": "Mandatory seconds in partial-time, the Z or numeric time-offset requirement, and the explicit finding that unqualified local time is unacceptable for interoperability. Grounds the timestamp rule." }, { "id": "SRC-036", "title": "The Government Data Quality Framework", "organization": "UK Government Data Quality Hub (Office for National Statistics / Cabinet Office)", "url": "https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework", "version_or_date": "Published 3 December 2020", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:16:00Z", "relevance": "Definitions of completeness, uniqueness, consistency, timeliness, validity and accuracy; data quality as fitness for purpose; assessment across the whole data lifecycle; and named data-quality roles. Grounds validation, reconciliation, staleness measurement and quality ownership." }, { "id": "SRC-037", "title": "ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure", "organization": "International Organization for Standardization / International Electrotechnical Commission", "url": "https://www.iso.org/standard/80392.html", "version_or_date": "ISO/IEC TS 27560:2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:18:00Z", "relevance": "Machine-readable consent record and receipt structure, with sectioned fields, cross-references between sections, and a receipt carrying only a receipt identifier and schema version as required fields. Grounds the decision to reference consent records rather than absorb them, and the need to record the referenced record's schema version." }, { "id": "SRC-038", "title": "Guidelines 05/2020 on consent under Regulation 2016/679", "organization": "European Data Protection Board (EDPB)", "url": "https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en", "version_or_date": "Version 1.1, adopted 4 May 2020", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:19:00Z", "relevance": "Supervisory interpretation of valid consent, purpose granularity, the duty to demonstrate consent and the requirement that withdrawal be as easy as giving consent. Used to justify per-purpose permission bindings and re-check triggers rather than a single global flag." }, { "id": "SRC-039", "title": "Public Notice: Reassigned Numbers Database (DA-21-1649)", "organization": "U.S. Federal Communications Commission (FCC)", "url": "https://docs.fcc.gov/public/attachments/DA-21-1649A1.pdf", "version_or_date": "DA-21-1649, 2021", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:20:00Z", "relevance": "US Reassigned Numbers Database and the 47 CFR 64.1200(m) safe harbour, under which a caller queries the database using the date consent was obtained. Cited as the jurisdiction-specific example of endpoint reassignment as a staleness signal. The PDF could not be text-extracted during this pass, so the paragraph wording was corroborated from summaries of FCC-published material rather than re-read verbatim; this limitation is recorded in coverage.known_omissions." } ], "structure": { "bundles": [ { "id": "cp-chan-b-identity", "name": "Contact-point identity and party binding", "description": "Establishes the contact point as a first-class, separately identified object attached to exactly one owning party, and the classification facets (endpoint kind, purpose context, capability) that determine which syntax and validation rules apply.", "rationale": "JSContact, vCard and the W3C vCard ontology all model channels as separately identified objects linked from an entity rather than as scalar attributes of it. Without a stable contact-point identity distinct from the endpoint value, history, verification and supersession cannot be carried across a value change.", "source_refs": [ "SRC-011", "SRC-010", "SRC-014", "SRC-013", "SRC-016" ], "layers": [ { "id": "cp-chan-l-record-identity", "name": "Record identity and ownership", "description": "Identity of the contact-point record itself and its binding to the owning or subject party, kept strictly separate from party identity.", "source_refs": [ "SRC-011", "SRC-013", "SRC-014" ], "findings": [ { "id": "cp-chan-f-endpoint-identity", "name": "Contact-point identifier distinct from endpoint value", "description": "A contact point is identified by a stable, non-semantic identifier assigned by the authoritative master system, not by the endpoint value it carries. JSContact assigns a mandatory uid to the Card and Id keys to each channel entry; vCard uses UID plus PID for individual property instances. Treating the endpoint value as the primary key destroys verification, validity and supersession history the moment a number or mailbox changes, and breaks when two parties legitimately share a value.", "source_refs": [ "SRC-011", "SRC-010", "SRC-013" ], "questions": [ { "id": "cp-chan-q-id-authority", "text": "Which system of record assigns the authoritative identifier for this contact point, and does that identifier remain stable when the endpoint value changes?", "kind": "identity", "answer_data": [ "Contact-point identifier value", "Issuing system reference", "Identifier scheme code", "Stability guarantee flag" ] }, { "id": "cp-chan-q-id-scope", "text": "Is the contact-point identifier globally resolvable, or unique only within the owning party's record?", "kind": "interoperability", "answer_data": [ "Identifier scope code (global, party-local, system-local)", "Resolvable IRI or URN form where one exists", "Namespace or authority reference" ] }, { "id": "cp-chan-q-id-vs-value", "text": "What distinguishes the contact-point record identity from the endpoint value that natural-key strategies would otherwise use?", "kind": "definition", "answer_data": [ "Record identifier", "Current endpoint value", "Statement of which attributes may change without a new record identifier" ] }, { "id": "cp-chan-q-id-dedup", "text": "How are two contact-point records that normalize to the same endpoint value for the same party reconciled?", "kind": "constraint", "answer_data": [ "Normalized comparison key", "Duplicate resolution outcome code", "Surviving record reference", "Merge or link decision timestamp" ] } ], "data_elements": [ { "id": "cp-chan-de-contact-point-id", "name": "Contact point identifier", "description": "Stable identifier of the contact-point record, assigned per the model identity priority and free of any date-like component.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-id-scheme", "name": "Identifier scheme", "description": "Code stating whether the identifier is a master-system key, a governed IRI/URN, or a locally assigned UUID/ULID.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-issuing-system-ref", "name": "Issuing system reference", "description": "Reference to the system of record that assigned the contact-point identifier.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-record-created-at", "name": "Record created at", "description": "Instant the contact-point record was first created in the holding system (ingestion time, distinct from endpoint validity start).", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-record-updated-at", "name": "Record updated at", "description": "Instant of the most recent modification to the contact-point record.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "cp-chan-de-normalized-key", "name": "Normalized comparison key", "description": "Scheme-specific canonical string used only for equality comparison and duplicate detection; never used as the record identifier.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] } ], "artifacts": [ { "id": "cp-chan-a-contact-point-record", "name": "Contact point record", "description": "The core object of this mixin: one identified contact point carrying its owning-party reference, classification facets, one typed endpoint value, validity state and links to verification assertions and supersession entries.", "media_or_form": [ "Structured record in any encoding", "Channel entry within a contact-data interchange object such as a JSContact Card phones/emails/onlineServices/addresses map entry", "vCard property instance group bound by PID/ALTID", "Row in a party contact register" ], "serial": false, "identity_strategy": "Use the authoritative master-system contact-point identifier from the party's contact system of record; if none exists, use a governed global identifier or IRI issued by the adopting Dimension; only if neither exists, mint a UUID or ULID. The endpoint value, a display label and any date are never used as the identifier.", "source_refs": [ "SRC-011", "SRC-010", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "cp-chan-f-party-binding", "name": "Owning-party reference and mixin attachment", "description": "Defines how a contact point attaches to exactly one owning or subject party and how shared, delegated and role-based arrangements are represented, without absorbing any party identity attributes. JSContact links channels to a Card; schema.org attaches ContactPoint to Person and Organization; the W3C vCard ontology links a Kind to channels via hasTelephone, hasEmail, hasAddress and hasURL. CPOV additionally shows contact points held by an organizational function rather than a natural person.", "source_refs": [ "SRC-011", "SRC-013", "SRC-014", "SRC-016" ], "questions": [ { "id": "cp-chan-q-party-owner", "text": "Which party does this contact point belong to, and under which identifier scheme is that party referenced?", "kind": "ownership", "answer_data": [ "Owning party reference", "Party identifier scheme code", "Party kind code (individual, org, group, location, device, application)" ] }, { "id": "cp-chan-q-party-shared", "text": "Can this endpoint be shared by more than one party, and how is shared or delegated use represented?", "kind": "relationship", "answer_data": [ "Sharing indicator", "Co-user party references", "Delegation basis description", "Primary-holder reference" ] }, { "id": "cp-chan-q-party-authority", "text": "Who is authorized to add, change or retire a contact point on behalf of the owning party?", "kind": "authority", "answer_data": [ "Authorized steward reference", "Authority basis code", "Self-service permitted flag" ] }, { "id": "cp-chan-q-party-role-based", "text": "Is this contact point held for a role or function rather than for a named natural person, and how is that flagged?", "kind": "classification", "answer_data": [ "Role-based indicator", "Role or function label", "Responsible organizational unit reference" ] } ], "data_elements": [ { "id": "cp-chan-de-owning-party-ref", "name": "Owning party reference", "description": "Reference to the single party that owns or is the subject of this contact point.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-013" ] }, { "id": "cp-chan-de-party-kind", "name": "Owning party kind", "description": "Coded kind of the owning party, aligned to JSContact Card kind values (individual, group, org, location, device, application).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-role-based-flag", "name": "Role-based indicator", "description": "Boolean stating the contact point serves a function or role rather than a specific natural person.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-steward-ref", "name": "Authorized steward reference", "description": "Reference to an identity steward or delegate permitted to maintain this contact point on the party's behalf.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-shared-use-flag", "name": "Shared use indicator", "description": "Boolean stating the endpoint value is known to be reachable by parties other than the owner.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "The binding is a reference tuple carried on the contact-point record, not a separate deliverable. The party record, its identifier scheme, its identity resolution and its lifecycle are owned by the party model; materializing a local party artifact here would duplicate a target-owned entity and create a second, divergent source of party identity." } ] }, { "id": "cp-chan-l-classification", "name": "Endpoint classification facets", "description": "The orthogonal classification axes that determine parsing, validation and intended use: addressing scheme/medium, purpose context, and technical capability.", "source_refs": [ "SRC-011", "SRC-010", "SRC-013", "SRC-009" ], "findings": [ { "id": "cp-chan-f-endpoint-kind", "name": "Endpoint kind and addressing scheme", "description": "The medium and addressing scheme that select which syntax, canonicalization and validation rules apply. JSContact partitions channels into phones, emails, onlineServices and addresses; vCard into TEL, EMAIL, ADR, URL and IMPP; RFC 3986 makes the URI scheme the determinant of scheme-based normalization. Endpoint kind must be declared explicitly because a bare value string is frequently ambiguous across schemes.", "source_refs": [ "SRC-011", "SRC-010", "SRC-009", "SRC-013" ], "questions": [ { "id": "cp-chan-q-kind-scheme", "text": "Which addressing scheme governs the syntax of this endpoint value, and which specification defines that scheme?", "kind": "classification", "answer_data": [ "Endpoint kind code", "URI scheme where applicable", "Governing specification reference and version" ] }, { "id": "cp-chan-q-kind-derivation", "text": "Is the endpoint kind derivable from the value itself, or must it be declared independently of the stored value?", "kind": "definition", "answer_data": [ "Declared endpoint kind", "Derivation method code (declared, scheme-inferred, heuristically inferred)", "Confidence or assertion basis" ] }, { "id": "cp-chan-q-kind-codelist", "text": "Which code list is authoritative for endpoint kind, and how are emerging or unregistered channel types admitted?", "kind": "interoperability", "answer_data": [ "Code list reference", "Registered value", "Extension value with governing namespace", "Registration status" ] }, { "id": "cp-chan-q-kind-ambiguity", "text": "What happens when a value is syntactically valid under more than one scheme, such as a digit string usable as both a telephone number and a messaging handle?", "kind": "exception", "answer_data": [ "Ambiguity flag", "Disambiguating service or context identifier", "Resolution rule applied", "Rejected candidate schemes" ] } ], "data_elements": [ { "id": "cp-chan-de-endpoint-kind", "name": "Endpoint kind", "description": "Coded medium of the contact point (telephone, email, postal, web-uri, online-service, other).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "cp-chan-de-uri-scheme", "name": "URI scheme", "description": "Scheme component of the endpoint value where the endpoint is expressed as a URI, used to select scheme-based normalization.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "cp-chan-de-governing-spec-ref", "name": "Governing specification reference", "description": "Reference to the specification and version that defines the syntax and comparison rules for this endpoint kind.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Endpoint kind is a coded reference value resolved against externally governed registries such as the IANA URI schemes registry and the property sets of vCard and JSContact. Minting a local artifact would fork a code list this model does not own and would drift from the registries that define the syntax rules the code selects." }, { "id": "cp-chan-f-purpose-and-capability", "name": "Purpose context and channel capability", "description": "Two orthogonal facets distinct from the medium and from preference ranking: use context (JSContact contexts such as private, work, billing, delivery; vCard TYPE; schema.org contactType and contactOption) and technical capability (JSContact features such as mobile, voice, text, video, fax; vCard TEL TYPE values). Also carries service scope (schema.org areaServed, availableLanguage). Declaring a purpose states intended use only; permission to use the channel for that purpose is a consent-model decision.", "source_refs": [ "SRC-011", "SRC-010", "SRC-013", "SRC-016" ], "questions": [ { "id": "cp-chan-q-purpose-context", "text": "For which use contexts or business purposes is this endpoint intended, and are multiple contexts simultaneously applicable?", "kind": "classification", "answer_data": [ "Purpose context codes", "Multi-context indicator", "Context code list reference" ] }, { "id": "cp-chan-q-capability-basis", "text": "Which technical capabilities does the endpoint support, and were those capabilities declared by the party or observed by a system?", "kind": "quality", "answer_data": [ "Capability feature codes", "Assertion basis code (declared, observed, inferred)", "Observation source reference", "Basis recorded timestamp" ] }, { "id": "cp-chan-q-purpose-permission", "text": "Does recording a purpose context here imply any permission to contact the party for that purpose?", "kind": "constraint", "answer_data": [ "Explicit no-permission statement", "Reference to the governing consent or legal-basis record", "Purpose-to-permission mapping owner" ] }, { "id": "cp-chan-q-service-scope", "text": "Which geographic or linguistic service scope applies to this contact point?", "kind": "spatial", "answer_data": [ "Area served reference or text", "Available language tags", "Scope assertion source" ] } ], "data_elements": [ { "id": "cp-chan-de-purpose-context", "name": "Purpose context", "description": "Coded use context of the endpoint, aligned to JSContact contexts, vCard TYPE and schema.org contactType.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010", "SRC-013" ] }, { "id": "cp-chan-de-capability-feature", "name": "Capability feature", "description": "Coded technical capability of the endpoint such as mobile, voice, text, video, fax or pager.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "cp-chan-de-capability-basis", "name": "Capability assertion basis", "description": "Code stating whether a capability was declared by the party, observed by a system probe, or inferred from number ranges or provider data.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-area-served", "name": "Area served", "description": "Geographic scope in which this contact point is intended to serve, expressed as a reference to an administrative area or place.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "cp-chan-de-available-language", "name": "Available language", "description": "Language tag for communication supported on this channel.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Purpose and capability are coded facets attached to an endpoint already materialized by the typed endpoint artifacts; they have no independent existence or serialization. Permission to use a channel for a purpose is a consent and legal-basis determination owned by a separate model, so no local permission artifact is created here." } ] } ] }, { "id": "cp-chan-b-endpoints", "name": "Addressable channel endpoints and value forms", "description": "The typed addressable endpoint values themselves - telephone, email, web/URI and online service, and postal delivery - together with their canonical, display and URI forms and the internationalization rules that govern them.", "rationale": "Each addressing scheme has its own normative syntax, canonical form and comparison rules from a different standards body: ITU-T for telephone numbers, IETF for mailboxes and URIs, UPU for postal delivery. Modelling them under one untyped value field would make correct validation, comparison and rendition impossible.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-005", "SRC-009", "SRC-011", "SRC-012" ], "layers": [ { "id": "cp-chan-l-telecom-endpoints", "name": "Telephone and mailbox endpoints", "description": "The two endpoint kinds with the strictest normative syntax and the most consequential normalization pitfalls: E.164 telephone numbers and RFC 5321 mailboxes.", "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-007" ], "findings": [ { "id": "cp-chan-f-telephone-endpoint", "name": "Telephone endpoint canonical, URI and display forms", "description": "A telephone endpoint is stored as an E.164 international number of at most 15 digits, structured as country code (1-3 digits) plus national destination code plus subscriber number, or as a local number that RFC 3966 requires to be qualified by a phone-context. The tel URI is the interoperable projection; E.123 governs the human-readable display notation. Visual separators are disregarded in comparison, so a separate canonical form must be stored alongside any display form. Extensions and dialling prefixes are carried outside the canonical digit string.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004", "SRC-011", "SRC-010" ], "questions": [ { "id": "cp-chan-q-tel-global-local", "text": "Is the stored number a global E.164 number, or a local number that requires a phone-context to be unambiguous?", "kind": "constraint", "answer_data": [ "Global number indicator", "E.164 digit string", "Phone-context value (domain name or leading digits of a global number)", "Country code" ] }, { "id": "cp-chan-q-tel-canonical", "text": "What is the canonical machine form of this telephone endpoint, and which characters are significant when two numbers are compared?", "kind": "validation", "answer_data": [ "Canonical digit string without visual separators", "Digit count validated against the 15-digit maximum", "Comparison rule reference", "Validation outcome code" ] }, { "id": "cp-chan-q-tel-display", "text": "How is the human-readable display form derived, and which notation standard governs its spacing and symbols?", "kind": "interoperability", "answer_data": [ "Display notation string", "Notation standard reference", "Locale used for formatting", "Derivation is lossy indicator" ] }, { "id": "cp-chan-q-tel-extension", "text": "How are extensions, dialling prefixes and subaddresses represented without corrupting the canonical number?", "kind": "requirement", "answer_data": [ "Extension value held in a separate element", "ISDN subaddress value", "Prefix stripping rule applied", "tel URI parameter rendering" ] } ], "data_elements": [ { "id": "cp-chan-de-e164-number", "name": "E.164 number", "description": "Canonical international number in leading-plus digit form, at most 15 digits, with no visual separators.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "cp-chan-de-country-code", "name": "Country code", "description": "The 1-to-3 digit ITU-T country code component of the international number.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "cp-chan-de-is-global-number", "name": "Global number indicator", "description": "Boolean stating the number is a global (leading plus) number rather than a context-qualified local number.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "cp-chan-de-phone-context", "name": "Phone context", "description": "Mandatory qualifier for local numbers: a domain name or the leading digits of a global number that make the local number globally unique.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "cp-chan-de-tel-uri", "name": "tel URI", "description": "RFC 3966 projection of the telephone endpoint, including any phone-context and extension parameters.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "id": "cp-chan-de-tel-extension", "name": "Telephone extension", "description": "Extension digits dialled after connection, held separately from the canonical number.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "cp-chan-de-tel-display", "name": "Telephone display notation", "description": "Human-readable rendering of the number using the notation of ITU-T E.123 or a locale convention.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "cp-chan-a-telephone-endpoint", "name": "Telephone endpoint value object", "description": "The typed telephone endpoint carried by a contact point, holding the canonical E.164 form, optional phone-context and extension, the tel URI projection and the display notation as parallel representations of one endpoint.", "media_or_form": [ "E.164 canonical digit string with leading plus", "tel URI per RFC 3966", "E.123 display notation string", "JSContact Phone object or vCard TEL property instance" ], "serial": false, "identity_strategy": "Identified by the parent authoritative master-system contact-point identifier; the canonical E.164 string serves only as a comparison key, never as the record identifier, because a number may be reassigned by a carrier to a different party over time.", "source_refs": [ "SRC-002", "SRC-004", "SRC-003", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "cp-chan-f-email-endpoint", "name": "Email mailbox endpoint and normalization limits", "description": "An email endpoint is an RFC 5321 mailbox of the form local-part@domain. The local-part MUST be treated as case sensitive and its case preserved, while the domain follows case-insensitive DNS rules; case-folding the whole address is therefore a defect, not a normalization. Internationalized email permits UTF-8 in both local part and domain, and RFC 6530 removes any requirement for a paired all-ASCII address, so an ASCII fallback is an optional, separately sourced assertion. IDN domains must be recorded so that A-label and U-label forms remain convertible.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-008", "SRC-011", "SRC-010" ], "questions": [ { "id": "cp-chan-q-email-case", "text": "Which portion of this mailbox may be case-folded during normalization and which portion must be preserved exactly as supplied?", "kind": "validation", "answer_data": [ "Local-part string as supplied", "Domain string", "Case-folding rule applied per component", "Normalization profile reference" ] }, { "id": "cp-chan-q-email-i18n-scope", "text": "Does this mailbox contain non-ASCII characters in the local part, in the domain, or in both?", "kind": "classification", "answer_data": [ "Internationalized address indicator", "Non-ASCII component flags", "Required SMTP extension support flag" ] }, { "id": "cp-chan-q-email-fallback", "text": "Is an ASCII fallback address recorded, and on whose authority is it treated as equivalent to the internationalized address?", "kind": "exception", "answer_data": [ "Fallback address value", "Equivalence asserting party reference", "Equivalence basis statement", "Absence-of-requirement note" ] }, { "id": "cp-chan-q-email-idn-forms", "text": "How is the domain part recorded when both A-label and U-label forms exist for the same name?", "kind": "interoperability", "answer_data": [ "A-label form", "U-label form in Normalization Form C", "Convertibility verified flag", "Form used for transmission" ] } ], "data_elements": [ { "id": "cp-chan-de-mailbox-addr-spec", "name": "Mailbox addr-spec", "description": "The complete mailbox in local-part@domain form, stored with local-part case preserved.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-011" ] }, { "id": "cp-chan-de-mailbox-local-part", "name": "Mailbox local part", "description": "Local-part component, case sensitive and never case-folded during storage or comparison.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "cp-chan-de-mailbox-domain", "name": "Mailbox domain", "description": "Domain component, compared case-insensitively per DNS rules.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "cp-chan-de-domain-a-label", "name": "Domain A-label form", "description": "ASCII-compatible encoding of an internationalized domain, prefixed xn-- and convertible to the U-label.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "cp-chan-de-domain-u-label", "name": "Domain U-label form", "description": "Unicode form of an internationalized domain in Normalization Form C.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "cp-chan-de-is-internationalized-mailbox", "name": "Internationalized mailbox indicator", "description": "Boolean stating the mailbox requires internationalized email support because a component contains non-ASCII characters.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "cp-chan-de-mailto-uri", "name": "mailto URI", "description": "RFC 6068 projection of the mailbox with percent-encoding applied to reserved and non-ASCII octets.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "cp-chan-a-email-endpoint", "name": "Email mailbox endpoint value object", "description": "The typed mailbox endpoint carried by a contact point, holding the addr-spec with case-preserved local part, the domain in both A-label and U-label forms where applicable, and the mailto URI projection.", "media_or_form": [ "RFC 5321 addr-spec string", "mailto URI per RFC 6068", "UTF-8 internationalized mailbox string", "JSContact EmailAddress object or vCard EMAIL property instance" ], "serial": false, "identity_strategy": "Identified by the parent authoritative master-system contact-point identifier; the addr-spec is a comparison key only, since mailboxes are routinely reassigned and since case-sensitive local parts make value equality an unsafe identity basis.", "source_refs": [ "SRC-005", "SRC-006", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-chan-l-web-postal-endpoints", "name": "Web, service and postal endpoints", "description": "Endpoint kinds addressed by URI or by physical delivery: web pages, online-service and messaging handles, and postal delivery points.", "source_refs": [ "SRC-009", "SRC-011", "SRC-012", "SRC-014" ], "findings": [ { "id": "cp-chan-f-web-service-endpoint", "name": "Web URI and online-service endpoint", "description": "Covers generic URI endpoints (web page, profile page, contact page) and online-service or messaging handles. RFC 3986 supplies the component model and the graduated comparison ladder: simple string comparison, then syntax-based normalization (case of scheme and host, percent-encoding, dot-segment removal), then scheme-based and protocol-based normalization. JSContact OnlineService allows a service name, a URI, a user handle, or a combination, because many messaging handles have no resolvable URI. Public profile URIs address the party only indirectly and carry a different exposure profile from private channels.", "source_refs": [ "SRC-009", "SRC-011", "SRC-010", "SRC-014", "SRC-016" ], "questions": [ { "id": "cp-chan-q-uri-components", "text": "Which URI scheme and authority identify this endpoint, and is the recorded URI absolute rather than relative?", "kind": "identity", "answer_data": [ "Absolute URI string", "Scheme component", "Authority component", "Absoluteness validation outcome" ] }, { "id": "cp-chan-q-uri-normalization", "text": "Which normalization steps may be applied before two URI endpoints are treated as equivalent?", "kind": "validation", "answer_data": [ "Normalization level applied", "Case-normalized components", "Percent-encoding normalization result", "Scheme-specific equivalence rule reference" ] }, { "id": "cp-chan-q-service-handle", "text": "When a messaging handle is recorded without a resolvable URI, which service identifier disambiguates the handle?", "kind": "composition", "answer_data": [ "Service name", "User handle string", "Service identifier namespace", "Resolvable URI present indicator" ] }, { "id": "cp-chan-q-uri-exposure", "text": "Does this endpoint address the party directly, or a publicly readable profile that third parties also observe?", "kind": "privacy", "answer_data": [ "Direct-addressing indicator", "Public visibility indicator", "Exposure classification code" ] } ], "data_elements": [ { "id": "cp-chan-de-endpoint-uri", "name": "Endpoint URI", "description": "Absolute URI addressing the endpoint, recorded with syntax-based normalization applied but scheme-specific normalization recorded separately.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "cp-chan-de-service-name", "name": "Online service name", "description": "Name of the messaging or social service on which the handle is valid.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-service-handle", "name": "Service user handle", "description": "User identifier within the named service, used when no resolvable URI exists.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-uri-normalization-profile", "name": "URI normalization profile", "description": "Code identifying which level of the RFC 3986 comparison ladder was applied to the stored value.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "cp-chan-de-public-visibility", "name": "Public visibility indicator", "description": "Boolean stating the endpoint is a publicly readable location rather than a private addressable channel.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "cp-chan-a-uri-endpoint", "name": "URI or service endpoint value object", "description": "The typed URI or online-service endpoint carried by a contact point, holding either an absolute URI, a service-plus-handle pair, or both, with the applied normalization profile recorded so that equivalence decisions are reproducible.", "media_or_form": [ "Absolute URI per RFC 3986", "Service name plus user handle pair", "Percent-encoded internationalized form", "JSContact OnlineService object or vCard URL/IMPP property instance" ], "serial": false, "identity_strategy": "Identified by the parent authoritative master-system contact-point identifier; where the adopting Dimension publishes contact data as linked data, a governed IRI may additionally be minted, but the URI value itself is never the record identifier because handles are transferable.", "source_refs": [ "SRC-009", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "cp-chan-f-postal-endpoint", "name": "Postal delivery endpoint reference and delivery role", "description": "A contact point may designate a postal delivery endpoint. UPU S42 Part A defines the postal address component set and Part B the country-specific templates that render components into a correctly formatted address; that structure, its maintenance and any geocoding belong to the postal-address and place models. This model carries the reference to the addressed location, the country binding that selects the template, and the delivery-role attributes that are properties of the contact arrangement rather than of the location: attention line, care-of, and mailbox or post-office-box designation.", "source_refs": [ "SRC-012", "SRC-011", "SRC-010", "SRC-014" ], "questions": [ { "id": "cp-chan-q-postal-reference", "text": "Which addressed location does this postal contact point designate, and by which reference is that location identified?", "kind": "composition", "answer_data": [ "Addressed location reference", "Reference scheme", "Full address text captured at time of reference", "Reference resolution status" ] }, { "id": "cp-chan-q-postal-template", "text": "Which country template and postal component set govern rendition of this address for delivery?", "kind": "interoperability", "answer_data": [ "Country code", "Template library reference", "Component set version", "Rendition owner reference" ] }, { "id": "cp-chan-q-postal-role", "text": "Which delivery-specific attributes belong to the contact point rather than to the location itself?", "kind": "definition", "answer_data": [ "Attention line", "Care-of party name", "Mailbox or post-office-box designation", "Statement of the component/role split" ] }, { "id": "cp-chan-q-postal-nature", "text": "Is the delivery point a place the party occupies, or purely a mail-receipt arrangement such as a box or forwarding agent?", "kind": "classification", "answer_data": [ "Delivery point nature code", "Occupancy indicator", "Forwarding agent reference" ] } ], "data_elements": [ { "id": "cp-chan-de-postal-location-ref", "name": "Addressed location reference", "description": "Reference to the address or place record held by the postal-address/place model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] }, { "id": "cp-chan-de-postal-country-code", "name": "Postal country code", "description": "ISO 3166-1 alpha-2 country code selecting the applicable country template, as required by JSContact Address countryCode.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "cp-chan-de-attention-line", "name": "Attention line", "description": "Recipient-routing line naming the person or unit to whose attention items are delivered.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] }, { "id": "cp-chan-de-care-of", "name": "Care-of party", "description": "Party through whom delivery is routed when the recipient is not the occupant of the addressed location.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "cp-chan-de-delivery-designation", "name": "Delivery service designation", "description": "Post-office box, private bag, poste restante or comparable delivery-service designation attached to the contact arrangement.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] }, { "id": "cp-chan-de-address-full-text", "name": "Captured full address text", "description": "Free-text rendering of the address as supplied, retained only as provenance for the reference and never as the authoritative component structure.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "The structured postal address components, the country template library and the rendition rules are defined and maintained under UPU S42 Parts A and B and materialized by the postal-address and place models. Producing a local address artifact here would duplicate a target-owned structure, desynchronize from the template library and create a second address of record; this model therefore holds only reference and delivery-role fields inline." } ] }, { "id": "cp-chan-l-internationalization", "name": "Internationalization of endpoint values", "description": "Script, encoding, normalization and localization rules that cut across all endpoint kinds.", "source_refs": [ "SRC-008", "SRC-007", "SRC-011", "SRC-012" ], "findings": [ { "id": "cp-chan-f-internationalization", "name": "Script, normalization and localized forms", "description": "Endpoint values and their labels must survive non-ASCII scripts. IDNA2008 requires U-labels to be in Normalization Form C and A-labels and U-labels to be mutually convertible; RFC 6530 permits UTF-8 throughout a mailbox; RFC 6068 defines percent-encoded UTF-8 for URI carriage. JSContact separates a card-level language tag from a localizations map that applies locale-specific overrides by JSON Pointer rather than duplicating the object. UPU reports at least twenty scripts in official postal use, so transliteration authority must be recorded rather than assumed.", "source_refs": [ "SRC-008", "SRC-007", "SRC-006", "SRC-011", "SRC-012" ], "questions": [ { "id": "cp-chan-q-i18n-normalization", "text": "Which Unicode normalization form is required before an endpoint value is stored or compared?", "kind": "validation", "answer_data": [ "Normalization form code", "Pre-normalization value", "Post-normalization value", "Normalization applied at ingestion flag" ] }, { "id": "cp-chan-q-i18n-language", "text": "Which language tag applies to the human-readable label for this endpoint?", "kind": "classification", "answer_data": [ "Label text", "Language tag", "Default language of the containing profile" ] }, { "id": "cp-chan-q-i18n-variants", "text": "How are localized alternative forms of one endpoint recorded without creating duplicate contact points?", "kind": "composition", "answer_data": [ "Localization variant set keyed by locale", "Pointer or key linking each variant to the base value", "Cardinality rule stating variants do not multiply the contact point" ] }, { "id": "cp-chan-q-i18n-transliteration", "text": "Which script or transliteration variant is authoritative when a source system supplies more than one?", "kind": "authority", "answer_data": [ "Authoritative variant identifier", "Transliteration standard or authority reference", "Non-authoritative variants retained for search" ] } ], "data_elements": [ { "id": "cp-chan-de-normalization-form", "name": "Unicode normalization form", "description": "Code stating the Unicode normalization form applied to the stored value; Normalization Form C where IDNA U-labels are involved.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "cp-chan-de-label-text", "name": "Endpoint label", "description": "Human-readable label describing the endpoint, distinct from the endpoint value itself.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-label-language", "name": "Label language tag", "description": "Language tag identifying the language of the label and of the localized variant.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-localization-variant", "name": "Localization variant", "description": "Locale-keyed override of one or more fields of the endpoint, applied without duplicating the contact point.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-transliteration-authority", "name": "Transliteration authority", "description": "Reference to the standard, authority or source system that produced a script variant of the value.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Internationalization manifests as constraints and parallel value forms on the telephone, mailbox and URI endpoint artifacts already declared. Materializing localized variants as separate artifacts would fragment one endpoint across multiple records, break the A-label/U-label equivalence guarantee and inflate contact-point counts for what is a single reachable channel." } ] } ] }, { "id": "cp-chan-b-assurance", "name": "Endpoint assurance, validity and supersession", "description": "The evidence and time dimensions of a contact point: what was proven about control of the endpoint, when the endpoint is valid, whether it is currently reachable, and which contact point replaces it.", "rationale": "OpenID Connect models verified state as a provider assertion rather than an intrinsic property; NIST SP 800-63A places proofing procedure and assurance levels in a separate discipline; CPOV models contact availability as a temporal entity. Together these establish that assurance, validity and reachability are carried on the contact point but sourced and executed elsewhere.", "source_refs": [ "SRC-015", "SRC-017", "SRC-016", "SRC-011" ], "layers": [ { "id": "cp-chan-l-verification", "name": "Verification assertions", "description": "Assertions of proof of control over an endpoint, carried on the contact point without importing the proofing process.", "source_refs": [ "SRC-015", "SRC-017" ], "findings": [ { "id": "cp-chan-f-verification-assertion", "name": "Carried verification assertion for endpoint control", "description": "A contact point may carry the outcome of a proof-of-control check: which authority asserted it, which method class was used, which assurance level is claimed, when it was asserted, and when it expires. OpenID Connect defines email_verified and phone_number_verified as claims asserted by an issuing provider, which makes the asserting party a required part of the record. NIST SP 800-63A owns proofing and enrollment procedure and its assurance framing; this model therefore records the assertion and a reference to its evidence, and never the challenge issuance, evaluation logic, decision engine or proofing audit trail.", "source_refs": [ "SRC-015", "SRC-017", "SRC-011" ], "questions": [ { "id": "cp-chan-q-verify-authority", "text": "Which authority asserted that the owning party controls this endpoint, and at what instant was the assertion made?", "kind": "provenance", "answer_data": [ "Asserting authority reference", "Assertion identifier", "Assertion instant", "Assertion subject binding to the contact-point identifier" ] }, { "id": "cp-chan-q-verify-method", "text": "Which verification method class and assurance level does the assertion claim?", "kind": "evidence", "answer_data": [ "Method class code", "Assurance level code and framework reference", "Evidence reference held by the proofing model", "Claim scope statement" ] }, { "id": "cp-chan-q-verify-expiry", "text": "Does the assertion expire, and which events invalidate it before its stated expiry?", "kind": "temporal", "answer_data": [ "Expiry instant or validity duration", "Invalidating event codes such as endpoint value change or supersession", "Re-verification due instant" ] }, { "id": "cp-chan-q-verify-boundary", "text": "Which system executed the proofing challenge, and where is the audit record of that execution held?", "kind": "security", "answer_data": [ "Executing system reference", "Audit record locator held by the referenced model", "Explicit statement that this model stores no execution or audit detail" ] } ], "data_elements": [ { "id": "cp-chan-de-verification-assertion-id", "name": "Verification assertion identifier", "description": "Identifier of the assertion as issued by the asserting authority.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "cp-chan-de-asserting-authority-ref", "name": "Asserting authority reference", "description": "Reference to the provider, steward or proofing service that made the verification assertion.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "cp-chan-de-verification-status", "name": "Verification status", "description": "Coded verified state of the endpoint, corresponding to claims such as email_verified or phone_number_verified.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "cp-chan-de-verification-method-class", "name": "Verification method class", "description": "Coded class of the proof-of-control method, recorded without the parameters or transcript of the run.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "cp-chan-de-assurance-level", "name": "Claimed assurance level", "description": "Assurance level claimed by the assertion together with the framework that defines it.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "cp-chan-de-verification-asserted-at", "name": "Assertion instant", "description": "Instant at which the asserting authority made the assertion (event time).", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "cp-chan-de-verification-recorded-at", "name": "Assertion recorded at", "description": "Instant at which this model ingested the assertion (observation time), recorded separately from the assertion instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "cp-chan-de-verification-expires-at", "name": "Assertion expiry", "description": "Instant after which the assertion is no longer treated as current.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "cp-chan-de-verification-evidence-ref", "name": "Evidence reference", "description": "Opaque locator for the evidence held by the proofing or verification model; this model stores the locator only.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "cp-chan-a-verification-assertion", "name": "Channel verification assertion", "description": "A carried, self-contained assertion binding a contact-point identifier to a claim of proven control, with asserting authority, method class, assurance level, event and observation timestamps, expiry and an evidence locator. It is an inbound record, never a log of this model's own processing.", "media_or_form": [ "Assertion record in any encoding", "Verified-claim payload such as an OpenID Connect email_verified or phone_number_verified claim", "Signed attestation with a dereferenceable evidence locator" ], "serial": false, "identity_strategy": "Use the assertion identifier issued by the asserting authority as the authoritative master-system identifier; where an authority issues none, mint a governed IRI or, failing that, a UUID or ULID in the adopting Dimension and record the authority reference alongside it. The assertion instant is never used as the identifier.", "source_refs": [ "SRC-015", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-chan-l-validity-supersession", "name": "Validity, reachability and supersession", "description": "Time-bounded validity of the contact point, its derived operational reachability status, and the ordered replacement chain that links retired contact points to their successors.", "source_refs": [ "SRC-016", "SRC-011", "SRC-010", "SRC-005" ], "findings": [ { "id": "cp-chan-f-validity-interval", "name": "Validity interval and lifecycle state", "description": "A contact point is valid over an interval and holds a lifecycle state. CPOV models contact availability and availability restriction as temporal entities; JSContact and vCard carry only created/updated and REV, so a normative valid-from/valid-to on a contact point is not supplied by the cited contact standards and is declared here as an adopting-Dimension extension rather than as a standards claim. Open-ended intervals, scheduled future changes and asserted past end dates must be distinguishable.", "source_refs": [ "SRC-016", "SRC-011", "SRC-010" ], "questions": [ { "id": "cp-chan-q-validity-interval", "text": "From which instant until which instant is this contact point valid for use by the owning party?", "kind": "temporal", "answer_data": [ "Valid-from instant", "Valid-to instant or open-ended marker", "Time zone or offset used", "Interval closedness convention" ] }, { "id": "cp-chan-q-validity-state", "text": "Which lifecycle state does the contact point currently hold, and which state transitions are permitted from it?", "kind": "lifecycle", "answer_data": [ "Lifecycle state code", "Permitted transition set", "Transition trigger", "Transition recorded instant" ] }, { "id": "cp-chan-q-validity-assertion-nature", "text": "Is a recorded end date an assertion of past fact or a scheduled future change, and how is a still-open interval represented?", "kind": "state", "answer_data": [ "End-date nature code (asserted, scheduled)", "Open-interval representation convention", "Scheduled-change effective instant" ] }, { "id": "cp-chan-q-validity-recurrence", "text": "Are there recurring windows within the validity interval during which the contact point is available or restricted?", "kind": "requirement", "answer_data": [ "Availability window specification", "Availability restriction specification", "Time zone reference", "Recurrence expression" ] } ], "data_elements": [ { "id": "cp-chan-de-valid-from", "name": "Valid from", "description": "Instant from which the contact point is valid for use (event time).", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-valid-to", "name": "Valid to", "description": "Instant after which the contact point ceases to be valid; absent means the interval is open-ended.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-lifecycle-state", "name": "Lifecycle state", "description": "Coded state of the contact point such as proposed, active, suspended, superseded or retired.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-end-date-nature", "name": "End-date nature", "description": "Code distinguishing an asserted past end from a scheduled future change.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-availability-window", "name": "Availability window", "description": "Recurring window during which the contact point is normally available, aligned to CPOV opening hours.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-013" ] }, { "id": "cp-chan-de-availability-restriction", "name": "Availability restriction", "description": "Interval or recurrence during which the contact point is explicitly not available.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Validity is expressed as two instants, a state code and optional recurrence expressions carried directly on the contact-point record; it has no independent serialization and no consumer that needs it apart from the record it qualifies. It is recorded inline precisely because no cited contact standard defines it as a separate object, so inventing an artifact would present an unsupported structure as canonical." }, { "id": "cp-chan-f-reachability-status", "name": "Operational reachability status", "description": "A derived, time-stamped statement of whether the endpoint currently appears reachable, together with a locator for the evidence that supports it. The underlying transmission, delivery status, failure reports and engagement records are owned by the communication/message model under SMTP and comparable transport specifications; this model carries only the summarized status, its observation instant and the evidence reference. Reachability is deliberately separated from validity: an endpoint may be valid but temporarily unreachable, or reachable but no longer valid for the party.", "source_refs": [ "SRC-005", "SRC-016", "SRC-011" ], "questions": [ { "id": "cp-chan-q-reach-status", "text": "What is the last recorded reachability status of this endpoint and at which instant was it observed?", "kind": "measurement", "answer_data": [ "Reachability status code", "Observation instant", "Observation window", "Status confidence" ] }, { "id": "cp-chan-q-reach-evidence", "text": "Which evidence supports the recorded reachability status, and in which model is that evidence held?", "kind": "evidence", "answer_data": [ "Evidence locator", "Holding model reference", "Evidence class code", "Explicit statement that no attempt log is stored locally" ] }, { "id": "cp-chan-q-reach-consequence", "text": "Does an unreachable status invalidate the contact point, or only suppress its operational use?", "kind": "decision", "answer_data": [ "Consequence code", "Suppression scope", "Escalation threshold", "Decision owner reference" ] }, { "id": "cp-chan-q-reach-authority", "text": "Who may set or override reachability status, and may it be set without an underlying observation?", "kind": "process", "answer_data": [ "Permitted setter roles", "Manual override permitted flag", "Override justification text", "Setter identity reference" ] } ], "data_elements": [ { "id": "cp-chan-de-reachability-status", "name": "Reachability status", "description": "Coded operational status such as reachable, degraded, unreachable-transient, unreachable-permanent or unknown.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "cp-chan-de-reachability-observed-at", "name": "Reachability observed at", "description": "Observation instant for the recorded status, distinct from the instant the status was ingested or from any endpoint event time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "cp-chan-de-reachability-evidence-ref", "name": "Reachability evidence reference", "description": "Locator for the delivery or probe evidence held by the communication/message model; never the evidence itself.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "cp-chan-de-reachability-setter-ref", "name": "Reachability status setter", "description": "Reference to the system or role that set the current status, including manual overrides.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Reachability is a derived summary field plus an evidence locator on the contact-point record. Declaring an artifact here would create a local observation store and would drift toward owning delivery-attempt, bounce and audit-trail semantics that belong to the referenced communication/message model; keeping it inline enforces that boundary structurally." }, { "id": "cp-chan-f-supersession", "name": "Supersession and replacement chain", "description": "When a party changes an endpoint, the old contact point is superseded rather than overwritten, so that verification assertions, historical references and inbound links remain interpretable. Supersession is an ordered, acyclic chain with an effective instant per link. No cited contact standard defines supersession for contact points - vCard offers only REV and JSContact only created/updated - so this is declared as an adopting-Dimension extension built on the identity separation those standards do provide.", "source_refs": [ "SRC-011", "SRC-010", "SRC-016" ], "questions": [ { "id": "cp-chan-q-supersede-successor", "text": "Which contact point replaces this one, and from which effective instant does the replacement apply?", "kind": "relationship", "answer_data": [ "Predecessor contact-point identifier", "Successor contact-point identifier", "Effective instant", "Supersession reason code" ] }, { "id": "cp-chan-q-supersede-retention", "text": "Is a superseded contact point retained for historical interpretation, or disposed once the successor is active?", "kind": "retention", "answer_data": [ "Retention decision code", "Retention period", "Governing retention policy reference", "Tombstone content specification" ] }, { "id": "cp-chan-q-supersede-traversal", "text": "How is a supersession chain traversed to obtain the currently effective endpoint for a historical reference?", "kind": "process", "answer_data": [ "Traversal rule", "Chain depth limit", "Terminal node marker", "Resolution outcome when the chain ends in a retired node" ] }, { "id": "cp-chan-q-supersede-integrity", "text": "What prevents a supersession cycle or a fork with two concurrent successors?", "kind": "constraint", "answer_data": [ "Acyclicity constraint statement", "Single-active-successor rule", "Conflict detection outcome", "Rejected link record" ] } ], "data_elements": [ { "id": "cp-chan-de-supersedes-ref", "name": "Supersedes reference", "description": "Reference from a contact point to the contact point it replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-superseded-by-ref", "name": "Superseded-by reference", "description": "Reference from a retired contact point to its active successor.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-chan-de-supersession-effective-at", "name": "Supersession effective instant", "description": "Event-time instant from which the successor is the effective contact point.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "cp-chan-de-supersession-reason", "name": "Supersession reason", "description": "Coded reason for replacement such as party-initiated change, carrier reassignment, employer change or correction of an error.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "cp-chan-de-supersession-sequence", "name": "Supersession sequence number", "description": "Monotonically increasing integer ordering supersession links within one contact-point chain.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "cp-chan-a-supersession-link", "name": "Supersession link entry", "description": "An ordered entry recording that one contact point replaces another from a stated effective instant, with a reason code and sequence number, forming an acyclic chain per contact point.", "media_or_form": [ "Ordered replacement link record", "Change-history entry in a party contact register", "Directed edge in a contact-point graph projection" ], "serial": true, "identity_strategy": "Identified by the predecessor's authoritative master-system contact-point identifier combined with the chain sequence number; where the adopting Dimension issues no master-system key, a governed IRI or a UUID/ULID is minted. The effective instant is never part of the identifier.", "source_refs": [ "SRC-011", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "cp-pref-bundle-declaration", "name": "Preference Declaration", "description": "What the party declares about how it wishes to be contacted: the scope a statement applies to, which modalities it prefers or asks to avoid, and the linguistic and accessibility directives that shape the communication itself.", "rationale": "Declaration is a coherent concern because every element is an assertion made by or for the party about desired treatment, independent of when contact happens or how a system resolves competing statements. Both vCard/JSContact and FHIR treat purpose context, preference ordering and language preference as properties of the contact description rather than of a transmission, which supports grouping them together and separating them from routing-time evaluation.", "source_refs": [ "SRC-011", "SRC-018", "SRC-013", "SRC-023", "SRC-026" ], "layers": [ { "id": "cp-pref-layer-scope-and-disposition", "name": "Applicability Scope and Channel Disposition", "description": "The scoping of a preference statement to a communication purpose and usage context, and the positive or negative disposition it expresses towards a channel modality.", "source_refs": [ "SRC-011", "SRC-018", "SRC-013", "SRC-023", "SRC-025" ], "findings": [ { "id": "cp-pref-finding-applicability-scope", "name": "Preference applicability scope: purpose class, context and capacity", "description": "The scope key that decides whether a preference statement applies to a given outbound or inbound interaction: the communication purpose class (for example service, administrative, scheduling, relationship or life-safety), the usage context (private or work), the party capacity in which the statement was made, and any profile-conditional flags that must be declared rather than assumed.", "source_refs": [ "SRC-011", "SRC-018", "SRC-013", "SRC-023" ], "questions": [ { "id": "cp-pref-q-purpose-class-set", "text": "Which communication purpose classes does this statement govern, and is the class list closed or extensible?", "kind": "classification", "answer_data": [ "purpose class code", "code system identifier and version", "extensibility rule for locally minted classes" ] }, { "id": "cp-pref-q-usage-context-value", "text": "Which usage context qualifies the statement, and what does an absent context mean?", "kind": "definition", "answer_data": [ "usage context code such as private or work", "default interpretation when context is absent", "whether contexts are mutually exclusive" ] }, { "id": "cp-pref-q-unclassified-request", "text": "How is an inbound contact request handled when it declares no purpose class at all?", "kind": "exception", "answer_data": [ "treatment rule for unclassified requests", "whether the most restrictive matching statement applies", "reason code returned to the requester" ] }, { "id": "cp-pref-q-multi-capacity-party", "text": "Which capacity does the statement cover when the same party acts as customer, employee and emergency contact?", "kind": "relationship", "answer_data": [ "party capacity or role reference", "scope key composition rule", "cross-capacity leakage prohibition" ] }, { "id": "cp-pref-q-profile-condition-flag", "text": "Which profile-conditional situations must be recorded explicitly instead of being inferred as defaults?", "kind": "requirement", "answer_data": [ "profile condition flag such as workplace contact, minor, vulnerable person or life-safety", "flag assertion authority", "explicit prohibition on inferring the flag" ] } ], "data_elements": [ { "id": "cp-pref-de-purpose-class", "name": "Purpose class", "description": "Code identifying the class of communication a statement governs.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-013", "SRC-023" ] }, { "id": "cp-pref-de-purpose-code-system", "name": "Purpose code system reference", "description": "Reference to the governed code system and version from which the purpose class is drawn.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "cp-pref-de-usage-context", "name": "Usage context", "description": "Context in which the contact information is to be used, such as private or work.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-023" ] }, { "id": "cp-pref-de-party-capacity", "name": "Party capacity", "description": "Reference to the capacity or role of the party under which the statement was made.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "cp-pref-de-profile-condition-flag", "name": "Profile condition flag", "description": "Explicitly asserted conditional situation that changes handling and must never be inferred.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-027" ] } ], "artifacts": [], "inline_only_rationale": "An applicability scope is a structured key made of codes and references that is evaluated at resolution time; it has no document form, no rendition and no separate custody. Capturing it as an artifact would create a second identity for something that only exists as an attribute set on a preference statement." }, { "id": "cp-pref-finding-preferred-modality", "name": "Preferred channel modality and relative preference ordering", "description": "The party's positive disposition towards one or more channel kinds within a scope, expressed as a relative preference value that points at a channel kind or an endpoint handle owned by the channel area, never at an address. Includes the semantics of an absent preference value and whether values are comparable across different channel kinds.", "source_refs": [ "SRC-011", "SRC-018", "SRC-023", "SRC-025" ], "questions": [ { "id": "cp-pref-q-preferred-kind-declared", "text": "Which channel kinds are declared preferred within this scope, and how is the preference value expressed numerically?", "kind": "definition", "answer_data": [ "channel kind code", "preference value on a stated scale", "direction of the scale, lower or higher meaning more preferred" ] }, { "id": "cp-pref-q-absent-preference-value", "text": "What does an absent preference value mean, and may a single valued instance be read on its own?", "kind": "constraint", "answer_data": [ "default interpretation of absence", "prohibition on absolute interpretation of a single value", "comparison set definition" ] }, { "id": "cp-pref-q-cross-kind-comparability", "text": "Are preference values comparable between different channel kinds, or only within the same kind?", "kind": "measurement", "answer_data": [ "comparison scope declaration", "normalisation rule when merging sets from different sources", "scale range and precision" ] }, { "id": "cp-pref-q-dangling-endpoint-reference", "text": "Which channel-kind or endpoint reference does the statement point to, and how is a reference that no longer resolves treated?", "kind": "relationship", "answer_data": [ "endpoint handle or channel kind reference", "reference resolution status", "behaviour on a dangling reference, excluded rather than assumed usable" ] } ], "data_elements": [ { "id": "cp-pref-de-channel-kind", "name": "Channel kind", "description": "Code for the modality a preference applies to, such as voice, text message, email, video or postal.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011", "SRC-025" ] }, { "id": "cp-pref-de-preference-rank", "name": "Preference rank value", "description": "Relative preference value within the declared comparison set, with the scale direction stated explicitly.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-023" ] }, { "id": "cp-pref-de-endpoint-handle-ref", "name": "Endpoint handle reference", "description": "Reference to an endpoint descriptor held in the channel area; the address itself is never copied here.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-023" ] }, { "id": "cp-pref-de-preference-comparison-scope", "name": "Preference comparison scope", "description": "Declared set within which preference values may be compared, preventing cross-set numeric merging.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] } ], "artifacts": [], "inline_only_rationale": "A modality preference is a small set of codes, references and one ordering value carried on the party record. It is consumed only by comparison at resolution time and has no standalone rendition, custody chain or media form that would justify artifact identity." }, { "id": "cp-pref-finding-avoidance-statement", "name": "Party-stated contact-avoidance preference", "description": "An advisory request by the party to avoid a particular combination of channel, purpose, context or time. It is a local operational preference only: it carries no legal effect, is never evidence of a legal position, and can only ever narrow the set of options that other inputs already allow.", "source_refs": [ "SRC-011", "SRC-018", "SRC-023" ], "questions": [ { "id": "cp-pref-q-avoidance-scope-precision", "text": "Which combination of channel, purpose, context and time does the party ask to avoid, and at what precision is that combination stated?", "kind": "definition", "answer_data": [ "avoidance scope key", "precision level, from whole channel kind down to a single endpoint handle", "free-text qualifier where the structured key is insufficient" ] }, { "id": "cp-pref-q-avoidance-versus-legal-record", "text": "How is this advisory statement distinguished in data from the legally governed restriction record held in the external registry?", "kind": "authority", "answer_data": [ "explicit local-advisory marker", "reference to the external restriction registry rather than a local copy", "prohibition on asserting legal effect through this element" ] }, { "id": "cp-pref-q-avoidance-monotonicity", "text": "Can this statement ever widen the set of permitted options relative to an external restriction?", "kind": "decision", "answer_data": [ "monotonic narrowing rule", "effect mode fixed to narrow-only", "test case showing the statement cannot re-permit a blocked option" ] }, { "id": "cp-pref-q-avoidance-firmness", "text": "What firmness does the party attach to the request, and how is that recorded without implying legal weight?", "kind": "quality", "answer_data": [ "firmness code such as soft or firm", "operator guidance text", "explicit non-legal disclaimer flag" ] }, { "id": "cp-pref-q-avoidance-duration", "text": "For how long does the request stay effective, and does it expire by default?", "kind": "temporal", "answer_data": [ "effective interval reference", "default expiry policy of the adopting Dimension", "renewal or reconfirmation trigger" ] } ], "data_elements": [ { "id": "cp-pref-de-avoidance-scope", "name": "Avoidance scope key", "description": "Structured combination of channel kind, purpose class, context and time frame the party asks to avoid.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-013" ] }, { "id": "cp-pref-de-avoidance-strength", "name": "Avoidance firmness", "description": "Code expressing how strongly the party states the request, with no legal meaning attached.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "cp-pref-de-avoidance-reason-text", "name": "Avoidance reason note", "description": "Optional party-supplied free text explaining the request; treated as restricted because it may reveal sensitive characteristics.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-pref-de-avoidance-effect-mode", "name": "Avoidance effect mode", "description": "Fixed marker recording that the statement can only remove options and never add them.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] } ], "artifacts": [], "inline_only_rationale": "The statement is a narrow structured record plus an optional note, evaluated inline by the advisory resolver. Giving it artifact identity would invite treating it as a standalone, transferable instrument, which is precisely the confusion with an externally governed legal restriction record that this model must prevent." } ] }, { "id": "cp-pref-layer-linguistic-accommodation", "name": "Linguistic and Accessibility Directives", "description": "How a communication must be expressed to reach the party: language, script and locale preference, and functional accessibility accommodation directives that constrain which channels can satisfy the request.", "source_refs": [ "SRC-011", "SRC-020", "SRC-022", "SRC-026" ], "findings": [ { "id": "cp-pref-finding-language-script", "name": "Language, script and locale preference for communication", "description": "The BCP 47 tags the party prefers for interaction, ordered and optionally qualified by usage context and modality, with explicit rules for when a script subtag carries meaning and what happens when no preferred language can be honoured.", "source_refs": [ "SRC-011", "SRC-018", "SRC-020", "SRC-013" ], "questions": [ { "id": "cp-pref-q-language-tag-order", "text": "Which language tags does the party prefer for written and for spoken interaction, and in what order?", "kind": "classification", "answer_data": [ "BCP 47 language tag", "modality qualifier such as written, spoken or signed", "preference order value within the modality" ] }, { "id": "cp-pref-q-script-subtag-rule", "text": "When must a script subtag be carried on a preference tag, and when should it be omitted?", "kind": "constraint", "answer_data": [ "script subtag value", "Suppress-Script registry check outcome", "distinguishing-value justification for retaining a script subtag" ] }, { "id": "cp-pref-q-language-per-context", "text": "Does the language preference differ by usage context, and how are competing per-context orders reconciled?", "kind": "composition", "answer_data": [ "context-qualified preference entries", "reconciliation rule when a request matches several contexts", "fallback when no context matches" ] }, { "id": "cp-pref-q-language-unavailable", "text": "What is the correct behaviour when no preferred language can be produced on the selected channel?", "kind": "exception", "answer_data": [ "declared fallback tag list", "rule on whether to fall back or to defer contact", "reason code recorded on the advisory result" ] }, { "id": "cp-pref-q-locale-convention-boundary", "text": "Which locale formatting conventions travel with a language preference, and which stay with the rendering system?", "kind": "interoperability", "answer_data": [ "conventions carried here, such as tag and script", "conventions explicitly excluded, such as number and date formatting rules", "mapping note for legacy ISO 639-2 sources" ] } ], "data_elements": [ { "id": "cp-pref-de-language-tag", "name": "Preferred language tag", "description": "BCP 47 language tag the party prefers, in canonical form.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-020", "SRC-011" ] }, { "id": "cp-pref-de-language-modality", "name": "Language modality", "description": "Whether the tag applies to written, spoken or signed interaction.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-pref-de-language-rank", "name": "Language preference order", "description": "Relative order among the party's language preferences within one context and modality.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-018" ] }, { "id": "cp-pref-de-language-context", "name": "Language context qualifier", "description": "Usage context in which this language preference applies.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-pref-de-language-fallback-tag", "name": "Fallback language tag", "description": "Ordered fallback tags acceptable to the party when no preferred tag can be produced.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020" ] } ], "artifacts": [], "inline_only_rationale": "Language preference is a short ordered list of registry-governed codes with context qualifiers. It is resolved by comparison against channel capability at send time and produces no document, so an artifact would add identity and custody overhead with no corresponding content." }, { "id": "cp-pref-finding-accommodation-need", "name": "Accessibility accommodation directive for contact", "description": "Functional directives describing how communication must be conducted or rendered for this party, expressed as required channel capabilities and adaptation directives rather than as any diagnostic or medical statement, together with the required behaviour when no available channel can satisfy a directive.", "source_refs": [ "SRC-011", "SRC-022", "SRC-025", "SRC-026" ], "questions": [ { "id": "cp-pref-q-accommodation-directive-set", "text": "Which functional accommodation directives apply to communication with this party, inbound and outbound?", "kind": "requirement", "answer_data": [ "adaptation directive such as text alternative to audio or signed alternative to speech", "direction of applicability, inbound, outbound or both", "scope of the directive across purpose classes" ] }, { "id": "cp-pref-q-accommodation-non-diagnostic", "text": "How is the directive expressed so that it states a functional need without disclosing or implying a diagnosis?", "kind": "privacy", "answer_data": [ "functional expression pattern", "prohibited diagnostic vocabulary list", "minimum disclosure form shared with a channel provider" ] }, { "id": "cp-pref-q-channel-capability-match", "text": "Which channel capabilities must a candidate option possess before the directive counts as satisfiable?", "kind": "validation", "answer_data": [ "required capability code such as textphone or relay support", "capability source in the channel descriptor", "satisfiability test outcome" ] }, { "id": "cp-pref-q-accommodation-unsatisfiable", "text": "What must happen when no available channel can satisfy the accommodation directive?", "kind": "exception", "answer_data": [ "prescribed action such as flag and defer rather than silently degrade", "reason code on the advisory result", "escalation target for unmet accommodation" ] }, { "id": "cp-pref-q-accommodation-authority-source", "text": "Which record is the authoritative source of this directive when an external accessibility profile also exists?", "kind": "provenance", "answer_data": [ "reference to the external accessibility profile", "precedence rule between local directive and external profile", "last-synchronised marker" ] } ], "data_elements": [ { "id": "cp-pref-de-accommodation-directive", "name": "Accommodation directive", "description": "Functional directive describing a required adaptation of the communication.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "cp-pref-de-required-channel-capability", "name": "Required channel capability", "description": "Capability a candidate channel must expose for the directive to be satisfiable.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-022", "SRC-025" ] }, { "id": "cp-pref-de-accommodation-source-ref", "name": "Accommodation source reference", "description": "Reference to an external accessibility profile that is the authoritative source of the directive.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "cp-pref-de-unsatisfiable-directive-action", "name": "Unsatisfiable directive action", "description": "Declared behaviour when no candidate channel can satisfy the directive.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Accommodation directives are held as functional codes plus a reference to any authoritative external profile. Supporting documentation, assessments or accommodation letters are evidence objects owned by the accessibility or health model, so materialising an artifact here would pull evidence custody across a boundary this model does not own." } ] } ] }, { "id": "cp-pref-bundle-availability-routing", "name": "Availability and Routing", "description": "When the party asks to be contacted and in what order candidate options should be tried, including the time frame in which windows are read, urgency-driven deviation, and designation of a delegate or alternate recipient.", "rationale": "Availability and ordering form a coherent concern because they are all evaluated against an instant and a request, rather than being static assertions about the party. RFC 7953 treats stated availability as a priority-resolved pattern, FHIR carries rank as an ordering hint, and vCard registers agent and emergency relations - the same evaluation-time surface, grouped separately from static declaration and from precedence governance.", "source_refs": [ "SRC-018", "SRC-019", "SRC-021", "SRC-023", "SRC-024", "SRC-027" ], "layers": [ { "id": "cp-pref-layer-temporal-availability", "name": "Temporal Frame and Contact Windows", "description": "The time-zone frame in which stated windows are interpreted, and the recurring or one-off intervals during which the party asks to be contacted or left alone.", "source_refs": [ "SRC-018", "SRC-019", "SRC-021", "SRC-024" ], "findings": [ { "id": "cp-pref-finding-time-reference", "name": "Time-zone reference and temporal frame", "description": "The time zone in which the party's stated windows must be interpreted, preferring an IANA Time Zone Database identifier over a fixed UTC offset, together with the database release used and the distinction between a party's habitual zone and a per-statement override zone.", "source_refs": [ "SRC-018", "SRC-021", "SRC-024" ], "questions": [ { "id": "cp-pref-q-governing-time-zone", "text": "Which time-zone identifier governs interpretation of this party's stated windows?", "kind": "temporal", "answer_data": [ "IANA Area/Location time-zone identifier", "scope of the identifier, party-wide or statement-level", "source from which the identifier was obtained" ] }, { "id": "cp-pref-q-offset-insufficiency", "text": "Why is a fixed UTC offset insufficient for a stated window, and in which narrow case may one still be recorded?", "kind": "constraint", "answer_data": [ "daylight-saving and rebasing failure modes", "permitted offset-only case and its expiry", "required accompanying identifier when both are present" ] }, { "id": "cp-pref-q-tz-release-drift", "text": "How are time-zone database releases and renamed or linked zone identifiers handled as the registry changes?", "kind": "lifecycle", "answer_data": [ "pinned database release identifier", "re-evaluation trigger on release change", "identifier migration and alias resolution rule" ] }, { "id": "cp-pref-q-habitual-versus-override-zone", "text": "How is the party's habitual zone distinguished from a temporary zone assumed during travel?", "kind": "spatial", "answer_data": [ "habitual zone identifier", "override zone identifier with its effective interval", "precedence between the two at an instant" ] } ], "data_elements": [ { "id": "cp-pref-de-time-zone-id", "name": "Time-zone identifier", "description": "IANA Time Zone Database Area/Location identifier governing interpretation of stated windows.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-018" ] }, { "id": "cp-pref-de-utc-offset", "name": "Fixed UTC offset", "description": "Fixed offset recorded only where no zone identifier is obtainable, flagged as degraded.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "cp-pref-de-tz-database-release", "name": "Time-zone database release", "description": "Release of the time-zone database used to interpret the stated windows.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "cp-pref-de-time-zone-scope", "name": "Time-zone scope", "description": "Whether the identifier applies to the whole party profile or only to one statement.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "The temporal frame is one registry-governed identifier plus a release marker and a scope flag. The zone rules themselves live in the IANA registry, which this model references rather than reproduces, so there is nothing here to carry as a separate artifact." }, { "id": "cp-pref-finding-contact-window", "name": "Stated contact windows and declared unavailability", "description": "The recurring or one-off intervals during which the party asks to be contacted, the disposition of time no window covers, and the representation of one-off exceptions. A stated window is a preference, not an assertion about the party's real calendar availability.", "source_refs": [ "SRC-019", "SRC-021", "SRC-013" ], "questions": [ { "id": "cp-pref-q-window-pattern", "text": "Which recurring pattern expresses the party's stated contactable periods, and in which time-zone frame is it read?", "kind": "temporal", "answer_data": [ "pattern start and duration", "recurrence rule expression", "time-zone identifier applied to the pattern" ] }, { "id": "cp-pref-q-uncovered-time-disposition", "text": "Is time not covered by any declared window contactable or not contactable by default?", "kind": "decision", "answer_data": [ "declared default disposition for uncovered time", "rationale reference to the availability standard used", "whether the default may be overridden per purpose class" ] }, { "id": "cp-pref-q-window-one-off-exception", "text": "How is a single-occurrence exception expressed without rewriting the underlying pattern?", "kind": "exception", "answer_data": [ "occurrence identifier", "override patch on that occurrence", "exclusion entry where the occurrence is removed entirely" ] }, { "id": "cp-pref-q-window-versus-real-calendar", "text": "Does a stated window assert anything about the party's actual calendar availability at that time?", "kind": "definition", "answer_data": [ "explicit non-assertion statement", "reference to the calendar system of record", "rule that a stated window is never treated as booked or free time" ] }, { "id": "cp-pref-q-window-granularity", "text": "What granularity and minimum duration make a stated window meaningful for routing?", "kind": "measurement", "answer_data": [ "minimum duration threshold", "time granularity such as minute or quarter hour", "rounding rule at window boundaries" ] } ], "data_elements": [ { "id": "cp-pref-de-window-start", "name": "Window start", "description": "Start instant or local start time of a stated contact window.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-021" ] }, { "id": "cp-pref-de-window-duration", "name": "Window duration", "description": "Length of the stated window, preferred over an explicit end for recurring patterns.", "value_kind": "duration", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-021" ] }, { "id": "cp-pref-de-window-recurrence-rule", "name": "Window recurrence rule", "description": "Recurrence expression generating repeated occurrences of the window.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-019" ] }, { "id": "cp-pref-de-window-disposition", "name": "Uncovered-time disposition", "description": "Declared disposition applied to time that no window covers.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "cp-pref-de-window-exception", "name": "Occurrence exception set", "description": "Set of occurrence identifiers that are excluded or patched relative to the base pattern.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [ { "id": "cp-pref-artifact-availability-pattern", "name": "Stated availability pattern", "description": "The party's stated contactable and non-contactable periods expressed as a self-contained, exchangeable recurring pattern with its exceptions, its time-zone frame and its uncovered-time default.", "media_or_form": [ "iCalendar VAVAILABILITY component with AVAILABLE subcomponents", "JSCalendar availability object with recurrence overrides", "structured recurring-window table in the adopting projection" ], "serial": false, "identity_strategy": "Authoritative master-system identifier issued by the availability system of record where one exists; otherwise a governed URI or UID for the pattern; otherwise a UUID or ULID minted by the adopting Dimension. The publication or effective date is never the identifier.", "source_refs": [ "SRC-019", "SRC-021" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-pref-layer-routing-order", "name": "Ordering, Urgency and Delegation", "description": "How candidate options are sequenced, when an urgency tier may deviate from stated windows, and who else may be contacted on the party's behalf.", "source_refs": [ "SRC-018", "SRC-023", "SRC-025", "SRC-027" ], "findings": [ { "id": "cp-pref-finding-attempt-order", "name": "Attempt order and fallback sequence", "description": "The deterministic ordering of candidate contact options derived from preference values and scope match, the tie-break rule when values are equal or absent, and the party-stated conditions for moving on to the next option. Delivery outcomes and retry execution belong to the sending system.", "source_refs": [ "SRC-018", "SRC-019", "SRC-023" ], "questions": [ { "id": "cp-pref-q-total-order-derivation", "text": "How is a total order derived when several candidate options carry equal or absent preference values?", "kind": "decision", "answer_data": [ "ordered tie-break criteria", "stable sort key such as statement identifier", "documented determinism guarantee" ] }, { "id": "cp-pref-q-fallback-trigger", "text": "Which condition moves routing to the next option in the sequence, and which component evaluates that condition?", "kind": "process", "answer_data": [ "fallback trigger condition stated by the party", "evaluating component named as the sending system", "boundary statement that this model does not observe the trigger" ] }, { "id": "cp-pref-q-attempt-limits", "text": "Has the party stated a maximum number of attempts or a minimum interval between them?", "kind": "constraint", "answer_data": [ "maximum attempt count", "minimum spacing duration", "scope of the limit across purpose classes" ] }, { "id": "cp-pref-q-order-versus-urgency", "text": "How does the fallback sequence change with purpose class and urgency tier?", "kind": "relationship", "answer_data": [ "per-purpose sequence variants", "urgency tier overlay on the sequence", "precedence when a variant and an overlay disagree" ] } ], "data_elements": [ { "id": "cp-pref-de-attempt-sequence", "name": "Attempt sequence", "description": "Ordered list of candidate option references produced from preference values and scope match.", "value_kind": "collection", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-018" ] }, { "id": "cp-pref-de-tie-break-rule", "name": "Tie-break rule", "description": "Declared rule producing a stable order when preference values tie or are absent.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "cp-pref-de-fallback-trigger", "name": "Fallback trigger", "description": "Party-stated condition under which the next option should be tried.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-attempt-spacing", "name": "Minimum attempt spacing", "description": "Minimum interval the party asks to be left between contact attempts.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "The sequence is a derived ordering over references that the resolver recomputes from current statements; persisting it as an artifact would freeze a decision that must always be recomputed against live restriction status, and would blur into the sending system's own attempt log." }, { "id": "cp-pref-finding-urgency-escalation", "name": "Urgency tiering and escalation preference", "description": "Which urgency tiers the profile recognises, which of the party's own stated windows or avoidance statements a tier may override, who may assert a tier, and whether any life-safety routing has been declared. No urgency tier may ever override an external communication restriction.", "source_refs": [ "SRC-018", "SRC-019", "SRC-025", "SRC-027" ], "questions": [ { "id": "cp-pref-q-urgency-tier-vocabulary", "text": "Which urgency tiers are recognised for this profile, and against which vocabulary are they defined?", "kind": "classification", "answer_data": [ "urgency tier code", "referenced urgency vocabulary and version", "local mapping table where the vocabulary is adapted" ] }, { "id": "cp-pref-q-urgency-override-limits", "text": "Which of the party's own statements may an urgency tier override, and which may it never override?", "kind": "authority", "answer_data": [ "overridable statement classes", "non-overridable statement classes", "explicit rule that external restrictions are never overridable" ] }, { "id": "cp-pref-q-urgency-assertion-rights", "text": "Which requesting roles are permitted to assert the highest urgency tier on an outbound request?", "kind": "access", "answer_data": [ "permitted asserting roles", "assertion justification requirement", "handling of an unauthorised tier assertion" ] }, { "id": "cp-pref-q-life-safety-declaration", "text": "Has life-safety routing been declared for this party, and how is its absence interpreted?", "kind": "state", "answer_data": [ "life-safety routing declared flag", "declared routing target reference", "rule that absence means no declared preference, not a permissive default" ] }, { "id": "cp-pref-q-urgency-versus-restriction", "text": "What is the outcome when a high urgency tier meets an active external communication restriction?", "kind": "constraint", "answer_data": [ "blocked outcome with reason code", "precedence statement placing the external restriction above every urgency tier", "escalation path that does not involve contacting the party" ] } ], "data_elements": [ { "id": "cp-pref-de-urgency-tier", "name": "Urgency tier", "description": "Recognised urgency tier code applicable to requests against this profile.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-027" ] }, { "id": "cp-pref-de-urgency-vocabulary-ref", "name": "Urgency vocabulary reference", "description": "Reference to the vocabulary and version defining the urgency tiers in use.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027" ] }, { "id": "cp-pref-de-urgency-override-allowance", "name": "Urgency override allowance", "description": "Which classes of the party's own statements a given tier may override.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "cp-pref-de-emergency-routing-declared", "name": "Life-safety routing declared", "description": "Explicit flag recording whether life-safety routing has been declared for this party.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-018", "SRC-025" ] } ], "artifacts": [], "inline_only_rationale": "Urgency tiering is a small mapping between codes and override allowances that is evaluated at resolution time. The alert or incident that carries an urgency value is owned by the originating operational system, so no artifact is created here." }, { "id": "cp-pref-finding-delegate-alternate", "name": "Delegation and alternate-contact designation", "description": "Another party designated to receive or handle communication for this party, qualified by a registered relation type, scoped by purpose class and urgency, marked as substitutive or additive, and bounded by an effective interval. The delegate's identity and the authority evidence live outside this model.", "source_refs": [ "SRC-018", "SRC-023", "SRC-025" ], "questions": [ { "id": "cp-pref-q-delegate-identity-reference", "text": "Which party is designated as delegate or alternate, and by which reference into the party model?", "kind": "identity", "answer_data": [ "delegate party reference", "identifier scheme used for the reference", "prohibition on copying the delegate's name or endpoint here" ] }, { "id": "cp-pref-q-delegate-relation-type", "text": "Which registered relation type qualifies the designation, and from which registry is it drawn?", "kind": "interoperability", "answer_data": [ "relation type value such as agent or emergency", "registry and registration procedure", "local extension handling under a vendor namespace" ] }, { "id": "cp-pref-q-delegate-scope-mode", "text": "For which purpose classes and urgency tiers is the designation valid, and does it replace or supplement contacting the party?", "kind": "composition", "answer_data": [ "scoped purpose classes and urgency tiers", "mode value: substitutive, additive or copy", "behaviour when the scope does not match a request" ] }, { "id": "cp-pref-q-delegate-authority-evidence", "text": "What authority supports the designation, and where is that evidence held?", "kind": "evidence", "answer_data": [ "authority reference such as a mandate or authorisation record", "holding system for the evidence", "assurance level of the designation" ] }, { "id": "cp-pref-q-delegate-lapse", "text": "When does the designation lapse, and what happens to routing already in flight at that moment?", "kind": "lifecycle", "answer_data": [ "effective interval of the designation", "lapse trigger such as revocation or expiry", "in-flight routing rule at the moment of lapse" ] } ], "data_elements": [ { "id": "cp-pref-de-delegate-party-ref", "name": "Delegate party reference", "description": "Reference to the designated party in the party model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-018" ] }, { "id": "cp-pref-de-delegate-relation-type", "name": "Delegate relation type", "description": "Registered relation type qualifying the designation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018", "SRC-025" ] }, { "id": "cp-pref-de-delegate-scope", "name": "Delegation scope", "description": "Purpose classes, contexts and urgency tiers for which the designation is valid.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "cp-pref-de-delegate-mode", "name": "Delegation mode", "description": "Whether the delegate replaces, supplements or is copied alongside the party.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-delegate-authority-ref", "name": "Delegation authority reference", "description": "Reference to the external record evidencing authority for the designation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] } ], "artifacts": [], "inline_only_rationale": "The designation is a scoped, typed reference between two parties. The mandate, power of attorney or authorisation record that justifies it is an evidence object owned by another model, and the delegate's own contact profile is a separate instance of this mixin, so no artifact belongs here." } ] } ] }, { "id": "cp-pref-bundle-validity-governance", "name": "Validity, Precedence and Statement Provenance", "description": "How long each statement holds, how temporary overrides supersede standing statements, how overlapping statements combine into one deterministic advisory outcome, and who asserted each statement under what authority.", "rationale": "Validity and precedence are a distinct concern from what a party declares and from when it is available: they govern how many independent statements plus one external input are folded into a single defensible outcome, and how that outcome can be explained later. RFC 7953 supplies a tested precedence pattern for overlapping availability, FHIR supplies validity periods, and JSCalendar supplies non-destructive override semantics.", "source_refs": [ "SRC-018", "SRC-019", "SRC-021", "SRC-023" ], "layers": [ { "id": "cp-pref-layer-validity-precedence", "name": "Effective Intervals, Overrides and Precedence", "description": "The temporal validity of statements, non-destructive temporary overrides, and the deterministic precedence rules that combine local statements with the external restriction resolution status.", "source_refs": [ "SRC-019", "SRC-021", "SRC-023" ], "findings": [ { "id": "cp-pref-finding-effective-interval-override", "name": "Effective intervals and temporary overrides", "description": "The validity interval bounding every preference statement, and the temporary override mechanism by which a short-lived statement supersedes a standing one for a bounded period without deleting or rewriting it.", "source_refs": [ "SRC-019", "SRC-021", "SRC-023" ], "questions": [ { "id": "cp-pref-q-effective-interval-bounds", "text": "What effective interval bounds this statement, and what does an open-ended end mean?", "kind": "temporal", "answer_data": [ "effective start instant", "effective end instant or open marker", "interpretation rule for an open end" ] }, { "id": "cp-pref-q-override-supersession", "text": "How does a temporary override supersede a standing statement without deleting it?", "kind": "state", "answer_data": [ "supersedes reference from override to standing statement", "override priority value", "reinstatement behaviour at override expiry" ] }, { "id": "cp-pref-q-override-duration-limit", "text": "Is there a maximum permitted duration for a temporary override, and what happens at expiry?", "kind": "lifecycle", "answer_data": [ "maximum override duration policy", "expiry action such as automatic reinstatement", "reconfirmation prompt where the override is repeatedly extended" ] }, { "id": "cp-pref-q-overlapping-overrides", "text": "Which statement applies at an instant when several overrides are effective at once?", "kind": "decision", "answer_data": [ "priority ordering among overrides", "equal-priority resolution rule favouring the more restrictive outcome", "the identifier of the statement that governed the instant" ] }, { "id": "cp-pref-q-superseded-retention", "text": "How long is a superseded statement retained so that a past outcome remains explainable?", "kind": "retention", "answer_data": [ "retention marker on the superseded version", "adopting Dimension retention policy reference", "minimum content kept after disposition" ] } ], "data_elements": [ { "id": "cp-pref-de-effective-start", "name": "Effective start", "description": "Instant from which the statement applies.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-effective-end", "name": "Effective end", "description": "Instant after which the statement no longer applies; absence means open-ended.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-override-flag", "name": "Temporary override flag", "description": "Marks the statement as a bounded override of one or more standing statements.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-023" ] }, { "id": "cp-pref-de-override-priority", "name": "Override priority", "description": "Priority value resolving overlap between simultaneously effective statements.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "cp-pref-de-supersedes-ref", "name": "Supersedes reference", "description": "Reference from an override or new version to the statement version it supersedes.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Validity intervals and supersession links are relational attributes on statement versions. They are meaningful only in place, as part of the statement graph the resolver walks, and extracting them into an artifact would create a parallel version history competing with the statement records themselves." }, { "id": "cp-pref-finding-precedence-conflict-rule", "name": "Precedence and conflict-resolution rules", "description": "The deterministic rules that fold matching statements, the local contact-avoidance preference and the external restriction resolution status into one advisory disposition per candidate option, including the fail-closed rule that an unresolvable external restriction reference yields an unresolved outcome rather than any permissive default.", "source_refs": [ "SRC-018", "SRC-019", "SRC-023" ], "questions": [ { "id": "cp-pref-q-precedence-order", "text": "In which order are overlapping statements and external inputs combined into a single effective disposition?", "kind": "process", "answer_data": [ "ordered precedence chain", "per-step input and output disposition", "the ruleset edition that defines the chain" ] }, { "id": "cp-pref-q-narrow-versus-block", "text": "Which input may only narrow the result, and which input blocks an option outright?", "kind": "constraint", "answer_data": [ "narrow-only inputs, including the local avoidance preference", "blocking input, being the active external restriction", "proof that no local input can re-permit a blocked option" ] }, { "id": "cp-pref-q-unresolvable-restriction", "text": "What must be returned when the external communication-restriction reference cannot be resolved at evaluation time?", "kind": "exception", "answer_data": [ "unresolved outcome value", "reason code and retry guidance", "explicit prohibition of a permissive default" ] }, { "id": "cp-pref-q-irreducible-contradiction", "text": "How is a genuine contradiction between two statements of equal precedence surfaced rather than silently resolved?", "kind": "validation", "answer_data": [ "conflict detection result with the conflicting statement identifiers", "most-restrictive interim disposition", "routing of the conflict to the responsible steward" ] }, { "id": "cp-pref-q-ruleset-edition-citation", "text": "Which edition of the precedence ruleset produced a given resolution, and how is that recorded on the result?", "kind": "provenance", "answer_data": [ "ruleset edition identifier", "time-zone database release used", "statement version identifiers cited by the result" ] } ], "data_elements": [ { "id": "cp-pref-de-precedence-order", "name": "Precedence chain", "description": "Ordered list of precedence steps applied when combining inputs into one disposition.", "value_kind": "collection", "cardinality": "1", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "cp-pref-de-restriction-reference", "name": "External restriction reference", "description": "Resolvable reference to the external communication-restriction registry entry applicable to this party, supplied by the governance area; carries binding and subject parameters only, never a copy of the restriction record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-011" ] }, { "id": "cp-pref-de-restriction-resolution-status", "name": "Restriction resolution status", "description": "Outcome of resolving the external reference: an active restriction found, no restriction found, or not resolvable.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-plan-option-disposition", "name": "Option disposition", "description": "Advisory disposition for one candidate option, with a reason code.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-019", "SRC-023" ] }, { "id": "cp-pref-de-ruleset-edition", "name": "Precedence ruleset edition", "description": "Identifier of the precedence ruleset edition that produced a resolution.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "cp-pref-artifact-precedence-ruleset", "name": "Advisory precedence ruleset", "description": "The published, versioned decision table that defines how matching statements, the local avoidance preference and the external restriction resolution status combine into one advisory disposition, including the fail-closed unresolved outcome. It is a declarative rule statement; running it, and enforcing any result, belong to the consuming system and to the external restriction registry respectively.", "media_or_form": [ "versioned decision table", "machine-readable rule set in the adopting projection", "human-readable precedence specification" ], "serial": true, "identity_strategy": "Stable series identifier issued by the adopting Dimension plus a monotonically increasing edition number; every resolution result cites the exact edition, and superseded editions stay resolvable so a past outcome can be reconstructed.", "source_refs": [ "SRC-019", "SRC-023" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-pref-layer-statement-provenance", "name": "Statement Provenance and Assurance", "description": "Who asserted each preference, under what authority, through which capture channel, and how statement time is separated from recording time.", "source_refs": [ "SRC-011", "SRC-018", "SRC-023" ], "findings": [ { "id": "cp-pref-finding-statement-provenance", "name": "Provenance, authority and assurance of a preference statement", "description": "The origin of each statement: the asserting party or authorised steward, the authority relied on, the capture channel and its assurance level, and the separate recording of the instant the party stated the preference and the instant the system recorded it.", "source_refs": [ "SRC-011", "SRC-018", "SRC-021", "SRC-023" ], "questions": [ { "id": "cp-pref-q-asserter-and-authority", "text": "Who asserted this preference, the party or an authorised steward, and under what authority did they act?", "kind": "ownership", "answer_data": [ "asserter party reference", "asserter role", "authority basis reference held by the adopting Dimension" ] }, { "id": "cp-pref-q-capture-channel-assurance", "text": "Through which capture channel was the statement made, and what assurance level does that channel carry?", "kind": "evidence", "answer_data": [ "capture channel code", "assurance level code", "identity verification result at capture, where one exists" ] }, { "id": "cp-pref-q-statement-versus-record-time", "text": "How are the instant of statement and the instant of recording represented when they differ?", "kind": "temporal", "answer_data": [ "statement time with explicit offset", "recording time with explicit offset", "rule requiring both when they differ" ] }, { "id": "cp-pref-q-operator-alteration-limits", "text": "Which statements may an operator alter on the party's behalf, and what must be recorded when they do?", "kind": "authority", "answer_data": [ "alterable statement classes", "mandatory operator attribution fields", "statements that only the party may change" ] }, { "id": "cp-pref-q-low-assurance-handling", "text": "How does the advisory resolver treat a statement whose provenance or assurance is weak?", "kind": "quality", "answer_data": [ "assurance threshold for use in resolution", "conservative treatment rule favouring restriction", "flag surfaced on the explanation output" ] } ], "data_elements": [ { "id": "cp-pref-de-asserter-party-ref", "name": "Asserter reference", "description": "Reference to the party or steward that asserted the statement.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-023" ] }, { "id": "cp-pref-de-asserter-role", "name": "Asserter role", "description": "Role in which the asserter acted, such as the party itself or an authorised identity steward.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "cp-pref-de-statement-time", "name": "Statement time", "description": "Instant at which the party stated the preference.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-021" ] }, { "id": "cp-pref-de-record-time", "name": "Record time", "description": "Instant at which the statement was captured or ingested by the recording system.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-023" ] }, { "id": "cp-pref-de-assurance-level", "name": "Assurance level", "description": "Assurance attached to the capture channel and any identity verification at capture.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] } ], "artifacts": [], "inline_only_rationale": "Provenance here is a set of attributes carried on each statement version. The captured form itself, whether a signed web form submission, a call recording or a letter, is an evidence object whose custody, retention and audit trail belong to the capture and logging systems, so this model references it rather than materialising it." } ] } ] }, { "id": "cp-gov-bundle-authority-provenance", "name": "Authority, Stewardship and Provenance of Contact Assertions", "description": "Everything that establishes who was entitled to put a contact point on a party profile, who is accountable for it afterwards, where the value came from, whether control of the endpoint was demonstrated, and which externally owned permission allows it to be used.", "rationale": "Accountability under GDPR Article 5(2) requires that a controller can demonstrate how each personal datum came to be held and on what basis it is processed. PROV-O supplies the agent/activity/entity vocabulary for that demonstration, and NIST SP 800-63A supplies the vocabulary for demonstrating control of a communication channel. Separating these from permission prevents the common conflation of 'we verified this number' with 'we may call this number'.", "source_refs": [ "SRC-028", "SRC-029", "SRC-017", "SRC-037" ], "layers": [ { "id": "cp-gov-layer-assertion-authority", "name": "Assertion Authority and Stewardship", "description": "The mandate under which an agent may assert or change a contact point, and the ongoing ownership, stewardship and controller roles attached to the resulting record.", "source_refs": [ "SRC-028", "SRC-030", "SRC-017", "SRC-036" ], "findings": [ { "id": "cp-gov-finding-assertion-authority", "name": "Authority to assert or change a contact point", "description": "Which agent is entitled to create, alter, suspend or retire a contact point on a party profile, on what recorded mandate, how that mandate is bounded and when it lapses. This is strictly the entitlement to write the record; it is not the entitlement to use the resulting endpoint.", "source_refs": [ "SRC-028", "SRC-029", "SRC-030", "SRC-017" ], "questions": [ { "id": "cp-gov-q-authority-basis", "text": "On what recorded mandate may an agent other than the data subject assert or change this contact point?", "kind": "authority", "answer_data": [ "Mandate type code (self, guardianship, power of attorney, employment, statutory steward, system derivation)", "Mandate reference identifier", "Issuing authority reference", "Scope of permitted operations", "Mandate validity interval" ] }, { "id": "cp-gov-q-authority-self-service", "text": "How is a self-asserted change by the data subject distinguished from a steward-asserted or system-derived change?", "kind": "provenance", "answer_data": [ "Assertion actor role code", "Actor party reference", "Assertion channel code", "Authentication assurance reference" ] }, { "id": "cp-gov-q-authority-scope-limit", "text": "Which contact-point operations does the mandate permit and which does it explicitly exclude?", "kind": "constraint", "answer_data": [ "Permitted operation set", "Explicitly excluded operation set", "Per-channel restrictions", "Escalation-required flag" ] }, { "id": "cp-gov-q-authority-expiry", "text": "When does the asserting mandate lapse, and what happens to in-force assertions made under it once it does?", "kind": "lifecycle", "answer_data": [ "Mandate expiry timestamp", "Revocation event reference", "Disposition rule for dependent assertions", "Re-attestation requirement" ] }, { "id": "cp-gov-q-authority-decision-owner", "text": "Which external authorisation model renders the allow or deny decision, and what decision reference is retained here?", "kind": "decision", "answer_data": [ "Authorisation model reference", "Policy decision identifier", "Decision timestamp", "Attached obligation references" ] } ], "data_elements": [ { "id": "cp-gov-de-authority-basis-code", "name": "Authority basis code", "description": "Coded reason the asserting agent was entitled to write this contact point.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-028", "SRC-017" ] }, { "id": "cp-gov-de-mandate-reference", "name": "Mandate reference", "description": "Resolvable reference to the instrument evidencing delegated authority, where the asserter is not the data subject.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028", "SRC-030" ] }, { "id": "cp-gov-de-asserting-agent-ref", "name": "Asserting agent reference", "description": "Reference to the responsible agent to whom the assertion is attributed, aligned to prov:Agent.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-029" ] }, { "id": "cp-gov-de-permitted-operations", "name": "Permitted operation set", "description": "The contact-point operations the mandate authorises, used as a write-time precondition.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-authorization-decision-ref", "name": "Authorisation decision reference", "description": "Reference to the decision rendered by the external authorisation model for a specific attempted operation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] } ], "artifacts": [ { "id": "cp-gov-artifact-authority-mandate", "name": "Written authority mandate", "description": "The instrument evidencing that an agent other than the data subject may assert or change contact points, held or referenced so a steward can verify scope and currency.", "media_or_form": [ "Signed mandate or authorisation letter", "Court order or guardianship instrument", "Power of attorney document", "Organisational steward designation record" ], "serial": false, "identity_strategy": "Use the identifier issued by the authoritative issuing system or registry (court file number, HR mandate record identifier). Where none exists, mint a governed IRI under the adopting Dimension's namespace. As a last resort assign a UUIDv7. The mandate's issue or expiry date is an attribute and is never used as its identifier.", "source_refs": [ "SRC-028", "SRC-030", "SRC-034" ] } ], "inline_only_rationale": null }, { "id": "cp-gov-finding-stewardship-ownership", "name": "Ownership, stewardship and custodial roles", "description": "Which system is authoritative for a contact point, which hold non-authoritative copies, who is accountable for its quality, and which party acts as controller or processor for each purpose, including how those roles transfer without losing the prior chain of responsibility.", "source_refs": [ "SRC-028", "SRC-030", "SRC-036" ], "questions": [ { "id": "cp-gov-q-owner-of-record", "text": "Which system of record is authoritative for this contact point, and which systems hold non-authoritative copies?", "kind": "ownership", "answer_data": [ "Authoritative system identifier", "Copy-holder system identifiers", "Authority ranking value", "Synchronisation direction" ] }, { "id": "cp-gov-q-steward-assignment", "text": "Which named steward role is accountable for the accuracy and currency of this contact point?", "kind": "ownership", "answer_data": [ "Steward role code", "Steward party reference", "Accountable organisational unit", "Stewardship effective interval" ] }, { "id": "cp-gov-q-controller-role", "text": "Which party acts as controller and which as processor for this contact point, and does that differ by purpose?", "kind": "relationship", "answer_data": [ "Controller reference", "Processor references", "Per-purpose role overrides", "Joint-controller arrangement reference" ] }, { "id": "cp-gov-q-ownership-transfer", "text": "How is a change of owning system or steward recorded without losing the prior chain of responsibility?", "kind": "provenance", "answer_data": [ "Transfer event reference", "Prior owner reference", "New owner reference", "Transfer effective timestamp", "Superseded-authority note" ] } ], "data_elements": [ { "id": "cp-gov-de-record-owner-system", "name": "Authoritative system of record", "description": "Identifier of the system whose value prevails for this contact point when copies disagree.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-030", "SRC-036" ] }, { "id": "cp-gov-de-steward-party-ref", "name": "Accountable steward reference", "description": "Reference to the party or role accountable for the quality and currency of the contact point.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] }, { "id": "cp-gov-de-controller-role-code", "name": "Processing role code", "description": "Coded controller, joint-controller or processor role held for this contact point, optionally qualified per purpose.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-authority-rank", "name": "Source authority rank", "description": "Numeric precedence used to break ties between conflicting sources during reconciliation.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] } ], "artifacts": [], "inline_only_rationale": "Ownership and stewardship are expressed entirely as governed references to party, organisational-unit and system registries, plus role codes and effective intervals. No document is produced or held by this model: controller and processor arrangements are documented in the referenced records-of-processing model under GDPR Article 30, and duplicating them here would copy that model's lifecycle and evidence." }, { "id": "cp-gov-finding-assertion-provenance", "name": "Provenance of each contact-point assertion", "description": "The agent, activity and upstream source behind every asserted or derived contact value, with event time, observation time and ingestion time kept apart, so that a later reader can judge trustworthiness and reproduce the derivation.", "source_refs": [ "SRC-029", "SRC-035", "SRC-028", "SRC-011" ], "questions": [ { "id": "cp-gov-q-provenance-origin", "text": "Which activity generated this contact-point value, and from what upstream entity was it derived?", "kind": "provenance", "answer_data": [ "Generating activity reference", "Source entity reference", "Derivation relation code (revision, derivation, primary source)", "Transformation note" ] }, { "id": "cp-gov-q-provenance-times", "text": "What are the separate event time, observation time and record-ingestion time for this assertion?", "kind": "temporal", "answer_data": [ "Event timestamp", "Observed-at timestamp", "Ingested-at timestamp", "Timestamp precision", "Originating clock or source note" ] }, { "id": "cp-gov-q-provenance-attribution", "text": "To which responsible agent is the assertion attributed, and with what qualification?", "kind": "evidence", "answer_data": [ "Attributed agent reference", "Agent role", "Qualified attribution note", "Delegation chain reference" ] }, { "id": "cp-gov-q-provenance-confidence", "text": "What reliability grade is attached to the originating source, and how was that grade derived?", "kind": "quality", "answer_data": [ "Source reliability grade", "Grading scheme identifier", "Grading method", "Grade assigned-at timestamp" ] } ], "data_elements": [ { "id": "cp-gov-de-generating-activity-ref", "name": "Generating activity reference", "description": "Reference to the activity that produced this contact-point version, aligned to prov:wasGeneratedBy.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-029" ] }, { "id": "cp-gov-de-event-time", "name": "Event time", "description": "When the asserted fact became true in the world, for example when the party began using the endpoint.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-035", "SRC-029" ] }, { "id": "cp-gov-de-observed-at-time", "name": "Observation time", "description": "When a source or verifier observed the fact, distinct from when it occurred.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-035" ] }, { "id": "cp-gov-de-ingested-at-time", "name": "Ingestion time", "description": "When this model wrote the assertion into the record, always present for every version.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-035", "SRC-030" ] }, { "id": "cp-gov-de-source-reliability-grade", "name": "Source reliability grade", "description": "Graded confidence in the originating source under a named grading scheme.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] } ], "artifacts": [], "inline_only_rationale": "Provenance here is structured metadata expressed as agent, activity and entity references with RFC 3339 timestamps aligned to PROV-O. It yields no separate deliverable object. Any signed provenance bundle or immutable event stream a Dimension chooses to emit is an artifact of the referenced provenance and audit models, which own its persistence and evidential weight." } ] }, { "id": "cp-gov-layer-control-and-permission", "name": "Endpoint Control Proof and Permission Linkage", "description": "Two deliberately separated concerns: non-secret evidence that a challenge to the endpoint was answered, and resolvable references to the externally owned consent, legal-basis and restriction records that decide whether the endpoint may lawfully be used for a purpose.", "source_refs": [ "SRC-017", "SRC-028", "SRC-037", "SRC-038", "SRC-039" ], "findings": [ { "id": "cp-gov-finding-control-verification", "name": "Proof that an endpoint is controlled", "description": "Evidence that a challenge sent to the endpoint was correctly answered, recorded as a non-secret verification state with method, assurance, freshness and decay. Verified control never implies permission to contact, and the exchange's secret material is never persisted here.", "source_refs": [ "SRC-017", "SRC-011", "SRC-028" ], "questions": [ { "id": "cp-gov-q-verification-method", "text": "By what method and at what assurance was control of this endpoint demonstrated?", "kind": "evidence", "answer_data": [ "Verification method code (out-of-band code, click-through confirmation, postal confirmation, carrier attestation)", "Assurance level", "Challenge channel", "Verifier system reference" ] }, { "id": "cp-gov-q-verification-freshness", "text": "When did the successful verification occur, and when does the verification state expire or require renewal?", "kind": "temporal", "answer_data": [ "Verified-at timestamp", "Verification validity period", "Next re-verification due timestamp", "Decay policy reference" ] }, { "id": "cp-gov-q-verification-secret-exclusion", "text": "What must never be persisted in this model from the verification exchange?", "kind": "security", "answer_data": [ "Prohibited element list (one-time codes, challenge secrets, session tokens, message bodies)", "Permitted non-secret outcome fields", "Hash or reference-only linkage rule", "Rejection behaviour for non-compliant payloads" ] }, { "id": "cp-gov-q-verification-failure", "text": "How are failed, abandoned or replayed verification attempts represented without leaking attempt detail?", "kind": "exception", "answer_data": [ "Verification outcome code", "Attempt-count band", "Lockout state", "Related incident reference" ] }, { "id": "cp-gov-q-verification-not-permission", "text": "How is verified control kept distinct from lawful permission to contact the endpoint?", "kind": "constraint", "answer_data": [ "Verification state value", "Permission binding reference", "Combined-use precondition rule", "Conflict handling note" ] } ], "data_elements": [ { "id": "cp-gov-de-verification-state", "name": "Verification state", "description": "Non-secret coded outcome of endpoint control proof (unverified, pending, verified, expired, failed).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "cp-gov-de-verification-assurance", "name": "Verification assurance level", "description": "Assurance associated with the verification method, referencing an external assurance scheme rather than restating it.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "cp-gov-de-verification-event-ref", "name": "External verification event reference", "description": "Reference to the verification event held by the identity verification model; the challenge payload itself is never copied.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "cp-gov-de-verified-at", "name": "Verified-at timestamp", "description": "Time at which the successful control proof completed, recorded separately from ingestion time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-035", "SRC-017" ] }, { "id": "cp-gov-de-reverification-due", "name": "Re-verification due", "description": "Point after which the verification state is treated as stale and must be renewed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-036" ] } ], "artifacts": [ { "id": "cp-gov-artifact-verification-attestation", "name": "Endpoint control verification attestation", "description": "A non-secret attestation that a control-proof challenge succeeded for a named endpoint at a named time, suitable for showing to the data subject or an auditor without revealing challenge material.", "media_or_form": [ "Signed attestation record", "Verification receipt issued to the data subject", "Printable confirmation notice" ], "serial": false, "identity_strategy": "Use the verification event identifier issued by the verifying system of record. Where none exists, mint a governed IRI under the adopting Dimension's namespace. As a last resort assign a UUIDv7 and treat it as opaque. The verified-at timestamp is an attribute of the attestation and is never its identifier.", "source_refs": [ "SRC-017", "SRC-034", "SRC-035" ] } ], "inline_only_rationale": null }, { "id": "cp-gov-finding-permission-linkage", "name": "Linkage to consent, legal basis and communication restrictions", "description": "How the profile points at externally owned consent records, legal-basis determinations and suppression or objection entries per purpose and channel, carrying only the reference, binding scope, validity window and subject-specific parameters.", "source_refs": [ "SRC-028", "SRC-037", "SRC-038", "SRC-039" ], "questions": [ { "id": "cp-gov-q-permission-reference", "text": "Which external consent or legal-basis record authorises use of this endpoint for a named purpose?", "kind": "relationship", "answer_data": [ "Purpose identifier", "Legal basis code", "Consent record reference", "Referenced record schema version", "Binding effective interval" ] }, { "id": "cp-gov-q-permission-granularity", "text": "At what granularity does a permission bind: party, endpoint, channel, purpose or campaign class?", "kind": "composition", "answer_data": [ "Binding scope code", "Bound endpoint reference", "Bound channel code", "Purpose taxonomy reference" ] }, { "id": "cp-gov-q-restriction-signal", "text": "Which restriction, objection or suppression entries currently block use of this endpoint, and who owns them?", "kind": "constraint", "answer_data": [ "Restriction record reference", "Restriction type code", "Owning model reference", "Restriction effective-from timestamp", "Jurisdiction code" ] }, { "id": "cp-gov-q-permission-staleness", "text": "How does this model detect that a referenced permission has been withdrawn, expired or superseded?", "kind": "event", "answer_data": [ "Permission change event reference", "Last-checked timestamp", "Cache validity period", "Re-check trigger conditions" ] }, { "id": "cp-gov-q-permission-boundary", "text": "What consent detail must never be copied into this model?", "kind": "privacy", "answer_data": [ "Excluded element list (notice text, evidence payloads, complete consent receipts, proof recordings)", "Permitted reference fields", "Digest-only linkage rule", "Rejection behaviour for over-broad payloads" ] } ], "data_elements": [ { "id": "cp-gov-de-purpose-id", "name": "Purpose identifier", "description": "Governed purpose under which use of the endpoint is contemplated, drawn from the Dimension's purpose taxonomy.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-028", "SRC-038" ] }, { "id": "cp-gov-de-legal-basis-code", "name": "Legal basis code", "description": "Coded lawful basis asserted by the referenced permission record; recorded here only as a resolved summary.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-consent-record-ref", "name": "Consent or legal-basis record reference", "description": "Resolvable identifier of the externally owned record, together with the schema version it was written under.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-037", "SRC-028" ] }, { "id": "cp-gov-de-restriction-ref", "name": "Communication restriction reference", "description": "Reference to an objection, do-not-contact or suppression entry owned by the restriction registry.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028", "SRC-039" ] }, { "id": "cp-gov-de-permission-checked-at", "name": "Permission last-checked timestamp", "description": "When the referenced permission or restriction was last re-resolved, bounding how stale the local view may be.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-038", "SRC-035" ] } ], "artifacts": [], "inline_only_rationale": "This finding is deliberately reference-only. Consent records, legal-basis determinations and suppression entries are created, versioned, evidenced and withdrawn in separate models, so the profile holds nothing but resolvable identifiers, binding scope, purpose codes, schema versions and validity windows. Materialising a consent artifact here would reproduce the target model's evidence and lifecycle, which the composition contract reserves to that model." } ] } ] }, { "id": "cp-gov-bundle-lifecycle-quality", "name": "Lifecycle, Temporal Versioning and Data Quality", "description": "How a contact point moves through its permitted states over both real-world and record time, and how its value is validated, normalised, reconciled against other sources, and degraded as staleness, reassignment or compromise signals arrive.", "rationale": "GDPR Article 5(1)(d) requires that inaccurate personal data be rectified or deleted, which is unachievable without an explicit state model, a separation of valid time from record time, and measurable quality signals. NARA's lifecycle requirement groups and PROV-O's generation and invalidation times supply the record-keeping frame; the UK Government Data Quality Framework supplies the dimension vocabulary for measuring fitness for purpose.", "source_refs": [ "SRC-028", "SRC-029", "SRC-030", "SRC-035", "SRC-036" ], "layers": [ { "id": "cp-gov-layer-lifecycle-time", "name": "Lifecycle States and Temporal Versioning", "description": "The closed state set and permitted transitions for a contact point, the separation of real-world validity from record history, and the version token that makes concurrent editing safe.", "source_refs": [ "SRC-030", "SRC-029", "SRC-035", "SRC-031" ], "findings": [ { "id": "cp-gov-finding-lifecycle-versioning", "name": "Lifecycle states, effective dating and record versioning", "description": "The permitted states of a contact point and their triggers, the real-world interval over which it is asserted valid, the preserved record-time history that distinguishes a correction from a change, the opaque version token used for concurrency, and the supersession links that keep predecessors resolvable.", "source_refs": [ "SRC-030", "SRC-029", "SRC-035", "SRC-031", "SRC-011" ], "questions": [ { "id": "cp-gov-q-lifecycle-states", "text": "What is the closed set of lifecycle states for a contact point, and which transitions between them are permitted?", "kind": "state", "answer_data": [ "State code set (proposed, active, suspended, superseded, retired, tombstoned)", "Allowed transition pairs", "Transition trigger codes", "Terminal state list" ] }, { "id": "cp-gov-q-lifecycle-valid-time", "text": "Over what real-world interval is this contact point asserted to be valid, independent of when the record was written?", "kind": "temporal", "answer_data": [ "Valid-from timestamp", "Valid-to timestamp", "Open-ended interval flag", "Offset handling rule for supplied local times" ] }, { "id": "cp-gov-q-lifecycle-record-time", "text": "How is record-time history preserved when a value is corrected rather than genuinely changed?", "kind": "lifecycle", "answer_data": [ "Record version number", "Recorded-at timestamp", "Correction versus change indicator", "Superseded version reference" ] }, { "id": "cp-gov-q-lifecycle-version-token", "text": "What opaque version token identifies the current revision for optimistic concurrency?", "kind": "identity", "answer_data": [ "Version token value", "Token derivation rule over the canonical record", "Token comparison strength", "Conditions that change the token" ] }, { "id": "cp-gov-q-lifecycle-supersession", "text": "When one contact point supersedes another, how is the predecessor kept resolvable?", "kind": "relationship", "answer_data": [ "Supersedes reference", "Superseded-by reference", "Supersession reason code", "Redirect validity period" ] } ], "data_elements": [ { "id": "cp-gov-de-lifecycle-state", "name": "Lifecycle state", "description": "Current coded state of the contact point within the closed state set.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-030" ] }, { "id": "cp-gov-de-valid-from", "name": "Valid-from timestamp", "description": "Start of the real-world interval over which the contact point is asserted usable.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-035", "SRC-029" ] }, { "id": "cp-gov-de-valid-to", "name": "Valid-to timestamp", "description": "End of the real-world validity interval, aligned to prov:invalidatedAtTime where the endpoint ceases to exist.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-029", "SRC-035" ] }, { "id": "cp-gov-de-record-version", "name": "Record version number", "description": "Monotonic revision counter for the record, incremented on every accepted mutation.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-030", "SRC-011" ] }, { "id": "cp-gov-de-version-token", "name": "Version token", "description": "Opaque validator derived from the canonical record, compared with strong equality for lost-update prevention.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-031" ] }, { "id": "cp-gov-de-supersedes-ref", "name": "Supersedes reference", "description": "Link from a replacement contact point to the predecessor it replaces, keeping the predecessor resolvable.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-029", "SRC-030" ] } ], "artifacts": [], "inline_only_rationale": "Lifecycle and versioning are expressed as state codes, interval attributes, revision counters and links on the record itself, so there is no separate deliverable to produce. Any signed revision log or immutable event stream belongs to the referenced audit-record model, which owns audit-trail persistence and evidential weight; reproducing it here would claim semantics the composition contract assigns elsewhere." } ] }, { "id": "cp-gov-layer-quality-reconciliation", "name": "Validation, Reconciliation and Decay", "description": "The checks a candidate endpoint must pass, the canonical form used for matching, the deterministic rules for merging and splitting duplicates, and the signals that erode confidence that an endpoint still reaches the intended party.", "source_refs": [ "SRC-036", "SRC-028", "SRC-011", "SRC-039" ], "findings": [ { "id": "cp-gov-finding-validation-reconciliation", "name": "Validation, canonical normalisation and cross-source reconciliation", "description": "The syntactic and referential checks applied before an endpoint becomes active, the canonical form stored alongside the verbatim original for matching, the thresholds that decide two records denote the same endpoint, and the survivorship rules and reversal path for merges.", "source_refs": [ "SRC-036", "SRC-011", "SRC-018", "SRC-028", "SRC-030" ], "questions": [ { "id": "cp-gov-q-validation-rules", "text": "Which syntactic and referential validations must a candidate endpoint pass before it can reach the active state?", "kind": "validation", "answer_data": [ "Validation rule identifiers", "Rule severity", "Failure codes", "Rule set version" ] }, { "id": "cp-gov-q-normalisation-form", "text": "What canonical normalised form is stored for matching, and is the original input preserved verbatim?", "kind": "quality", "answer_data": [ "Canonical value", "Normalisation algorithm identifier and version", "Original input value", "Lossy-normalisation flag" ] }, { "id": "cp-gov-q-match-threshold", "text": "What matching rule and threshold decide that two contact points denote the same endpoint?", "kind": "measurement", "answer_data": [ "Match rule identifier", "Similarity score", "Threshold value", "Blocking key" ] }, { "id": "cp-gov-q-survivorship", "text": "When sources conflict, which value survives and on what recorded justification?", "kind": "decision", "answer_data": [ "Survivorship rule identifier", "Winning source reference", "Losing source references", "Decision rationale", "Decided-at timestamp" ] }, { "id": "cp-gov-q-merge-reversal", "text": "How can an incorrect merge be reversed without destroying either original assertion?", "kind": "exception", "answer_data": [ "Unmerge procedure reference", "Preserved source records", "Reinstated identifiers", "Reversal event reference" ] } ], "data_elements": [ { "id": "cp-gov-de-canonical-value", "name": "Canonical endpoint value", "description": "Normalised representation of the endpoint used for comparison and matching, never overwriting the original input.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-036" ] }, { "id": "cp-gov-de-original-input-value", "name": "Original input value", "description": "The value exactly as supplied by the source, retained so normalisation is auditable and reversible.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-036", "SRC-029" ] }, { "id": "cp-gov-de-match-score", "name": "Match score", "description": "Similarity score produced by the named match rule when comparing candidate duplicates.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] }, { "id": "cp-gov-de-survivorship-rule-ref", "name": "Survivorship rule reference", "description": "Reference to the deterministic rule that selected the surviving value in a conflict.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] }, { "id": "cp-gov-de-quality-dimension-score", "name": "Quality dimension score", "description": "Measured score for a named data quality dimension such as completeness, validity, timeliness or uniqueness.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-036" ] } ], "artifacts": [ { "id": "cp-gov-artifact-reconciliation-decision-record", "name": "Reconciliation decision record", "description": "The record of a merge, split or survivorship decision, capturing the inputs, rule, score, decider and rationale so the decision can be reviewed or reversed.", "media_or_form": [ "Structured merge or split decision record", "Steward review case file", "Human-readable reconciliation report" ], "serial": true, "identity_strategy": "Use the identifier issued by the master-data system that executed the reconciliation. Where none exists, mint a governed IRI under the adopting Dimension's namespace. As a last resort assign a ULID or UUIDv7. Sequence numbers are scoped to the executing system and contain no date component.", "source_refs": [ "SRC-036", "SRC-030", "SRC-034" ] } ], "inline_only_rationale": null }, { "id": "cp-gov-finding-staleness-incident", "name": "Staleness decay, endpoint reassignment and compromise handling", "description": "How age, delivery failure, jurisdictional reassignment and compromise reports reduce confidence in an endpoint, and the guarded local state changes those signals may trigger without pre-empting the incident, breach or delivery models that own the underlying cases.", "source_refs": [ "SRC-036", "SRC-028", "SRC-039", "SRC-030" ], "questions": [ { "id": "cp-gov-q-staleness-signal", "text": "Which observable signals reduce confidence that an endpoint still reaches the intended party?", "kind": "quality", "answer_data": [ "Signal type codes (hard bounce, permanent disconnection, undeliverable postal return, reassignment hit, unsubscribe complaint)", "Signal source reference", "Observed-at timestamp", "Signal weight" ] }, { "id": "cp-gov-q-staleness-threshold", "text": "At what age or consecutive-failure count must an endpoint be re-verified or suspended?", "kind": "measurement", "answer_data": [ "Age threshold", "Consecutive failure threshold", "Suspension rule identifier", "Per-channel threshold overrides" ] }, { "id": "cp-gov-q-reassignment-check", "text": "How is a jurisdiction-specific reassignment check recorded, including the reference date used for the query?", "kind": "temporal", "answer_data": [ "Reassignment query reference", "Query reference date (for example the date permission was obtained)", "Query result code", "Jurisdiction code", "Queried-at timestamp" ] }, { "id": "cp-gov-q-compromise-response", "text": "When an endpoint is reported compromised or misdirected, what immediate state change is applied here and what is delegated?", "kind": "exception", "answer_data": [ "Compromise report reference", "Applied local state change", "Local suppression flag", "Incident or breach model reference", "List of delegated actions" ] } ], "data_elements": [ { "id": "cp-gov-de-confidence-score", "name": "Reachability confidence score", "description": "Composite, recomputable score expressing current confidence that the endpoint reaches the intended party.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036" ] }, { "id": "cp-gov-de-last-successful-use-at", "name": "Last successful use timestamp", "description": "Most recent time a use of the endpoint was reported successful by the delivery model.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-036", "SRC-035" ] }, { "id": "cp-gov-de-failure-signal", "name": "Failure signal entry", "description": "A single recorded decay signal with its type, source, weight and observation time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-036", "SRC-039" ] }, { "id": "cp-gov-de-incident-ref", "name": "Incident reference", "description": "Reference to a compromise, misdirection or breach case owned by the incident model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-reassignment-check-ref", "name": "Reassignment check reference", "description": "Reference to a jurisdictional reassignment or disconnection query and its result, with the reference date used.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-039" ] } ], "artifacts": [], "inline_only_rationale": "Staleness and compromise appear here only as confidence attributes, thresholds, signal entries and guarded state changes on the profile. The underlying delivery telemetry, incident case file, breach assessment and any regulatory notification are owned by the referenced communication-event and incident models; producing an artifact here would duplicate their lifecycle and evidence and would imply this model performs investigation or notification, which it does not." } ] } ] }, { "id": "cp-gov-bundle-protection-service", "name": "Protection, Disclosure, Disposition and Service Contract", "description": "How sensitivity classification and minimisation limit what is held, how purpose-scoped projection and redaction limit what is released, how retention and tombstoning limit how long it survives, and the canonical, format-neutral rules for reading, adding, editing, deleting and exporting the profile.", "rationale": "GDPR Articles 5(1)(c), 5(1)(e), 17, 19 and 25 require minimisation and protection by default, time-limited storage, and notification of rectification or erasure to recipients. NARA's disposal and transfer requirement groups supply the records frame; RFC 9110, RFC 6902 and RFC 9457 supply well-specified semantics for concurrency, atomic patching and non-revealing errors that can be expressed independently of any particular interface projection.", "source_refs": [ "SRC-028", "SRC-030", "SRC-031", "SRC-032", "SRC-033" ], "layers": [ { "id": "cp-gov-layer-sensitivity-disclosure", "name": "Sensitivity, Minimisation and Purpose-Scoped Disclosure", "description": "Classification of contact points by sensitivity and safety risk, the necessity test that decides what may be held at all, and the projection, redaction and export rules that decide what any given requester sees.", "source_refs": [ "SRC-028", "SRC-030", "SRC-032", "SRC-036" ], "findings": [ { "id": "cp-gov-finding-sensitivity-minimisation", "name": "Sensitivity classification and minimisation of held contact data", "description": "How a contact point is classified for sensitivity and safety risk, which purpose makes each stored field necessary, how at-risk or protected endpoints are flagged, and which attributes could reveal protected information by inference.", "source_refs": [ "SRC-028", "SRC-030", "SRC-036" ], "questions": [ { "id": "cp-gov-q-sensitivity-class", "text": "What sensitivity classification applies to this contact point, and what drives that classification?", "kind": "classification", "answer_data": [ "Sensitivity class code", "Classification scheme reference", "Classification driver (safety risk, special-category inference, professional confidentiality)", "Classified-at timestamp" ] }, { "id": "cp-gov-q-minimisation-necessity", "text": "Which purpose makes each stored field necessary, and which fields must be dropped when that purpose ends?", "kind": "requirement", "answer_data": [ "Field-to-purpose necessity map", "Drop-on-purpose-end field list", "Necessity review interval", "Reviewing role" ] }, { "id": "cp-gov-q-safety-flag", "text": "How is an at-risk or protected endpoint flagged so that it is never disclosed or printed by default?", "kind": "privacy", "answer_data": [ "Protection programme flag", "Disclosure prohibition code", "Substitute endpoint reference", "Flag-setting authority reference" ] }, { "id": "cp-gov-q-inference-risk", "text": "Which contact attributes could reveal special-category or otherwise protected information by inference?", "kind": "privacy", "answer_data": [ "Inference-risk attribute list (employer domain, clinic telephone, place-of-worship address)", "Mitigation code", "Risk assessment reference", "Residual risk note" ] } ], "data_elements": [ { "id": "cp-gov-de-sensitivity-class", "name": "Sensitivity class", "description": "Assigned sensitivity class governing default handling, projection and export behaviour.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-028", "SRC-030" ] }, { "id": "cp-gov-de-necessity-purpose-map", "name": "Field necessity map", "description": "Mapping from each retained field to the purposes that make it necessary, used to drive minimisation reviews.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-protection-flag", "name": "Protected endpoint flag", "description": "Marks an endpoint whose disclosure could endanger the party, excluding it from bulk projections and exports.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "cp-gov-de-classification-authority-ref", "name": "Classification authority reference", "description": "Reference to the role or scheme that assigned the sensitivity class, so the assignment can be reviewed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030", "SRC-028" ] } ], "artifacts": [], "inline_only_rationale": "Classification and minimisation are recorded as codes, necessity mappings and flags attached to fields, producing no separate deliverable. The classification scheme itself and any data protection impact assessment are maintained by referenced classification and risk models, so only the assigned class, its driver and its authority reference are held here." }, { "id": "cp-gov-finding-purpose-scoped-disclosure", "name": "Field- and purpose-scoped disclosure, redaction and export", "description": "The projection rules deciding which fields a requester may see for a stated purpose and role, how withheld values are masked, tokenised or proxied, what a subject-facing export must and must not contain, and how a partial or refused disclosure is communicated without revealing what was hidden.", "source_refs": [ "SRC-028", "SRC-032", "SRC-030", "SRC-011" ], "questions": [ { "id": "cp-gov-q-disclosure-projection", "text": "Which fields are released to a requester operating under a stated purpose and role?", "kind": "access", "answer_data": [ "Purpose identifier", "Requester role", "Released field list", "Withheld field list", "Projection profile identifier" ] }, { "id": "cp-gov-q-redaction-technique", "text": "How are withheld values represented: omitted, masked, tokenised or replaced by a proxy endpoint?", "kind": "security", "answer_data": [ "Redaction technique code", "Mask pattern", "Token reference", "Proxy endpoint reference", "Reversibility flag" ] }, { "id": "cp-gov-q-export-contents", "text": "What must a subject-facing export contain, and which governance fields are excluded from it?", "kind": "interoperability", "answer_data": [ "Export profile identifier", "Included field set", "Excluded internal governance fields", "Export format binding", "Content digest" ] }, { "id": "cp-gov-q-disclosure-denial", "text": "How is a partial or refused disclosure communicated so the requester can act without learning what was hidden?", "kind": "exception", "answer_data": [ "Problem type identifier", "Advisory status code", "Non-revealing detail text", "Appeal or escalation route reference" ] } ], "data_elements": [ { "id": "cp-gov-de-projection-profile-id", "name": "Projection profile identifier", "description": "Named, versioned profile binding a role and purpose pair to a permitted field set and redaction technique.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-028", "SRC-030" ] }, { "id": "cp-gov-de-redaction-technique-code", "name": "Redaction technique code", "description": "How a withheld value is represented in a projection or export.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028", "SRC-032" ] }, { "id": "cp-gov-de-export-digest", "name": "Export content digest", "description": "Digest over the canonical content of an export package, used to verify integrity on receipt.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030" ] }, { "id": "cp-gov-de-disclosure-problem-ref", "name": "Disclosure problem type reference", "description": "Reference to the registered problem type returned when a disclosure is refused or trimmed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-032" ] } ], "artifacts": [ { "id": "cp-gov-artifact-disclosure-export-package", "name": "Purpose-scoped profile export package", "description": "A portable package of the party's contact profile rendered under a named export profile, carrying an integrity digest and excluding fields that the profile withholds.", "media_or_form": [ "Structured data export bundle", "Human-readable profile statement", "Machine-readable interchange file" ], "serial": false, "identity_strategy": "Use the export job identifier issued by the executing system of record. Where none exists, mint a governed IRI under the adopting Dimension's namespace. As a last resort assign a UUIDv7. The generated-at timestamp and content digest are attributes of the package and are never used as its identifier.", "source_refs": [ "SRC-028", "SRC-030", "SRC-034" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-gov-layer-retention-disposition", "name": "Retention, Erasure and Tombstoning", "description": "How long a contact point and its version history are kept, which external authority sets the period, what remains resolvable after erasure, and how conflicts between erasure and retention duties are recorded rather than silently resolved.", "source_refs": [ "SRC-028", "SRC-030", "SRC-029" ], "findings": [ { "id": "cp-gov-finding-retention-disposition", "name": "Retention, erasure and tombstoning of contact records", "description": "The referenced schedule and disposition authority that set the keeping period, the disposition action taken and its evidence, the tombstone left so inbound references resolve without re-exposing the endpoint, the handling of legal-hold conflicts, and the notification owed to recipients of previously disclosed values.", "source_refs": [ "SRC-028", "SRC-030", "SRC-029" ], "questions": [ { "id": "cp-gov-q-retention-authority", "text": "Which retention schedule or disposition authority sets the keeping period for this contact point?", "kind": "retention", "answer_data": [ "Retention schedule reference", "Disposition authority identifier", "Retention trigger event", "Retention period", "Jurisdiction code" ] }, { "id": "cp-gov-q-erasure-outcome", "text": "When erasure is required, is the value destroyed, anonymised or suppressed, and what evidence of the action is kept?", "kind": "retention", "answer_data": [ "Disposition action code", "Executed-at timestamp", "Executing system reference", "Disposition certificate reference", "Residual fields retained" ] }, { "id": "cp-gov-q-tombstone-shape", "text": "What tombstone remains after deletion so that inbound references resolve without re-exposing the endpoint?", "kind": "constraint", "answer_data": [ "Tombstone identifier", "Tombstone state code", "Retained non-personal metadata", "Reason code", "Downstream notification list" ] }, { "id": "cp-gov-q-retention-conflict", "text": "How is a conflict between an erasure request and a legal hold or statutory retention duty resolved and recorded?", "kind": "exception", "answer_data": [ "Legal hold reference", "Conflicting obligation citation", "Resolution decision reference", "Deciding authority", "Review date" ] }, { "id": "cp-gov-q-downstream-notification", "text": "Which recipients must be told of a rectification or erasure, and how is that notification evidenced?", "kind": "process", "answer_data": [ "Recipient system list", "Notification event references", "Acknowledgement status", "Documented impossibility or disproportionate-effort rationale" ] } ], "data_elements": [ { "id": "cp-gov-de-retention-schedule-ref", "name": "Retention schedule reference", "description": "Reference to the externally owned schedule that determines the keeping period and disposition action.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030", "SRC-028" ] }, { "id": "cp-gov-de-disposition-action-code", "name": "Disposition action code", "description": "The action applied at disposition: retain, transfer, anonymise, destroy or suppress.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030" ] }, { "id": "cp-gov-de-tombstone-state", "name": "Tombstone state", "description": "Marker indicating the record has been disposed of, retaining only identifiers and reason metadata.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030", "SRC-029" ] }, { "id": "cp-gov-de-legal-hold-ref", "name": "Legal hold reference", "description": "Reference to a hold that suspends disposition, together with the authority that issued it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-030", "SRC-028" ] }, { "id": "cp-gov-de-downstream-notification-ref", "name": "Downstream notification reference", "description": "Reference to a rectification or erasure notification issued to a recipient of previously disclosed values.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] } ], "artifacts": [ { "id": "cp-gov-artifact-disposition-certificate", "name": "Disposition certificate", "description": "Evidence that a defined disposition action was executed against a contact point or its version history, naming the schedule, the executing system and the responsible agent.", "media_or_form": [ "Structured disposition record", "Signed destruction certificate", "Records-management disposal report" ], "serial": true, "identity_strategy": "Use the certificate identifier assigned by the records-management system of record that executed disposition. Where none exists, mint a governed IRI under the adopting Dimension's namespace. As a last resort assign a ULID. Certificate numbering is sequential within the executing system and excludes any date component.", "source_refs": [ "SRC-030", "SRC-028", "SRC-034" ] } ], "inline_only_rationale": null } ] }, { "id": "cp-gov-layer-service-interop", "name": "Canonical Service Contract and Interoperability", "description": "The format-neutral operation contract for reading, adding, editing, deleting and exporting the profile, and the declared crosswalks, conflicts and conformance limits against external contact vocabularies.", "source_refs": [ "SRC-031", "SRC-032", "SRC-033", "SRC-011", "SRC-018", "SRC-013" ], "findings": [ { "id": "cp-gov-finding-service-contract", "name": "Canonical service rules for read, add, edit, delete and export", "description": "The preconditions on every write, the version token comparison that prevents lost updates, the idempotency key that makes retries safe, the atomic patch semantics for partial edits, and the audit reference every accepted mutation must return.", "source_refs": [ "SRC-031", "SRC-032", "SRC-033", "SRC-034", "SRC-028", "SRC-030" ], "questions": [ { "id": "cp-gov-q-service-precondition", "text": "What preconditions must hold before a write to a contact point is accepted?", "kind": "process", "answer_data": [ "Authority check reference", "Version token match result", "Validation pass result", "Declared purpose", "Requester identity reference" ] }, { "id": "cp-gov-q-service-concurrency", "text": "How is a lost update prevented when two agents edit the same profile concurrently?", "kind": "constraint", "answer_data": [ "Expected version token", "Strong comparison rule", "Precondition-failed error code", "Retry and re-read guidance" ] }, { "id": "cp-gov-q-service-idempotency", "text": "How is a retried create or delete recognised as the same logical request?", "kind": "requirement", "answer_data": [ "Idempotency key", "Key scope and lifetime", "Stored original response reference", "Conflict behaviour on key reuse with different content" ] }, { "id": "cp-gov-q-service-patch", "text": "What patch semantics apply to partial edits, and how are they made all-or-nothing?", "kind": "process", "answer_data": [ "Permitted patch operation set", "Test-operation preconditions", "Atomicity rule", "Rejected-patch problem payload" ] }, { "id": "cp-gov-q-service-audit-link", "text": "What audit reference must every accepted mutation return, and who stores the audit entry?", "kind": "evidence", "answer_data": [ "Audit event reference", "Emitting operation identifier", "Owning audit model reference", "Linkage retention rule" ] } ], "data_elements": [ { "id": "cp-gov-de-idempotency-key", "name": "Idempotency key", "description": "Client-supplied key scoped to requester and target that lets a retried write return the original result instead of duplicating.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-031" ] }, { "id": "cp-gov-de-expected-version-token", "name": "Expected version token", "description": "Token the client believes is current, compared with strong equality before a mutation is applied.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-031" ] }, { "id": "cp-gov-de-operation-purpose", "name": "Declared operation purpose", "description": "Purpose declared by the requester for the operation, driving projection and permission checks.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-028", "SRC-038" ] }, { "id": "cp-gov-de-audit-event-ref", "name": "Audit event reference", "description": "Reference returned by the external audit model for a mutation or a value read, retained for linkage only.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-030", "SRC-028" ] }, { "id": "cp-gov-de-problem-type-ref", "name": "Problem type reference", "description": "Registered problem type identifying a class of failure, kept stable across occurrences.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-032" ] } ], "artifacts": [], "inline_only_rationale": "The service contract is a set of normative rules, preconditions and reference identifiers rather than a deliverable object, and each interface projection realises it differently. Audit entries themselves are written and retained by the referenced audit-record model, so only the returned audit event reference is held here; producing an audit artifact locally would claim audit-trail ownership the composition contract reserves to that model." }, { "id": "cp-gov-finding-interoperability-mapping", "name": "Interoperability mappings and conformance limits", "description": "Declared crosswalks between this mixin's governed fields and external contact vocabularies, with round-trip fidelity, handling of unmapped and unknown elements, recorded semantic conflicts, and explicit limits on any conformance claim.", "source_refs": [ "SRC-011", "SRC-018", "SRC-013", "SRC-037" ], "questions": [ { "id": "cp-gov-q-mapping-target", "text": "Which external contact vocabularies are mapped, at what version, and in which direction?", "kind": "interoperability", "answer_data": [ "Target vocabulary identifier", "Target version", "Mapping direction", "Mapping profile version" ] }, { "id": "cp-gov-q-mapping-fidelity", "text": "Which governed fields have no equivalent in the target vocabulary, and how are they carried?", "kind": "interoperability", "answer_data": [ "Unmapped field list", "Extension mechanism used", "Namespace prefix", "Preservation requirement for unknown properties on round-trip" ] }, { "id": "cp-gov-q-mapping-conflict", "text": "Where do external vocabularies disagree with this model's semantics, and how is the conflict recorded rather than hidden?", "kind": "constraint", "answer_data": [ "Conflict identifier", "Conflicting definitions", "Chosen interpretation", "Conflict status", "Review date" ] }, { "id": "cp-gov-q-mapping-conformance", "text": "What evidence supports any conformance claim, and where is the relationship limited to alignment only?", "kind": "evidence", "answer_data": [ "Test suite reference", "Sample round-trip results", "Claim scope statement", "Alignment-not-conformance flag" ] } ], "data_elements": [ { "id": "cp-gov-de-mapping-target-ref", "name": "Mapping target reference", "description": "Identifier and version of an external vocabulary against which a crosswalk is declared.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-018", "SRC-013" ] }, { "id": "cp-gov-de-extension-namespace", "name": "Extension namespace prefix", "description": "Namespace under which fields with no target equivalent are carried, preserved by conforming consumers.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "cp-gov-de-mapping-conflict-entry", "name": "Mapping conflict entry", "description": "A recorded semantic disagreement between this model and a target vocabulary, with the interpretation chosen.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-018", "SRC-013" ] }, { "id": "cp-gov-de-conformance-claim-scope", "name": "Conformance claim scope", "description": "Explicit statement of what is claimed, what is only aligned, and what evidence backs the claim.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-037", "SRC-011" ] } ], "artifacts": [ { "id": "cp-gov-artifact-crosswalk-profile", "name": "Vocabulary crosswalk profile", "description": "The published, versioned field-level mapping between this model and an external contact vocabulary, including unmapped fields, extension handling and recorded conflicts.", "media_or_form": [ "Field-level mapping table", "Machine-readable mapping profile", "Conformance and limitations statement" ], "serial": false, "identity_strategy": "Use the identifier assigned by the registry that publishes the crosswalk. Where none exists, mint a governed IRI under the adopting Dimension's namespace carrying an explicit semantic version. As a last resort assign a UUIDv7. Version is a separate attribute and no date is used as the identifier.", "source_refs": [ "SRC-011", "SRC-013", "SRC-034" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "cp-chan-fn-register-endpoint", "name": "Register contact point", "description": "Create a new contact point for an owning party, capturing the typed endpoint value, its declared kind, purpose contexts, capability features and initial validity, and assigning a stable identifier per the model identity priority.", "inputs": [ "Owning party reference", "Declared endpoint kind", "Raw endpoint value as supplied", "Purpose context codes", "Capability feature codes", "Valid-from instant", "Provenance of the supplied value" ], "outputs": [ "Contact point record with assigned identifier", "Normalized endpoint value and comparison key", "Validation outcome with any rejected components" ], "preconditions": [ "Owning party reference resolves in the party model", "Endpoint kind is present in the authoritative code list or carries a governed extension namespace", "Registering actor is an authorized steward or the party itself" ], "effects": [ "A contact point record exists in lifecycle state proposed or active with an open validity interval", "No verification status is asserted; verification_status remains absent until an assertion is attached", "No permission to contact is created or implied; consent remains with the referenced consent model" ], "source_refs": [ "SRC-011", "SRC-013", "SRC-016" ] }, { "id": "cp-chan-fn-normalize-endpoint", "name": "Normalize endpoint value", "description": "Apply the scheme-specific canonicalization required for storage and comparison: E.164 digit form with visual separators removed for telephone numbers, case-preserving local-part handling with case-insensitive domain for mailboxes, the RFC 3986 comparison ladder for URIs, and Normalization Form C with A-label/U-label pairing for internationalized names.", "inputs": [ "Raw endpoint value", "Endpoint kind", "Phone-context where the number is local", "Target normalization profile" ], "outputs": [ "Canonical machine form", "Comparison key", "Display form where a notation standard applies", "Normalization report listing each rule applied" ], "preconditions": [ "Endpoint kind and its governing specification are known", "For a local telephone number, a phone-context is supplied", "Input encoding is declared or reliably detected as UTF-8" ], "effects": [ "Canonical and display forms are stored as parallel representations of one endpoint, never as separate contact points", "Mailbox local-part case is preserved verbatim and is never folded", "Values that fail scheme validation are rejected with a reason rather than silently coerced" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-005", "SRC-009", "SRC-008", "SRC-003" ] }, { "id": "cp-chan-fn-attach-verification-assertion", "name": "Attach channel verification assertion", "description": "Record an externally produced proof-of-control assertion against a contact point, capturing the asserting authority, method class, claimed assurance level, event and observation instants, expiry and evidence locator. This function records an outcome; it never issues challenges, evaluates responses or determines assurance.", "inputs": [ "Contact point identifier", "Assertion identifier and asserting authority reference", "Verification status", "Method class and assurance level codes", "Assertion instant and expiry", "Evidence locator" ], "outputs": [ "Channel verification assertion linked to the contact point", "Updated verification status on the contact point", "Rejection report where the assertion subject does not match the contact point" ], "preconditions": [ "Contact point exists and is not retired", "Asserting authority is recognized by the adopting Dimension", "Assertion subject binding matches the contact-point identifier and current endpoint value" ], "effects": [ "The contact point carries a verification assertion with separate event and observation timestamps", "No proofing challenge is issued and no evaluation is performed by this model", "The proofing execution record and its audit trail remain in the referenced identity-proofing model and are not copied here" ], "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "cp-chan-fn-resolve-endpoint", "name": "Resolve contact point to current endpoint", "description": "Dereference a contact-point identifier or a historical endpoint value to the currently effective contact point by following the supersession chain, returning the canonical endpoint value, validity state and verification status without applying any preference ranking.", "inputs": [ "Contact point identifier or normalized comparison key", "Owning party reference for scoping", "Resolution instant" ], "outputs": [ "Currently effective contact point reference", "Canonical endpoint value and display form", "Validity state and verification status at the resolution instant", "Chain traversal path" ], "preconditions": [ "Starting node exists", "Supersession chain is acyclic and has at most one active successor per node", "Requesting actor holds read access to the contact point" ], "effects": [ "A resolution result is returned as of the supplied instant; no record is mutated", "Where the chain terminates in a retired node with no successor, an explicit unresolved outcome is returned rather than a stale value", "Preference ranking and channel selection are not performed here; they belong to the preferences layer of this model" ], "source_refs": [ "SRC-011", "SRC-009", "SRC-004" ] }, { "id": "cp-chan-fn-supersede-endpoint", "name": "Supersede contact point", "description": "Close the validity interval of a contact point, move it to the superseded state and create an ordered supersession link to a successor contact point with an effective instant and reason code.", "inputs": [ "Predecessor contact point identifier", "Successor contact point identifier", "Effective instant", "Supersession reason code", "Acting steward reference" ], "outputs": [ "Supersession link entry with sequence number", "Updated predecessor state and closed validity interval", "Updated successor with a supersedes reference" ], "preconditions": [ "Both contact points exist and belong to the same owning party", "The successor is not already superseding another active node in a way that would create a cycle or a second concurrent successor", "The acting steward is authorized for the owning party" ], "effects": [ "The predecessor is retained under the applicable retention rule and is not deleted by this function", "Verification assertions attached to the predecessor are marked invalidated by supersession but are not transferred to the successor", "Downstream disposition of the retained predecessor is decided by the adopting Dimension's retention policy, not by this function" ], "source_refs": [ "SRC-011", "SRC-010", "SRC-016" ] }, { "id": "cp-pref-fn-declare-preference-statement", "name": "Declare or revise a preference statement", "description": "Record a new preference, availability or routing statement for a party, or revise an existing one by supersession, with its scope, effective interval, asserter and authority.", "inputs": [ "Party reference resolvable in the parent party model", "Applicability scope: purpose class, usage context and party capacity", "Statement body: modality preference, avoidance request, language or accommodation directive, window pattern, ordering or delegation", "Effective interval and any override marker", "Asserter reference, asserter role and authority basis", "Statement time supplied by the asserter" ], "outputs": [ "Persisted statement version with a local identifier, record time and supersession links", "Validation report listing unresolved references, malformed codes and interval defects" ], "preconditions": [ "The party reference resolves in the parent party model", "The asserter is authorised for the statement class being written", "Referenced channel kinds and endpoint handles resolve in the channel area", "Language tags, time-zone identifiers and purpose codes validate against their governing registries", "The statement carries no assertion of legal effect" ], "effects": [ "Creates or supersedes a record inside this model's own statement set only", "Links the new version to the version it supersedes rather than overwriting it", "Sends no communication and schedules none", "Creates, ends or modifies nothing in the external communication-restriction registry or the consent and legal-basis model" ], "source_refs": [ "SRC-011", "SRC-018", "SRC-023" ] }, { "id": "cp-pref-fn-evaluate-availability-window", "name": "Evaluate stated availability at an instant", "description": "Determine whether an instant or interval falls inside the party's stated contact windows, after applying the time-zone frame, recurrence expansion, occurrence exceptions and effective overrides.", "inputs": [ "Statement set matching the applicable scope", "Evaluation instant or interval as an RFC 3339 value with an explicit offset", "Time-zone identifier and pinned time-zone database release", "Effective temporary overrides at the evaluation instant" ], "outputs": [ "Window disposition: inside a stated window, outside a stated window, or no window declared", "Identifier and version of the statement that governed the result", "Applied time-zone identifier and database release" ], "preconditions": [ "The time-zone identifier resolves against the cited database release", "Recurrence expressions parse without ambiguity", "The uncovered-time disposition is declared for the statement set" ], "effects": [ "Produces an advisory computation only", "Reads and writes nothing in the calendar system of record and asserts nothing about real free or busy time", "Returns no-window-declared instead of assuming the party is contactable" ], "source_refs": [ "SRC-019", "SRC-021", "SRC-024" ] }, { "id": "cp-pref-fn-resolve-contact-plan", "name": "Resolve an advisory contact plan", "description": "Produce an ordered advisory plan of candidate contact options for a request, by combining matching preference statements, stated availability, the local contact-avoidance preference and the resolution status of the external communication-restriction reference.", "inputs": [ "Party reference and request scope: purpose class, usage context and urgency tier", "Evaluation instant as an RFC 3339 value with an explicit offset", "Candidate options with channel kind and capability metadata supplied by the channel area", "Resolvable external communication-restriction reference supplied by the governance area", "Precedence ruleset edition identifier" ], "outputs": [ "Ordered advisory contact plan, or the single value unresolved", "Per-option disposition with a reason code", "Cited ruleset edition, time-zone database release and statement versions" ], "preconditions": [ "The external restriction reference is present; if it is absent or cannot be resolved, the function returns unresolved and produces no plan", "Candidate options carry the capability metadata needed to test accommodation directives", "A precedence ruleset edition is specified" ], "effects": [ "Any active external restriction blocks the applicable option and takes precedence over every local statement and every urgency tier", "The local contact-avoidance preference may only remove options and can never permit what an external restriction prohibits", "Returns unresolved rather than any permissive default when the restriction registry cannot be resolved", "Produces advisory output only: it does not send, block, throttle, queue or log a communication, and it evaluates no legal basis", "Writes nothing to the party record, the restriction registry or any delivery log" ], "source_refs": [ "SRC-011", "SRC-019", "SRC-023", "SRC-027" ] }, { "id": "cp-pref-fn-resolve-language-and-format", "name": "Resolve language and rendering directives", "description": "Select the language tag and rendering directives to use for a given candidate option, by matching the party's language preference and accommodation directives against the option's declared capabilities.", "inputs": [ "Ordered language preferences with context and modality qualifiers", "Accommodation directives and their required channel capabilities", "Declared capabilities of the selected candidate option", "Content modality of the intended communication" ], "outputs": [ "Selected language tag in canonical form, with fallbacks in order", "Rendering directives the sender must apply", "Report of directives that the option cannot satisfy" ], "preconditions": [ "Language tags are well formed and canonicalised under BCP 47", "The candidate option publishes a capability list", "Script subtags have been tested against the Suppress-Script rule" ], "effects": [ "Produces advisory rendering directives only; it translates, transcribes and generates no content", "Flags an unsatisfiable accommodation directive instead of silently degrading the communication", "Discloses to a channel provider only the required capability, never the underlying need" ], "source_refs": [ "SRC-020", "SRC-022", "SRC-026" ] }, { "id": "cp-pref-fn-explain-resolution", "name": "Explain a resolution outcome", "description": "Render a human- and agent-readable explanation of how an advisory plan or an unresolved outcome was reached, naming the statements applied, narrowed, superseded or blocking.", "inputs": [ "A resolution result with its per-option dispositions", "Precedence ruleset edition and the statement versions cited", "Time-zone database release used" ], "outputs": [ "Ordered explanation of applied, narrowed, superseded and blocking inputs with reason codes", "Explicit unresolved marker and its cause when no plan was produced", "List of statement identifiers a steward should review where a contradiction was detected" ], "preconditions": [ "The resolution result cites statement versions and a ruleset edition", "The requester is authorised to see the statement classes referenced" ], "effects": [ "Produces an explanation only; it changes no statement and re-runs no decision", "Reports only the resolution status of the external restriction reference and never the content of the external restriction record", "Is not an audit record and does not substitute for the sending or logging system's own trail, which those systems own and retain" ], "source_refs": [ "SRC-018", "SRC-019", "SRC-023" ] }, { "id": "cp-gov-fn-resolve-assertion-authority", "name": "Resolve and bind assertion authority", "description": "Resolve the mandate that entitles a requester to assert or change a contact point, verify it is in force and covers the requested operation, and bind the external authorisation decision reference to the pending change. Policy evaluation itself is performed by the referenced authorisation model.", "inputs": [ "Requester identity reference", "Requested operation code", "Target contact point or profile reference", "Declared purpose", "Claimed mandate reference (optional)" ], "outputs": [ "Authority binding record", "External authorisation decision reference", "Permitted operation set for this request" ], "preconditions": [ "Target profile is resolvable", "Requester identity has been authenticated by an external identity service", "Any claimed mandate resolves and is within its validity interval" ], "effects": [ "Records the authority basis and the decision reference against the pending change", "Blocks the operation when no in-force mandate covers it", "Does not author, evaluate, cache or store authorisation policy, which remains owned by the authorisation model" ], "source_refs": [ "SRC-028", "SRC-017", "SRC-029" ] }, { "id": "cp-gov-fn-assert-contact-point", "name": "Assert a contact point", "description": "Register a new contact point for a party with full provenance, canonical and original values, an initial lifecycle state and an initial version token.", "inputs": [ "Candidate endpoint value", "Channel type and context labels", "Asserting agent reference", "Provenance attributes including event and observation times", "Idempotency key" ], "outputs": [ "Registered contact point with assigned identifier", "Initial lifecycle state", "Provenance record", "Version token" ], "preconditions": [ "Assertion authority has been resolved", "Validation rules pass at the required severity", "A sensitivity classification has been assigned" ], "effects": [ "Creates the record in proposed or unverified-active state, never in verified state", "Stores the canonical value alongside the verbatim original input", "Sets record version one and an initial version token", "Emits a change signal so the external audit model can record the event and returns its reference" ], "source_refs": [ "SRC-011", "SRC-029", "SRC-036", "SRC-030" ] }, { "id": "cp-gov-fn-record-control-verification", "name": "Record endpoint control verification", "description": "Record the non-secret outcome of an externally executed challenge proving control of an endpoint, together with method, assurance and freshness.", "inputs": [ "Contact point reference", "Verification method code", "External verification event reference", "Outcome code", "Verified-at timestamp" ], "outputs": [ "Updated verification state and assurance", "Verification attestation reference", "Next re-verification due timestamp" ], "preconditions": [ "The verification was executed by an external verifier", "The submitted payload contains no secret material", "The contact point is not tombstoned" ], "effects": [ "Sets the non-secret verification state, method and assurance", "Rejects any payload containing one-time codes, challenge secrets, session tokens or message bodies", "Confers no permission to contact the endpoint; permission remains governed by the referenced consent and restriction models" ], "source_refs": [ "SRC-017", "SRC-028", "SRC-011" ] }, { "id": "cp-gov-fn-bind-permission-reference", "name": "Bind a permission reference to a purpose and endpoint", "description": "Attach a resolvable reference to an externally owned consent or legal-basis record, scoped to a purpose, channel and validity window, without copying the target record's content.", "inputs": [ "Contact point reference", "Purpose identifier", "Consent or legal-basis record reference and schema version", "Binding scope code", "Validity interval" ], "outputs": [ "Permission binding entry", "Last-checked timestamp", "Effective usability indicator for the purpose" ], "preconditions": [ "The referenced permission record resolves and its schema version is known", "The purpose exists in the governed purpose taxonomy", "No blocking restriction entry is currently in force for the endpoint and purpose" ], "effects": [ "Stores only the reference, binding scope, purpose, legal basis code and validity window", "Never copies notice text, evidence payloads, recordings or complete consent objects", "Marks the binding stale when the source record signals change, prompting re-resolution rather than local repair" ], "source_refs": [ "SRC-028", "SRC-037", "SRC-038" ] }, { "id": "cp-gov-fn-transition-lifecycle-state", "name": "Transition contact point lifecycle state", "description": "Apply a permitted state transition with effective dating, preserving prior record versions and creating supersession links where a replacement is involved.", "inputs": [ "Contact point reference", "Target state code", "Transition trigger code", "Effective-from timestamp", "Expected version token" ], "outputs": [ "New lifecycle state", "New record version and version token", "Supersession links where applicable" ], "preconditions": [ "The transition is permitted by the closed state model", "The requester is authorised for the operation", "The expected version token matches under strong comparison" ], "effects": [ "Closes the prior validity interval and opens the new one", "Preserves the prior record version rather than overwriting it", "Emits a change signal and retains the returned audit event reference" ], "source_refs": [ "SRC-030", "SRC-035", "SRC-031", "SRC-029" ] }, { "id": "cp-gov-fn-reconcile-contact-points", "name": "Reconcile duplicate or conflicting contact points", "description": "Match candidate records under a declared rule and threshold, apply survivorship, and emit a reversible decision record that keeps every source assertion resolvable.", "inputs": [ "Candidate record set", "Match rule identifier and threshold", "Survivorship rule identifier", "Steward decision where the rule requires human adjudication" ], "outputs": [ "Merged or split result", "Reconciliation decision record", "Retained references to losing source assertions" ], "preconditions": [ "Canonical normalisation has been applied to all candidates", "A match score has been computed against a declared threshold", "Conflicting records are within the same authority scope or an authority rank is available" ], "effects": [ "Designates surviving values with a recorded justification and decision timestamp", "Keeps losing assertions resolvable so an incorrect merge can be reversed", "Never silently discards a source assertion or overwrites its provenance" ], "source_refs": [ "SRC-036", "SRC-011", "SRC-018", "SRC-030" ] }, { "id": "cp-gov-fn-assess-endpoint-staleness", "name": "Assess endpoint staleness and compromise signals", "description": "Recompute reachability confidence from age, delivery failure, reassignment and compromise signals, and propose a guarded state change when a threshold is crossed.", "inputs": [ "Contact point reference", "Delivery and failure signal references with observation times", "Age and failure thresholds for the channel", "Jurisdictional reassignment check reference" ], "outputs": [ "Updated reachability confidence score", "Recommended state change", "Re-verification requirement" ], "preconditions": [ "Signals carry observation timestamps and a source reference", "Thresholds are defined for the channel and jurisdiction", "The record is not already tombstoned" ], "effects": [ "Updates the confidence score and may propose suspension or re-verification", "Records the reassignment query with the reference date used", "Does not execute delivery, open an incident, assess a breach or issue any regulatory notification, all of which remain with the referenced delivery and incident models" ], "source_refs": [ "SRC-036", "SRC-028", "SRC-039" ] }, { "id": "cp-gov-fn-project-purpose-view", "name": "Project a purpose-scoped view", "description": "Produce the field projection permitted for a requester's role and declared purpose, applying redaction, masking, tokenisation or proxy substitution to withheld values.", "inputs": [ "Contact point or profile reference", "Requester role", "Declared purpose", "Projection profile identifier" ], "outputs": [ "Redacted field projection", "Withheld field summary", "Projection decision reference" ], "preconditions": [ "A purpose is declared and recognised in the governed taxonomy", "Sensitivity class and protection flags have been evaluated", "A projection profile exists for the role and purpose pair" ], "effects": [ "Returns only the fields necessary for the declared purpose", "Applies the profile's redaction technique to every withheld value", "Returns a non-revealing problem object when the request is refused, exposing no information about hidden fields" ], "source_refs": [ "SRC-028", "SRC-032", "SRC-030" ] }, { "id": "cp-gov-fn-export-profile-package", "name": "Export a profile package", "description": "Assemble a portable export of the party's contact profile under a named export profile, excluding internal governance fields and attaching an integrity digest.", "inputs": [ "Party profile reference", "Export profile identifier", "Requester identity and declared purpose", "Target format binding" ], "outputs": [ "Export package", "Content digest and digest algorithm identifier", "Export job reference" ], "preconditions": [ "The export is authorised for the requester and purpose", "A redaction profile has been resolved", "Protection-flagged endpoints have been excluded or individually approved" ], "effects": [ "Produces a portable package with an integrity digest and a generated-at timestamp", "Excludes governance-only fields not required by the export profile", "Records the export as a governed event and retains the audit event reference returned by the audit model" ], "source_refs": [ "SRC-028", "SRC-030", "SRC-011" ] }, { "id": "cp-gov-fn-apply-governed-patch", "name": "Apply a governed partial edit", "description": "Apply an ordered patch to a contact point atomically under optimistic concurrency and idempotency, returning a structured problem object on rejection.", "inputs": [ "Contact point reference", "Ordered patch operation list", "Expected version token", "Idempotency key", "Declared purpose" ], "outputs": [ "Updated record or rejection", "New version token", "Problem object on failure" ], "preconditions": [ "The expected version token matches under strong comparison", "Every test operation in the patch is satisfied against the pre-state", "The requester is authorised for each affected field" ], "effects": [ "Applies all operations or leaves the record entirely unchanged", "Returns the stored original result when a previously seen idempotency key is replayed with identical content", "Resets verification state in the same atomic operation when the endpoint value changes", "Rejects operations targeting referenced consent, restriction, audit or retention-schedule records with a distinct problem type" ], "source_refs": [ "SRC-031", "SRC-032", "SRC-033" ] }, { "id": "cp-gov-fn-dispose-or-tombstone", "name": "Dispose of or tombstone a contact record", "description": "Execute the local record action for retirement, erasure or anonymisation under an externally owned schedule, leaving a resolvable tombstone and recording the outcome.", "inputs": [ "Contact point reference", "Disposition trigger (schedule expiry, erasure instruction, retirement)", "Retention schedule reference", "Legal hold status", "Downstream recipient list" ], "outputs": [ "Disposition outcome", "Tombstone record", "Disposition certificate reference", "Downstream notification references" ], "preconditions": [ "The retention period has elapsed or a valid erasure instruction exists", "No unresolved legal hold applies", "The recipient list for rectification or erasure notification has been resolved" ], "effects": [ "Destroys, anonymises or suppresses the value while leaving a tombstone carrying identifier, state, reason and disposition timestamps", "Records the executing system and the responsible agent", "Suspends and records the conflict, with a review date, where erasure collides with a retention duty, without adjudicating it", "Leaves the retention period, the disposition authority and the legality of erasure owned by the referenced records-retention model or, absent a binding, by the adopting Dimension's records policy" ], "source_refs": [ "SRC-028", "SRC-030", "SRC-029" ] } ], "composition": [ { "target": "WM-PER-001 Person / Party identity", "relation": "MIX-IN", "purpose": "WM-PER-010 is mixed into the party model to supply the contact profile. It carries only a reference to the owning party plus the party-kind facet needed to select validation rules; party identifiers, names, matching and party lifecycle stay in the target.", "required": true, "source_refs": [ "SRC-011", "SRC-013", "SRC-014" ] }, { "target": "Postal address / place model (registry identifier unresolved)", "relation": "REFERENCE", "purpose": "The postal endpoint carries a reference to an addressed location plus the delivery-role parameters (attention line, care-of, box designation) and the country code that selects a template. Address component structure, template rendition, geocoding and address lifecycle remain owned by the target.", "required": false, "source_refs": [ "SRC-012", "SRC-011", "SRC-010" ] }, { "target": "Communication event / message-delivery model (registry identifier unresolved)", "relation": "REFERENCE", "purpose": "Reachability status carries a locator for delivery or probe evidence held by the target. Message content, envelopes, delivery attempts, failure reports and engagement records are not modelled here.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Identity proofing and verification-process model (registry identifier unresolved)", "relation": "REFERENCE", "purpose": "Verification assertions carry the asserting authority, method class, assurance level, timestamps and an evidence locator. Challenge issuance, evaluation, assurance determination and the proofing audit trail remain wholly in the target.", "required": false, "source_refs": [ "SRC-017", "SRC-015" ] }, { "target": "Consent and legal-basis model (registry identifier unresolved)", "relation": "REFERENCE", "purpose": "Purpose contexts declared on an endpoint state intended use only. Permission to contact, lawful basis, withdrawal and objection outcomes are referenced from the target; neither JSContact nor schema.org ContactPoint carries consent semantics, so no local permission structure is created.", "required": false, "source_refs": [ "SRC-011", "SRC-013" ] }, { "target": "ITU-T E.164 and IETF RFC 3966 tel URI", "relation": "ALIGN", "purpose": "Alignment for the canonical telephone endpoint: 15-digit maximum, CC/NDC/SN structure, global versus local numbers, mandatory phone-context and separator-insensitive comparison. Conformance is not claimed without validation evidence per instance.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ] }, { "target": "ITU-T E.123 notation", "relation": "ALIGN", "purpose": "Alignment for the human-readable display form of telephone numbers, email addresses and web addresses, held separately from the canonical machine form.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "IETF RFC 5321, RFC 6068, RFC 6530 and RFC 5890", "relation": "ALIGN", "purpose": "Alignment for mailbox syntax, case-sensitivity of local parts, mailto projection, internationalized email and IDNA A-label/U-label handling.", "required": false, "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-008" ] }, { "target": "IETF RFC 3986 URI generic syntax", "relation": "ALIGN", "purpose": "Alignment for URI component structure and the normalization/comparison ladder applied to web and online-service endpoints.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "IETF RFC 9553 JSContact", "relation": "ALIGN", "purpose": "Primary interchange alignment: Card uid, Id-keyed channel maps, contexts, features, pref, label, countryCode, language and localizations map to this model's identity, classification and internationalization elements.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "IETF RFC 6350 vCard 4.0 and the W3C vCard Ontology", "relation": "ALIGN", "purpose": "Legacy and RDF alignment for TEL, EMAIL, ADR, URL and IMPP with TYPE, PREF, PID and ALTID, and for hasTelephone, hasEmail, hasAddress and hasURL in the RDF projection. The W3C document is an Interest Group Note, not a Recommendation.", "required": false, "source_refs": [ "SRC-010", "SRC-014" ] }, { "target": "schema.org ContactPoint", "relation": "ALIGN", "purpose": "Publication alignment for contactType, contactOption, areaServed, availableLanguage, hoursAvailable, email, telephone and faxNumber. schema.org aggregates several channels on one ContactPoint whereas this model holds one typed endpoint per contact point; the mapping is therefore one-to-many.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "UPU S42 international postal address components and templates", "relation": "ALIGN", "purpose": "Alignment for the postal component set (Part A) and country template library (Part B) that the referenced address model implements; this model aligns only its country binding and delivery-role attributes.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "SEMIC Core Public Organisation Vocabulary ContactPoint", "relation": "ALIGN", "purpose": "Public-sector alignment for contact point as a first-class class with email, telephone, contact page, opening hours and availability restriction expressed as temporal entities.", "required": false, "source_refs": [ "SRC-016" ] }, { "target": "OpenID Connect Core 1.0 verified contact claims", "relation": "ALIGN", "purpose": "Alignment for email_verified and phone_number_verified as provider-asserted claims, binding this model's verification status to an identifiable asserting authority.", "required": false, "source_refs": [ "SRC-015" ] }, { "target": "WM-PER-001 Party / Person", "relation": "MIX-IN", "purpose": "Attach preference, availability and routing statements to a governed party identity. Party identity, naming, roles and life events remain owned by the parent model and are referenced, never restated.", "required": true, "source_refs": [ "SRC-011", "SRC-023" ] }, { "target": "Contact channel and endpoint descriptor area of WM-PER-010", "relation": "COMPOSE", "purpose": "Preference statements bind to channel kinds and endpoint handles published by the channel area, which owns the endpoint address, its syntax, its capability metadata and its verification state. This area stores no address.", "required": true, "source_refs": [ "SRC-011", "SRC-023" ] }, { "target": "External communication-restriction registry (legally governed restrictions)", "relation": "REFERENCE", "purpose": "Carry only the resolvable reference and its resolution status as an input to the advisory resolver. The restriction record, its lifecycle, its evaluation and its enforcement stay with the registry; this model never creates, ends, weakens or interprets it, and returns unresolved when the reference cannot be resolved.", "required": true, "source_refs": [ "SRC-023", "SRC-011" ] }, { "target": "Consent and legal-basis model", "relation": "REFERENCE", "purpose": "Point at the lawfulness decision without reproducing it. A stated preference is not consent evidence and a resolved plan is never a legal-basis determination.", "required": false, "source_refs": [ "SRC-023" ] }, { "target": "Message delivery and logging model", "relation": "REFERENCE", "purpose": "Identify the consumer of an advisory plan. Delivery attempts, outcomes, retries and audit trails are created, owned and retained there; this model neither writes nor mirrors them.", "required": false, "source_refs": [ "SRC-021", "SRC-027" ] }, { "target": "IETF JSContact (RFC 9553) and vCard (RFC 6350) preference vocabulary", "relation": "ALIGN", "purpose": "Map usage contexts, preference ordering, preferred languages, phone feature values and RELATED relation types. Alignment only; no conformance is claimed and the numeric comparison-scope rule of PREF is preserved rather than flattened.", "required": false, "source_refs": [ "SRC-011", "SRC-018", "SRC-025" ] }, { "target": "IETF Calendar Availability (RFC 7953) and JSCalendar (RFC 8984)", "relation": "ALIGN", "purpose": "Reuse recurring availability, occurrence override and priority-resolution semantics for stated contact windows, without adopting calendar scheduling, free/busy publication or scheduling-message workflows.", "required": false, "source_refs": [ "SRC-019", "SRC-021" ] }, { "target": "IANA Time Zone Database", "relation": "ALIGN", "purpose": "Use registry time-zone identifiers and pinned database releases to interpret stated local windows; the zone rules themselves are never copied into this model.", "required": false, "source_refs": [ "SRC-024", "SRC-018" ] }, { "target": "BCP 47 / RFC 5646 language tag syntax and the IANA subtag registry", "relation": "ALIGN", "purpose": "Constrain language preference values to canonical BCP 47 tags, including the Suppress-Script rule for script subtags.", "required": false, "source_refs": [ "SRC-020", "SRC-011" ] }, { "target": "1EdTech / ISO-IEC 24751 AccessForAll Personal Needs and Preferences", "relation": "ALIGN", "purpose": "Express accommodation directives functionally and support multiple context-specific preference sets. The full functional-ability profile and any diagnostic content remain in the accessibility or health model.", "required": false, "source_refs": [ "SRC-026" ] }, { "target": "HL7 FHIR R5 ContactPoint (rank, period, use)", "relation": "ALIGN", "purpose": "Interoperate with health-sector exchange for preference ranking, validity periods and temporary use, noting that FHIR rank orders a set while vCard PREF is comparable only within one property.", "required": false, "source_refs": [ "SRC-023", "SRC-018" ] }, { "target": "schema.org ContactPoint and ContactPointOption", "relation": "ALIGN", "purpose": "Support publication of organisation-side contact purpose, available languages, available hours and accessibility options on the web, acknowledging that the published enumeration is far narrower than the functional directive set held here.", "required": false, "source_refs": [ "SRC-013", "SRC-022" ] }, { "target": "OASIS Common Alerting Protocol v1.2 urgency vocabulary", "relation": "ALIGN", "purpose": "Offer a sector-neutral urgency tier vocabulary for escalation preference. CAP alert structure, dissemination and public-warning semantics are not adopted, and no CAP element grants override of an external restriction.", "required": false, "source_refs": [ "SRC-027" ] }, { "target": "WM-PER-001 Person / Party", "relation": "MIX-IN", "purpose": "Attach governed contact points, preferences and their governance to a party without redefining party identity, names, roles or relationships, which remain owned by the parent model.", "required": true, "source_refs": [ "SRC-011", "SRC-013" ] }, { "target": "Consent and legal-basis record model (ISO/IEC TS 27560 aligned)", "relation": "REFERENCE", "purpose": "Carry the reference, schema version, binding scope, purpose and validity window for permission to use an endpoint. Consent capture, notice text, evidence, receipts and the withdrawal lifecycle remain owned and operated by the target.", "required": true, "source_refs": [ "SRC-037", "SRC-028", "SRC-038" ] }, { "target": "Communication restriction and suppression registry model", "relation": "REFERENCE", "purpose": "Resolve objection, do-not-contact and jurisdictional suppression entries that block use of an endpoint. Creation, expiry and enforcement of those entries remain with the target.", "required": false, "source_refs": [ "SRC-028", "SRC-039" ] }, { "target": "Audit record and event log model", "relation": "REFERENCE", "purpose": "Retain only the audit event reference returned for each mutation and value read. Audit persistence, immutability, retention and querying remain with the target.", "required": true, "source_refs": [ "SRC-030", "SRC-028" ] }, { "target": "Authorisation policy decision model", "relation": "REFERENCE", "purpose": "Obtain and record allow or deny decision references as write preconditions. Policy authoring, evaluation and enforcement remain with the target.", "required": true, "source_refs": [ "SRC-028", "SRC-017" ] }, { "target": "Identity verification and credential model (NIST SP 800-63A-4 aligned)", "relation": "REFERENCE", "purpose": "Reference external endpoint-control verification events and assurance levels. Challenge generation, secret handling, identity proofing and credential lifecycle remain with the target.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "Records retention schedule and disposition authority model", "relation": "REFERENCE", "purpose": "Resolve the retention period, disposition authority and legal-hold status governing deletion. Schedule authoring, approval and hold adjudication remain with the target.", "required": true, "source_refs": [ "SRC-030", "SRC-028" ] }, { "target": "Communication event and message delivery model", "relation": "REFERENCE", "purpose": "Consume delivery outcome and failure signals as staleness inputs. Message content, delivery execution, logs and campaign scheduling remain with the target.", "required": false, "source_refs": [ "SRC-036", "SRC-039" ] }, { "target": "Postal address and location model", "relation": "COMPOSE", "purpose": "Compose structured postal endpoints from the address model rather than restating address structure, validation reference data or geocoding.", "required": false, "source_refs": [ "SRC-018", "SRC-011" ] }, { "target": "RFC 9553 JSContact", "relation": "ALIGN", "purpose": "Align endpoint, context and preference semantics and carry mapping and extension parameters. JSContact remains the external normative vocabulary and is not restated here.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "RFC 6350 vCard", "relation": "ALIGN", "purpose": "Preserve legacy interchange fidelity on export, with recorded loss where bitemporal history cannot round-trip through a single revision property.", "required": false, "source_refs": [ "SRC-018" ] }, { "target": "schema.org ContactPoint", "relation": "ALIGN", "purpose": "Provide a publish-facing crosswalk for organisational contact points, recorded as partial alignment because the target carries no verification, provenance or permission semantics.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "W3C PROV-O", "relation": "ALIGN", "purpose": "Express assertion provenance using the agent, activity and entity patterns and the revision and invalidation properties, without importing a provenance store or its query semantics.", "required": false, "source_refs": [ "SRC-029" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single accountable owner for the WM-PER-010 package and a deputy identity steward, both resolvable as party references with effective intervals.", "The owner package must declare the authoritative system of record for each channel type and the authority ranking used when copies disagree during reconciliation.", "The owner package must bind, by reference, the consent and legal-basis model, the communication-restriction registry, the audit-record model, the authorisation decision model and the retention schedule authority; an unbound required reference blocks promotion beyond candidate status.", "The owner package must publish the governed purpose taxonomy, the projection profiles for field- and purpose-scoped disclosure, and the export profiles, each with an explicit version." ], "namespace_guidance": "Governed identifiers are minted under a Dimension-controlled namespace with a stable authority segment and an explicit semantic version, for example /wm-per-010//. Local identifiers are opaque, lower-kebab-case, and contain no date, no personal data and no endpoint value. Fields carried from external vocabularies retain their originating namespace prefix, as JSContact vendor extensions require, and are never flattened into the core namespace; consumers must preserve unknown namespaced properties on round-trip.", "registry_links": [ "The vr.wm-per-010 registry entry is the authoritative record of this model's status, entry kind, parent (WM-PER-001) and review state; the review_state value boundary-review-required must be cleared before adoption.", "External vocabulary registries used for alignment are the IANA registries associated with RFC 9553 and RFC 6350, and dated schema.org releases; each crosswalk profile records the target version it was authored against." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is a storage-neutral logical record: properties ordered by stable name, one canonical value per endpoint, the verbatim original input retained alongside, and absent distinguished from explicitly null.", "Endpoint values are normalised per channel before any comparison (for example an internationally formatted telephone number, or a case-folded domain part for an email address), and the normalisation algorithm identifier and version are recorded; normalisation never destroys the original input.", "All time values are canonicalised to RFC 3339 with seconds and an explicit offset or Z before hashing, comparison or digest computation.", "Integrity digests are computed over the canonical logical record, not over any particular serialization; where a serialized projection is used, a deterministic encoding is required so digests remain stable across systems.", "Governance-only fields that differ legitimately between copies, such as local cache timestamps, are excluded from the canonical form used to derive the version token." ], "patch_rules": [ "Partial edits are expressed as an ordered operation list (add, remove, replace, move, copy, test) applied atomically: if any operation fails, the record is left entirely unchanged.", "Every mutating patch must carry at least one test operation or an expected version token asserting the pre-state it was authored against.", "Patches may not create, alter or delete referenced consent, restriction, audit or retention-schedule records; operations targeting those paths are rejected with a distinct registered problem type.", "A patch that changes a verified endpoint value must reset the verification state to unverified within the same atomic operation.", "Patch payloads containing secret authenticators, one-time codes, session tokens, message content or complete consent evidence objects are rejected before evaluation.", "Patches to superseded or tombstoned versions are rejected; corrections are made by creating a new record version that supersedes the prior one." ], "compatibility_rules": [ "Adding optional fields or new enumeration members is a minor change; consumers must ignore unknown properties and preserve them on round-trip.", "Removing a field, narrowing cardinality, changing an identity strategy, or altering lifecycle state semantics is a breaking change requiring a new major model version and a published crosswalk from the previous version.", "Conformance to an external vocabulary is claimed only where round-trip test evidence exists; otherwise the relationship is recorded as alignment, and every known semantic conflict is registered with the interpretation chosen.", "Projection and export profiles are versioned independently of the model; a consumer must be able to request a named profile version and receive stable field membership." ] }, "artifact_rules": { "identity_priority": [ "The identifier issued by the authoritative master system of record for the artifact, such as the records-management system's disposition certificate number, the verifying system's verification event identifier, or the issuing registry's crosswalk identifier.", "A governed global identifier or IRI minted under the adopting Dimension's namespace, with an explicit authority segment and semantic version, where no master-system identifier exists.", "A UUID (preferably UUIDv7) or ULID assigned by the adopting Dimension as a last resort, treated as opaque and never parsed for meaning.", "No date, timestamp, endpoint value or other personal datum is ever used as an identifier; identifiers must remain stable across renames, re-issues and format migrations." ], "timestamp_rule": "All time values are recorded in RFC 3339 format with seconds present and an explicit numeric offset or Z; unqualified local time is rejected. Event time (when the fact became true in the world, such as when the party began using the endpoint) is recorded separately from observation time (when a source or verifier observed it) and from ingestion or record time (when this model wrote the assertion). The three are stored in distinct fields even when they coincide, and the originating clock or supplying system is recorded whenever a time is provided by an external source.", "serial_naming_rule": "Serial artifacts (reconciliation decision records and disposition certificates) are numbered sequentially within the scope of the executing system of record, using an explicit series code and a zero-padded monotonic counter, for example RECON--000123 or DISP--000045. The series never encodes a date or a personal identifier, counters are never reused, and any gap is recorded with a reason.", "integrity_rule": "Every artifact carries a digest over its canonical form, the digest algorithm identifier, the generating function, the generated-at timestamp and the responsible agent. Digests are verified on read and before any export; a mismatch places the artifact in a quarantined state and blocks disclosure until a steward resolves it. Artifacts are never mutated in place: a correction produces a new artifact version linked to its predecessor, and the predecessor remains resolvable until its own disposition." }, "policies": [ "Separation of proof and permission: verified control of an endpoint never implies lawful permission to use it for a purpose, and a valid permission never implies the endpoint is reachable or still controlled. Both states must be independently satisfied before an endpoint is offered for use.", "Secret exclusion: one-time codes, challenge secrets, passwords, session tokens, message bodies and complete consent evidence objects are never persisted in this model. Only non-secret outcomes, references, assurance codes and digests are held, and non-compliant payloads are rejected rather than truncated.", "Reference-not-replication: where a concept is owned by a neighbouring model, this model stores the identifier, binding scope and validity window only, re-resolving on a declared cache validity rather than caching target content.", "Minimisation by default: a field is stored only where a declared purpose makes it necessary, and disclosure defaults to the narrowest projection available for the requester's role and purpose.", "No silent loss: reconciliation, supersession and disposition always leave a resolvable trace, whether a retained losing assertion, a supersession link or a tombstone.", "Jurisdictional overlay: channel- and country-specific duties, such as reassigned-number checks or direct-marketing objection handling, are applied as declared overlays keyed to the endpoint's jurisdiction, never as global defaults." ], "crud": { "read": [ "Reads are purpose-declared: a requester states role and purpose and receives only the projection permitted for that pair; an undeclared purpose yields the minimal projection or a refusal.", "Reads of endpoint values are recorded as governed access events and the returned audit event reference is retained; reads of governance metadata alone may be recorded in aggregate under the Dimension's declared policy.", "Historical reads are supported both by record version and by valid-time instant; a request must state whether it wants the current record, a specific record version, or the state as at a valid-time instant.", "Tombstoned records return tombstone metadata and a gone-style outcome; the erased value is never reconstructed or returned.", "Protection-flagged endpoints are omitted from bulk and enumerative reads regardless of the requester's role." ], "create": [ "Creation requires a resolved authority basis, a declared purpose, passing validation at the required severity, and an assigned sensitivity classification.", "New endpoints enter a proposed or unverified-active state; a create operation never sets a verified state directly.", "Creation is idempotent under a client-supplied key scoped to requester and target profile; replaying the key with identical content returns the original result rather than creating a duplicate, and replaying it with different content is refused as a conflict.", "Creation records provenance (agent, activity, source) with separated event, observation and ingestion times, and sets record version one with an initial version token." ], "update": [ "Updates are conditional on an expected version token compared with strong equality; a mismatch is refused rather than merged, and the client is told to re-read.", "Corrections (the record was wrong) and changes (the world changed) are distinguished: a correction supersedes the record version while preserving it, whereas a change closes the prior valid-time interval and opens a new one.", "Any update to an endpoint value resets verification state and recomputes reachability confidence within the same atomic operation.", "Updates may not alter the provenance of prior versions, nor referenced consent, restriction, audit or retention records; such operations are refused with a distinct problem type.", "Every accepted update emits a change signal and retains the audit event reference returned by the referenced audit model." ], "delete": [ "Default disposition is retirement and tombstoning rather than physical deletion: the tombstone retains only the identifier, lifecycle state, reason code, disposition timestamps and the links needed for inbound references to resolve.", "Physical erasure or irreversible anonymisation is performed only on a valid erasure instruction, or when the retention period from the referenced retention schedule has elapsed with no legal hold; both paths produce a disposition certificate naming the executing system and responsible agent.", "The retention period, the disposition authority and the legality of erasure are owned by the referenced records-retention and disposition model and, where no such model is bound, by the adopting Dimension's records policy. This model executes only the local record action and records the outcome; it does not set schedules or authorise destruction.", "Where erasure conflicts with a legal hold or a statutory retention duty, disposition is suspended, the conflict, the citation and the deciding authority are recorded, and a review date is set. This model does not adjudicate the conflict.", "Recipients of previously disclosed values are notified of rectification or erasure through the referenced downstream-notification process, and acknowledgements or a documented impossibility rationale are retained against the tombstone.", "Version history is disposed under the same schedule as the current record; a tombstone is not itself deleted while inbound references remain resolvable, and its own disposition is governed by the referenced schedule." ] }, "roles": [ { "name": "Contact Data Subject", "responsibilities": [ "Assert and correct their own contact points and preferences", "Request export of their profile and erasure or restriction of endpoints", "Exercise objection and withdrawal through the referenced consent and restriction models" ] }, { "name": "Identity Steward", "responsibilities": [ "Verify authority mandates and their scope before privileged changes are accepted", "Adjudicate reconciliation, survivorship and unmerge decisions requiring human judgement", "Maintain sensitivity classifications, quality thresholds and staleness policies" ] }, { "name": "Model Owner (adopting Dimension)", "responsibilities": [ "Maintain the owner package, required bindings to neighbouring models, purpose taxonomy and projection and export profiles", "Approve breaking version changes and publish crosswalks", "Clear the registry review state before adoption and keep alignment claims evidence-backed" ] }, { "name": "Records and Retention Officer", "responsibilities": [ "Bind the retention schedule and disposition authority applicable to each channel and jurisdiction", "Approve disposition runs and hold or release legal holds", "Review disposition certificates and unresolved retention conflicts" ] }, { "name": "Privacy Officer", "responsibilities": [ "Approve sensitivity classifications, minimisation decisions and disclosure profiles", "Review break-glass access, bulk exports and protection-flag releases", "Escalate conflicts between erasure duties and retention obligations to the deciding authority" ] }, { "name": "Integrating System Operator", "responsibilities": [ "Operate non-authoritative copies within the declared cache validity and authority ranking", "Honour projection, idempotency and concurrency rules on every operation", "Propagate rectification and erasure notifications and return acknowledgements" ] } ], "access": { "default_rule": "Deny by default. Access is granted only for an explicitly declared role and purpose pair against a published projection profile, and no requester receives an unredacted endpoint value without a purpose that makes that specific field necessary.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "The data subject, or a holder of an in-force mandate acting within its scope, may read the full unredacted profile including governance metadata, except fields that would reveal a third party or an unclosed investigation.", "Break-glass access for safety-of-life contact requires a recorded justification, a named approver and a time-boxed scope, and is reported to the privacy officer within the Dimension's declared window.", "Protection-flagged endpoints are excluded from all bulk projections and exports regardless of role, and may be released only through an individually approved, named request.", "Supervisory or regulatory access is granted under a referenced legal-basis record and is logged as a distinct access class rather than as ordinary operational access.", "Artifact-scope access may be granted without finding-scope access where an auditor needs only a disposition certificate or verification attestation, and never carries the underlying endpoint value." ], "audit_requirements": [ "Every read of an endpoint value and every accepted mutation records requester identity, role, declared purpose, projection profile, version token and outcome, and retains the audit event reference returned by the audit model.", "Break-glass access, bulk export and disposition operations additionally record the approving agent and justification text, and are subject to periodic steward review.", "Audit entries are written and retained by the referenced audit-record model; this model must never be the sole holder of audit evidence and must not mutate, expire or re-order audit entries.", "Refusals are audited as well as grants, using registered problem types that reveal nothing about withheld fields." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner", "Model ID and version", "Required referenced models" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other file or collection.", "Read the specification next for scope, boundary notes and the composition contract; the specification prevails over any storage or interface detail on conflict.", "Read the storage type document to learn how the format-neutral model is projected into the chosen store, treating that projection as encoding rather than semantics.", "Read the interface document for operation bindings, concurrency tokens, idempotency keys and error semantics.", "Read the processes document last for lifecycle, reconciliation, disclosure and disposition procedures, and resolve every required referenced model before attempting any write." ] } }, "coverage": { "claim": "Bounded adversarial audit of the merged three-pass Claude result for WM-PER-010 against its own 39 declared source records, the frozen vr.wm-per-010 registry entry, an empty relationship contract, an empty legacy source and its stated omissions. Examined: contact-point identity and party binding, typed endpoints and internationalization, carried verification, validity/reachability/supersession, preference declaration, availability and routing, precedence, and governance covering authority, provenance, lifecycle, quality, disclosure, retention and the service contract. No claim of universal completeness is made: six checklist dimensions remain self-declared gaps, eighteen omissions are declared, the WM-XCT-024 ownership conflict is unresolved, several load-bearing constructs have no primary support, and no independent second-provider review exists.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Contact-point identifier separated from endpoint value, with issuing system, scheme and stability questions; identity priority places the master-system identifier first and explicitly bars values and dates. Grounded in JSContact uid/Id keys and vCard UID/PID." }, { "dimension": "relationships", "status": "covered", "notes": "Owning-party binding, shared and delegated use, role-based holding, postal location reference, evidence locators and the supersession predecessor/successor chain are all modelled as references with explicit ownership boundaries." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments recorded for E.164/E.123/RFC 3966, RFC 5321/6068/6530/5890, RFC 3986, RFC 9553, RFC 6350, W3C vCard Ontology, schema.org ContactPoint, UPU S42 and CPOV, with the schema.org one-to-many mismatch flagged rather than smoothed over." }, { "dimension": "internationalization", "status": "covered", "notes": "NFC, A-label/U-label pairing, UTF-8 mailboxes with no required ASCII fallback, percent-encoded URI carriage, localized variants by locale key and recorded transliteration authority." }, { "dimension": "classification", "status": "covered", "notes": "Three orthogonal axes separated: medium/scheme, purpose context, and technical capability, each bound to an external code list rather than a local enumeration, with an explicit ambiguity-resolution question." }, { "dimension": "verification and assurance", "status": "covered", "notes": "Assertion carried with authority, method class, assurance level, dual timestamps, expiry and evidence locator; execution, evaluation and audit remain in the referenced proofing model. Grounded in OpenID Connect verified claims and NIST SP 800-63A-4." }, { "dimension": "reachability and supersession", "status": "gap", "notes": "Modelled as a derived status plus evidence locator and an ordered acyclic chain, but neither concept is defined by any cited contact standard; the boundary against delivery-attempt logs is asserted by design rather than by an external normative rule." }, { "dimension": "accessibility", "status": "covered", "notes": "Functional accommodation directives with required channel capabilities and a mandatory unsatisfiable-directive action, grounded in AccessForAll and the textphone and relay capability values registered by IANA and schema.org." }, { "dimension": "language and locale", "status": "covered", "notes": "BCP 47 tags with modality, context and order, the Suppress-Script omission rule, declared fallbacks, and an explicit boundary excluding number and date formatting conventions." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Party-side preference needs only a time-zone frame; geographic service area exists in schema.org for organisation contact points but belongs to the channel or organisation model, not to a party's preference statement." }, { "dimension": "conflict and precedence", "status": "covered", "notes": "A published, versioned precedence ruleset with monotonic narrowing, external-restriction supremacy and a fail-closed unresolved outcome, patterned on RFC 7953 priority resolution." }, { "dimension": "urgency and escalation", "status": "gap", "notes": "No primary, sector-neutral standard defines urgency tiers for party contact preference. CAP v1.2 supplies an alert-oriented vocabulary used strictly as an alignment candidate, so the tier set is a designed construct requiring Dimension-level definition." }, { "dimension": "contact-avoidance semantics", "status": "gap", "notes": "vCard, JSContact, FHIR and schema.org define no advisory, non-legal contact-avoidance construct distinct from a legally governed restriction. The finding is a designed construct, defensible from the absence of coverage in those standards but not directly attested by any of them." }, { "dimension": "lifecycle", "status": "covered", "notes": "A closed state set with permitted transitions, triggers, effective dating and supersession is defined in cp-gov-finding-lifecycle-versioning and operated by cp-gov-fn-transition-lifecycle-state and cp-gov-fn-dispose-or-tombstone." }, { "dimension": "temporal", "status": "covered", "notes": "Valid time is separated from record time; event, observation and ingestion times are distinct fields; all times use RFC 3339 with seconds and an explicit offset or Z, and unqualified local time is rejected." }, { "dimension": "provenance", "status": "covered", "notes": "cp-gov-finding-assertion-provenance aligns to PROV-O agent, activity and entity patterns with derivation, attribution and reliability grading; reconciliation and supersession preserve prior assertions." }, { "dimension": "ownership", "status": "covered", "notes": "Authoritative system of record, authority ranking, steward assignment, controller and processor roles, and ownership transfer with a preserved responsibility chain are all modelled, with owner-package requirements in the dimension layer." }, { "dimension": "validation", "status": "covered", "notes": "Validation rules with severity and versioning, canonical normalisation preserving the original input, match thresholds, survivorship rules and reversible merges are defined and operated by cp-gov-fn-reconcile-contact-points." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with role and purpose declaration, published projection profiles, four access scopes, five exception classes including break-glass and protection flags, and audit requirements covering refusals as well as grants." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Tombstoning is the default, physical erasure requires an instruction or an elapsed schedule with no hold, a disposition certificate is produced, and the retention schedule, disposition authority and legality of erasure are explicitly owned by the referenced retention model or the adopting Dimension." }, { "dimension": "security", "status": "covered", "notes": "A secret-exclusion policy bars one-time codes, challenge secrets, tokens, message content and complete consent evidence; patch payloads carrying them are rejected before evaluation, and problem objects are constrained not to leak withheld detail." }, { "dimension": "measurement", "status": "covered", "notes": "Quality dimension scores, match scores and thresholds, reachability confidence, age and consecutive-failure thresholds are all first-class, using the UK Government Data Quality Framework dimension vocabulary." }, { "dimension": "authority", "status": "covered", "notes": "Mandate type, scope, expiry and revocation are modelled separately from the external authorisation decision reference, and cp-gov-fn-resolve-assertion-authority explicitly disclaims policy evaluation." }, { "dimension": "exception handling", "status": "covered", "notes": "Verification failure, merge reversal, compromise, retention conflict and refused disclosure each have a dedicated question and defined non-revealing error semantics." }, { "dimension": "channel taxonomy and preference semantics", "status": "not-applicable", "notes": "Assigned to the sibling split of WM-PER-010 covering channels and preferences; this pass references channel type and preference fields without defining their taxonomy or ordering rules." }, { "dimension": "jurisdictional variation", "status": "gap", "notes": "Only EU (GDPR, EDPB) and US telephone (FCC reassigned numbers) duties were researched as worked examples; equivalent duties in other jurisdictions are asserted as overlay slots rather than enumerated." }, { "dimension": "accessibility and language preference", "status": "gap", "notes": "Language and accessibility-driven channel preference is in scope for the combined model but has no governance finding here and no primary source was gathered for it in this pass." } ], "known_omissions": [ "No accessibility-channel modelling (relay services, textphone routing beyond the vCard textphone capability code, sign-language video relay) is developed, though schema.org contactOption and vCard TYPE hint at it.", "Emergency-contact and next-of-kin arrangements, where the contact point reaches a different party than its subject, are only partially covered by the shared-use and care-of elements.", "Number portability, carrier reassignment feeds and domain expiry monitoring as triggers for reachability or supersession are referenced conceptually but not modelled.", "Device and application endpoints (push tokens, device identifiers) are admitted only via the generic online-service shape; their distinct rotation and revocation semantics are not developed.", "ISO 19160-1 could not be retrieved (iso.org returned HTTP 403), so the address conceptual model and its address lifecycle are cited only indirectly through UPU S42.", "Frequency capping and quiet-hour enforcement across a whole programme are not modelled; only the party's stated spacing preference is carried, and enforcement is external.", "Organisation-side routing rotas, on-call schedules and queue assignment are not modelled; this area covers a party's stated preference, not a service desk's staffing.", "Inbound contact handling, meaning how the party's own inbound requests are queued or triaged, is not modelled beyond stated windows.", "Verification of a delegate's identity or mandate is referenced but not modelled; the authority record lives elsewhere.", "No mapping table is provided from purpose classes to jurisdiction-specific marketing or solicitation categories, which would import a regional rule into a neutral schema.", "Cost, carrier economics and channel reliability metrics that a sender might weigh alongside preference are out of scope.", "Deceased-party, minor and guardianship handling is only partially covered by the mandate finding; jurisdiction-specific rules for post-mortem contact data were not researched.", "No verified primary source was obtained for shared or role-based organisational mailboxes, which have no single data subject and sit at the boundary with the party model.", "Machine-readable retention schedule vocabularies beyond NARA's requirement groups were not evaluated, so the retention schedule reference remains an opaque link.", "The FCC public notice PDF (SRC-039) could not be text-extracted during this pass; the 47 CFR 64.1200(m) safe-harbour wording was corroborated from summaries of FCC-published material rather than re-read verbatim, so it is treated as supporting rather than load-bearing evidence.", "ISO 15489-1 and ISO/IEC 25012 pages returned HTTP 403, so records-management and data-quality grounding rests on NARA and the UK Government Data Quality Framework instead.", "Cross-border transfer, data-localisation and sub-processor governance are left entirely to the adopting Dimension's transfer model and are not modelled here." ], "conflicts": [ "Registry duplication: WM-XCT-024 Contact Point and WM-PER-010 both claim the contact-point concept. The cited vocabularies define one such concept, so the registry must resolve which model owns it; recorded as a conflict and a boundary note rather than a relation.", "RFC 5321 requires mailbox local-parts to be treated as case sensitive and their case preserved, while the same RFC notes that exploiting case sensitivity impedes interoperability and is discouraged. Widespread practice lowercases whole addresses. This model follows the normative rule and treats whole-address folding as a defect, which will conflict with many deployed systems.", "RFC 6530 removes the requirement for an all-ASCII alternate address for internationalized email, but many downstream systems still demand one. Any recorded ASCII fallback is therefore an optional, separately sourced assertion with a named asserting party, not an equivalence guaranteed by the standard.", "schema.org ContactPoint aggregates telephone, email and fax on a single node, whereas JSContact, vCard and this model hold one typed endpoint per object. Export is one-to-many and lossy in round trip; the mismatch is documented rather than resolved by merging.", "The W3C vCard Ontology is an Interest Group Note from 2014 and is not a Recommendation; it is used as an RDF alignment only and must not be cited as normative.", "No cited standard defines a validity interval, lifecycle state or supersession chain for a contact point. These are the model's most load-bearing extensions and rest on primary support only for the identity separation that makes them possible.", "ITU-T E.164 (02/26) is the in-force edition, but the ITU-hosted full text available for verification is the 05/97 edition. The 15-digit maximum and CC/NDC/SN structure are cited from the verified 05/97 text; if the 2026 edition altered them, those specific constraints would need revalidation.", "vCard and JSContact define pref as interpretable only relative to other instances of the same property in the same card, while FHIR ContactPoint.rank orders a set of contact points. A naive round trip between them silently changes the comparison scope, so this model records the comparison scope explicitly.", "RFC 7953 defaults time inside a VAVAILABILITY that no AVAILABLE component covers to busy, whereas schema.org hoursAvailable publishes open hours with no normative default for uncovered time. The two conventions imply opposite defaults, so the uncovered-time disposition is a required declared element here.", "RFC 7953 PRIORITY treats 1 as highest with absence or 0 as lowest, while vCard PREF treats 1 as most preferred with absence as least preferred. Both invert ordinary intuition in different ways and must never be merged into a single numeric field.", "schema.org ContactPointOption offers only TollFree and HearingImpairedSupported, far narrower than functional AccessForAll directives; mapping from directives to that enumeration is lossy in one direction and must not be reversed.", "The 1EdTech AccessForAll PNP v2.0 information model expresses language preference with ISO 639-2 codes, while vCard, JSContact and schema.org require BCP 47. Codes must be converted with an explicit mapping, never copied across.", "JSContact defines pref as an unsigned integer where a lower value means higher preference, while many deployed systems treat a higher number as stronger preference; every crosswalk profile must state the direction explicitly or preference order will invert silently on exchange.", "vCard's REV carries a single revision timestamp and has no concept of valid time versus record time, so bitemporal history cannot round-trip through vCard without documented loss.", "GDPR Article 17 erasure can conflict with statutory retention duties and with telecom record-keeping expectations; this model records the conflict, the citation and the deciding authority rather than encoding a resolution.", "schema.org ContactPoint is organisation-facing and carries no verification, provenance or permission semantics, so the relationship is partial alignment and must never be presented as conformance.", "ISO/IEC TS 27560 leaves most consent-record fields implementation-defined and requires only a receipt identifier and schema version, so the presence of a consent reference is not by itself evidence of a lawful basis; the schema version must be recorded alongside every reference.", "NIST SP 800-63A treats an address of record as an identity-proofing channel, a narrower purpose than general reachability; its assurance levels do not transfer automatically to service or marketing contact use.", "RFC 9110 concurrency and idempotency semantics are defined for HTTP, whereas this model is interface-neutral; they are adopted as semantic patterns, and a non-HTTP projection must supply equivalent strong-comparison and replay guarantees rather than claim the RFC's status codes." ], "regional_assumptions": [ "E.164 global-number form is assumed available for most telephone endpoints; closed numbering plans, short codes, emergency numbers and PBX extensions require the phone-context mechanism and are treated as local numbers.", "Postal delivery assumes UPU member-country templates exist for the country code recorded; informal, descriptive or unaddressed locations common in some regions may have no template and will fall back to captured full text held as provenance only.", "ISO 3166-1 alpha-2 is assumed sufficient for the postal country binding; disputed, non-listed or sub-territorial designations are not resolved by this model.", "Internationalized email support is assumed possible but not universal; a given endpoint may be unreachable from ASCII-only infrastructure, which is a reachability fact rather than a validity fact.", "Access defaults are stated as deny-by-default with purpose scoping; the specific legal grounds, notification duties and erasure obligations vary by jurisdiction and are deliberately delegated to the adopting Dimension and the consent model.", "Marketing and solicitation rules, statutory quiet hours and emergency-number routing are jurisdiction-specific. They are treated as profile-conditional inputs resolved by the external restriction registry and are deliberately not encoded as schema invariants.", "The window model assumes the Gregorian calendar and IANA time-zone identifiers; expressing windows in alternative calendar systems is not modelled.", "A single authoritative external communication-restriction registry per Dimension is assumed. A party subject to several jurisdictions may resolve to more than one, and aggregation across multiple registries is undefined in this area and must be settled by the governance area.", "Rules for contacting minors, vulnerable persons and people at their workplace vary by jurisdiction and sector, so they are recorded as explicit flags rather than as behaviour built into the resolver.", "Relay and textphone service availability, and the accessibility obligations attached to them, differ by country; capability codes are carried, but no obligation is asserted.", "EU and EEA duties (GDPR principles, rectification, erasure, objection to direct marketing, protection by design and by default) are treated as the baseline for consent linkage, minimisation and disposition.", "US telephone-specific duties, notably reassigned-number checking keyed to the date permission was obtained, are treated as a jurisdiction-scoped overlay applied per endpoint, never as a global default.", "UK Government Data Quality Framework dimension definitions are used as descriptive vocabulary for measurement, not as a legal requirement in any jurisdiction.", "No assumption is made about data-localisation or cross-border transfer regimes; the adopting Dimension must bind these to its own transfer model before adoption.", "Postal, telephone and messaging identifier formats are assumed to be normalised against international numbering and addressing standards, whose applicability varies by country and is recorded per normalisation algorithm version." ], "adversarial_checks": [ "Ownership test against every relation rationale: no bundle, layer, finding or function performs verification, evaluates assurance, executes delivery, enforces access or writes an audit trail. Verification and reachability findings carry assertions and locators only; the delete rules and audit requirements explicitly name the audit model and the adopting Dimension as owners of execution.", "Duplication test against the party model: no finding carries a party name, legal identifier, birth data or matching rule. Party binding is a reference tuple with an inline-only rationale stating why no local party artifact exists.", "Duplication test against the address model: the postal finding was rejected as an artifact-bearing finding because its structured components belong to UPU S42 templates and the address model; only delivery-role attributes and a reference remain.", "Counterexample search on normalization: the attractive but wrong rule 'lowercase the whole email address' was rejected against RFC 5321's MUST on local-part case sensitivity, and the equally attractive 'store the number as typed' was rejected against RFC 3966's separator-insensitive comparison requirement.", "Counterexample search on identity: endpoint values were tested as natural keys and rejected, because carriers reassign E.164 numbers and providers recycle mailboxes, so value equality would silently transfer verification assertions between parties.", "Unsupported-structure test: every finding was checked for a citation that actually covers its claim. Validity, lifecycle, supersession and reachability failed that test and are marked gaps in the checklist and conflicts rather than presented as standards-backed.", "Preference-leakage test: the resolve function was scoped to supersession traversal and canonical dereferencing only, with an explicit effect stating that preference ranking and channel selection belong to the preferences layer, so this pass does not colonize the adjacent split area.", "Attempted to make the resolver produce a usable plan when the external restriction reference is unreachable. Rejected: unresolved is the only outcome, it is stated in the function effects, in the fail-closed policy and in the integrity rule, and no bundle, layer, finding or function contains a permissive fallback.", "Attempted to model the legally governed restriction locally under a preference-sounding name. Rejected: only a resolvable reference and a resolution status are carried, the record content is never exposed at any access scope, and creation, deletion and patch rules all forbid touching the external registry.", "Attempted to attach delivery outcomes, retry state, bounce handling and audit trails to the attempt-order finding. Rejected: attempt ordering is a stated preference and the fallback trigger is explicitly evaluated by the sending system, which owns its own logs; the explain function is stated not to be an audit record.", "Tested whether a high urgency tier could override an active external restriction. Rejected: urgency may override only the party's own windows and avoidance statements, and the constraint question, the override-allowance element and the resolver effects all state that the external restriction takes precedence.", "Checked whether an endpoint address, party name or message content leaked into any finding or data element. None do: every such value is carried as a reference to the channel area, the party model or the message model.", "Checked whether accessibility directives could imply a diagnosis. They are expressed functionally per AccessForAll, a dedicated privacy question forbids diagnostic vocabulary, and disclosure to a channel provider is limited to the required capability.", "Searched vCard, JSContact, FHIR R5 and schema.org for a primary definition of an advisory, non-legal contact-avoidance preference and of party-contact urgency tiers. Neither exists; both are recorded as coverage gaps and as designed constructs rather than presented as canonical.", "Checked every finding and function against the composition contract for consent: cp-gov-finding-permission-linkage and cp-gov-fn-bind-permission-reference hold only reference, scope, purpose, schema version and validity, and an explicit question enumerates what must never be copied. No consent artifact is declared here.", "Checked that no function evaluates or stores authorisation policy: cp-gov-fn-resolve-assertion-authority records an externally rendered decision reference and blocks on its absence, and the authorisation model is a required REFERENCE with evaluation reserved to the target.", "Checked that audit-trail semantics are not absorbed: mutations emit a change signal and retain a returned audit event reference only, the service-contract finding is inline-only for that reason, and access.audit_requirements explicitly forbids this model being the sole holder or mutator of audit evidence.", "Checked that verified control never implies permission and permission never implies reachability, via a dedicated question (cp-gov-q-verification-not-permission), a stated policy, and a precondition rule requiring both states independently.", "Tested the rule that a date is not an identifier against all six artifact identity strategies, the serial naming rule and every local ID; timestamps and version numbers appear only as attributes.", "Searched for a counterexample where a contact point has no single owning party, such as a shared organisational mailbox, and recorded it as an unresolved boundary against the party model rather than modelling role-based mailboxes locally.", "Verified that the deletion rules name an external owner of retention execution and legal-hold adjudication, and that cp-gov-fn-dispose-or-tombstone suspends rather than resolves a retention conflict.", "Checked that no finding redefines channel taxonomy or preference ordering, which belong to the sibling split; channel type and preference appear only as referenced fields.", "Rejected an attractive but unsupported single endpoint trust score aggregating verification, consent and quality, because it would collapse the proof-versus-permission separation the primary sources require; confidence is scoped to reachability only.", "Re-read every bundle, layer, finding and function against each composition rationale and moved delivery telemetry, incident investigation, breach notification, credential lifecycle and schedule authoring into out_of_scope or boundary_notes rather than modelling them locally." ] }, "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": "aggregate", "status": "reclassified", "rationale": "Two axes must be kept apart. On the record plane the frozen registry files vr.wm-per-010 as record_plane world-model with entry_kind mixin; that value describes how the record is catalogued and reused across party models, and it governs the registry record, not the ontology of the subject. On the subject-model axis the delivered content does not behave as a mixin. The contact point carries its own master-system identifier explicitly decoupled from the endpoint value, a closed lifecycle state set with permitted transitions, separated valid time and record time, an opaque version token for optimistic concurrency, supersession chains, tombstones, disposition certificates, purpose-scoped disclosure projections and a complete create/read/update/delete/export service contract with idempotency keys and atomic patch semantics. Preference statements independently carry identity, effective intervals, temporary overrides, supersession and provenance. A trait bundle injected into a host model owns none of these: it does not own a transaction boundary, it does not issue disposition certificates, and it is not the subject of an access projection. The consistency boundary that all of this actually operates over is the party-scoped Contact Profile, which holds contact points, preference statements and carried assertions as members while referencing the party rather than containing it, exactly as the boundary note against WM-PER-001 requires. The most defensible schema kind is therefore aggregate, with the Contact Profile as aggregate root. Reusability into any party model is preserved as an attachment/reference relation rather than as a mixin classification, so nothing in the stated purpose is lost by the reclassification. The registry entry_kind value must be re-frozen by the registry owner; this audit does not clear it unilaterally." }, "decisions": [ { "concept": "Subject-model entry kind frozen as mixin", "disposition": "reclassified to aggregate", "rationale": "The delivered record owns record identity, a closed lifecycle, concurrency tokens, supersession, disposition certificates and a full CRUD/export contract. A trait bundle mixed into a host owns none of these. The registry value describes record-plane reuse, not subject ontology, so the two axes are reported separately rather than collapsed." }, { "concept": "Aggregate root identification", "disposition": "accepted with amendment: Contact Profile named as root", "rationale": "No root is named anywhere in the pack, yet the service contract, access projections, retention rules and integrity digests all presuppose exactly one consistency boundary. The party-scoped Contact Profile is the only candidate that holds both contact points and party-level preference statements; the party itself is referenced, never contained, per the WM-PER-001 boundary note." }, { "concept": "Duplicate verification findings across the channel and governance passes", "disposition": "merged into one carried-assertion finding", "rationale": "cp-chan-f-verification-assertion and cp-gov-finding-control-verification model the same proof-of-control outcome with overlapping questions and two competing artifacts (cp-chan-a-verification-assertion and cp-gov-artifact-verification-attestation). Shipping both creates two records of one assertion and two identity strategies for the same evidence." }, { "concept": "Duplicate validity, lifecycle and supersession findings", "disposition": "merged under cp-gov-finding-lifecycle-versioning", "rationale": "cp-chan-f-validity-interval and cp-chan-f-supersession restate valid-time, state-set and replacement-chain semantics already governed by the governance pass, which additionally carries record time and version tokens. Two lifecycle definitions inside one aggregate will diverge and the pack already flags both as unsupported extensions." }, { "concept": "Duplicate write functions across passes", "disposition": "collapsed into single write paths", "rationale": "cp-chan-fn-register-endpoint duplicates cp-gov-fn-assert-contact-point, cp-chan-fn-attach-verification-assertion duplicates cp-gov-fn-record-control-verification, and cp-chan-fn-supersede-endpoint is a special case of cp-gov-fn-transition-lifecycle-state. Retaining six functions offers two write paths with different provenance and validation obligations for the same state change." }, { "concept": "Endpoint value objects declared as artifacts", "disposition": "rejected as artifacts, demoted to inline typed value structures", "rationale": "cp-chan-a-telephone-endpoint, cp-chan-a-email-endpoint and cp-chan-a-uri-endpoint hold no identity of their own, borrowing the parent contact-point identifier, yet artifact_rules.integrity_rule would oblige every stored telephone number to carry a digest, algorithm identifier, generating function and responsible agent. They are value structures, not deliverables." }, { "concept": "cp-chan-a-contact-point-record classified as an artifact", "disposition": "rejected as artifact, retained as the aggregate's member entity", "rationale": "The contact-point record is the governed thing, not an output the model produces. Classifying the entity as an artifact makes the never-mutate-in-place and quarantine rules apply to live master data, which directly contradicts the update and governed-patch rules that mutate that record under a version token." }, { "concept": "Composite identifier for cp-chan-a-supersession-link", "disposition": "rejected, independent opaque identifier required", "rationale": "Deriving the link identifier from the predecessor's master-system identifier plus a chain sequence number breaks the artifact rule that identifiers remain stable across renames, re-issues and format migrations, and couples a relationship record's identity to a record it may outlive or that may be re-keyed on migration." }, { "concept": "cp-gov-artifact-authority-mandate materialised locally", "disposition": "rejected, demoted to a resolvable reference with scope and validity", "rationale": "cp-pref-finding-delegate-alternate states in its own inline rationale that mandates and powers of attorney are evidence objects owned by another model, and the reference-not-replication policy forbids holding target content. Court orders and guardianship instruments cannot take custody here without contradicting both." }, { "concept": "Duplicate source registration of RFC 6350", "disposition": "collapsed, SRC-018 folded into SRC-010", "rationale": "SRC-010 and SRC-018 are the identical specification registered under two identifiers and two URLs, so the declared count of 39 sources overstates distinct evidence. Citations split across the pair read as two witnesses to a claim supported by one document, which weakens rather than corroborates it." }, { "concept": "schema.org source tiering and version characterization", "disposition": "normalization required before the source table is published", "rationale": "SRC-013 records v30.0 dated 2026-03-19 as a development version at authority tier 3 while SRC-022 records the same v30.0 release at tier 2. One publisher and one release cannot hold two tiers or two release states, and both citations feed the classification and accessibility findings." }, { "concept": "Coverage checklist staleness after the three-pass merge", "disposition": "checklist rewritten against merged content before publication", "rationale": "The dimension channel taxonomy and preference semantics is marked not-applicable as belonging to a sibling split, and accessibility and language preference is marked a gap with no source gathered, yet the merged pack contains both bundles and cites SRC-020, SRC-022 and SRC-026 for them. The coverage record contradicts the delivered structure." }, { "concept": "Exactly-one-owning-party invariant versus shared endpoints", "disposition": "accepted, with shared use retained as a separate typed relation", "rationale": "in_scope asserts binding to exactly one owning party while cp-chan-q-party-shared asks whether an endpoint may be shared by more than one. Both survive only if ownership is single-valued and shared or delegated use is a distinct relation. The shared organisational mailbox case stays a declared open boundary against the party model." }, { "concept": "Tombstone persistence versus erasure duty", "disposition": "accepted with a required retention ceiling and pseudonymisation step", "rationale": "The delete rules keep a tombstone resolvable while inbound references exist and dispose it under the same external schedule, which admits an unbounded lifetime for an identifier still linked to a party and therefore still personal data. A ceiling and a de-linking rule must be stated rather than left implied by the referenced schedule." }, { "concept": "Access scopes expressed in record-plane terms", "disposition": "deferred, subject-data projection scopes required from the owner package", "rationale": "The declared scopes bundle, layer, finding and artifact describe the research record structure, not the governed contact data; a requester needs party, contact point, field and purpose scopes. The mapping between the two planes is undefined in the pack and cannot be invented by this audit without adding facts." }, { "concept": "Load-bearing constructs with no primary source support", "disposition": "accepted as declared adopting-Dimension extensions, visibly labelled", "rationale": "Validity interval, lifecycle state, supersession chain, reachability status, urgency tiering and advisory contact avoidance are defined by no cited contact standard, as the pack itself records in its conflicts and gap entries. They may ship in a draft only while the non-standards-backed label travels with each of them." }, { "concept": "Self-audit claims citing function effects that were not delivered", "disposition": "claims narrowed to what the delivered record contains", "rationale": "Several adversarial_checks entries assert a constraint is stated in the function effects or in stated effects, but the delivered function records carry only id, name, description and source_refs. The verification claim exceeds the evidence; the effects must be materialised or the corresponding self-audit assertions withdrawn." }, { "concept": "Purpose vocabulary fragmentation across passes", "disposition": "unified under one governed purpose taxonomy", "rationale": "cp-chan-f-purpose-and-capability carries a purpose and usage context, cp-pref-finding-applicability-scope carries a purpose class and context, and cp-gov-finding-permission-linkage carries purpose codes. The dimension layer promises a single governed purpose taxonomy, so three parallel vocabularies must not ship in one aggregate." } ], "publicationHolds": [ "Live source and version verification is outstanding and blocks publication of the source table as settled evidence: the in-force ITU-T E.164 (02/26) text was never read and the 15-digit maximum plus CC/NDC/SN structure rest on the verified 05/97 edition; SRC-039's FCC PDF could not be text-extracted; SRC-012 cites a UPU programme landing page rather than the S42 normative text; SRC-037 exposes only an ISO catalogue abstract; and the IANA tzdb pin (2026c, 2026-07-08) and the schema.org v30.0 characterization must both be re-resolved at publication time.", "No independent second-provider review exists. The repository owner waived Grok on 2026-08-29T09:06:27Z after repeated structured-output failures, so this is a Claude-only result audited by a single no-tools adversarial pass. The waiver, its authorizer, its date and its reason must be visible on every published artifact, and the record must remain a reviewable draft rather than an adopted model.", "The frozen registry entry vr.wm-per-010 still carries status candidate and review_state boundary-review-required, and the WM-XCT-024 versus WM-PER-010 contact-point ownership conflict is unresolved. Neither may be silently cleared by this synthesis; the boundary note must be published in place of any frozen relation.", "The relationship contract is empty while the model asserts required bindings to at least nine external models (party, postal address/place, consent and legal basis, communication-restriction registry, authorisation decision, audit-record, retention and disposition, communication-event and incident). The model's own owner-package rule states that an unbound required reference blocks promotion beyond candidate status.", "The entry-kind reclassification from mixin to aggregate changes a frozen registry value and must be reviewed and re-frozen by the registry owner before adoption. Publication must display both the registry-plane value and the audited subject-model kind so no reader mistakes the audit for a registry change.", "Duplicate source registration of RFC 6350 as SRC-010 and SRC-018, and the inconsistent authority tiering and release characterization for schema.org across SRC-013 and SRC-022, must be corrected before the 39-source count or any per-claim citation density is presented as evidence of coverage.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Registry adjudication of whether WM-PER-010 or WM-XCT-024 owns the contact-point concept, and whether that resolution forces a split of this aggregate into a channel/endpoint model and a separate party preference profile.", "A verified primary source for shared and role-based organisational mailboxes and functional contact points that have no single data subject, which currently sit unresolved on the boundary with the party model.", "A sector-neutral primary standard for party-contact urgency tiering and for an advisory, non-legal contact-avoidance construct; CAP v1.2 is an alert vocabulary carried only as an alignment candidate and cannot ground either.", "Retrieval of ISO 19160-1, ISO 15489-1, ISO/IEC 25012 and the UPU S42 normative text through an accessible channel, to replace the indirect grounding currently carried by NARA, the UK Government Data Quality Framework and a UPU programme landing page.", "Accessibility channel modelling beyond carried capability codes: relay services, textphone routing and sign-language video relay, including whether the resulting obligations attach to the contact profile or to the sending system.", "Jurisdictional overlays outside the EU and US-telephone worked examples, covering marketing and solicitation restriction, statutory quiet hours, reassigned-number equivalents, and post-mortem, minor and guardianship handling of contact data.", "Rotation and revocation semantics for device and application endpoints such as push tokens and device identifiers, which are currently admitted only through the generic online-service shape and lack distinct lifecycle rules.", "Machine-readable retention schedule vocabularies beyond NARA's requirement groups, so that the referenced retention schedule stops being an opaque link and the disposition path becomes independently checkable." ] }, "statistics": { "sources": 39, "bundles": 9, "layers": 20, "findings": 39, "questions": 173, "artifacts": 14, "functions": 21 } }