Contact Point / Party Profile

Contact-point identifier distinct from endpoint value

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.

1. Which system of record assigns the authoritative identifier for this contact point, and does that identifier remain stable when the endpoint value changes? identity
2. Is the contact-point identifier globally resolvable, or unique only within the owning party's record? interoperability
3. What distinguishes the contact-point record identity from the endpoint value that natural-key strategies would otherwise use? definition
4. How are two contact-point records that normalize to the same endpoint value for the same party reconciled? constraint

Owning-party reference and mixin attachment

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.

1. Which party does this contact point belong to, and under which identifier scheme is that party referenced? ownership
2. Can this endpoint be shared by more than one party, and how is shared or delegated use represented? relationship
3. Who is authorized to add, change or retire a contact point on behalf of the owning party? authority
4. Is this contact point held for a role or function rather than for a named natural person, and how is that flagged? classification

Endpoint kind and addressing scheme

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.

1. Which addressing scheme governs the syntax of this endpoint value, and which specification defines that scheme? classification
2. Is the endpoint kind derivable from the value itself, or must it be declared independently of the stored value? definition
3. Which code list is authoritative for endpoint kind, and how are emerging or unregistered channel types admitted? interoperability
4. 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? exception

Purpose context and channel capability

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.

1. For which use contexts or business purposes is this endpoint intended, and are multiple contexts simultaneously applicable? classification
2. Which technical capabilities does the endpoint support, and were those capabilities declared by the party or observed by a system? quality
3. Does recording a purpose context here imply any permission to contact the party for that purpose? constraint
4. Which geographic or linguistic service scope applies to this contact point? spatial

Telephone endpoint canonical, URI and display forms

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.

1. Is the stored number a global E.164 number, or a local number that requires a phone-context to be unambiguous? constraint
2. What is the canonical machine form of this telephone endpoint, and which characters are significant when two numbers are compared? validation
3. How is the human-readable display form derived, and which notation standard governs its spacing and symbols? interoperability
4. How are extensions, dialling prefixes and subaddresses represented without corrupting the canonical number? requirement

Email mailbox endpoint and normalization limits

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.

1. Which portion of this mailbox may be case-folded during normalization and which portion must be preserved exactly as supplied? validation
2. Does this mailbox contain non-ASCII characters in the local part, in the domain, or in both? classification
3. Is an ASCII fallback address recorded, and on whose authority is it treated as equivalent to the internationalized address? exception
4. How is the domain part recorded when both A-label and U-label forms exist for the same name? interoperability

Web URI and online-service endpoint

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.

1. Which URI scheme and authority identify this endpoint, and is the recorded URI absolute rather than relative? identity
2. Which normalization steps may be applied before two URI endpoints are treated as equivalent? validation
3. When a messaging handle is recorded without a resolvable URI, which service identifier disambiguates the handle? composition
4. Does this endpoint address the party directly, or a publicly readable profile that third parties also observe? privacy

Postal delivery endpoint reference and delivery role

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.

1. Which addressed location does this postal contact point designate, and by which reference is that location identified? composition
2. Which country template and postal component set govern rendition of this address for delivery? interoperability
3. Which delivery-specific attributes belong to the contact point rather than to the location itself? definition
4. Is the delivery point a place the party occupies, or purely a mail-receipt arrangement such as a box or forwarding agent? classification

Script, normalization and localized forms

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.

1. Which Unicode normalization form is required before an endpoint value is stored or compared? validation
2. Which language tag applies to the human-readable label for this endpoint? classification
3. How are localized alternative forms of one endpoint recorded without creating duplicate contact points? composition
4. Which script or transliteration variant is authoritative when a source system supplies more than one? authority

Carried verification assertion for endpoint control

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.

1. Which authority asserted that the owning party controls this endpoint, and at what instant was the assertion made? provenance
2. Which verification method class and assurance level does the assertion claim? evidence
3. Does the assertion expire, and which events invalidate it before its stated expiry? temporal
4. Which system executed the proofing challenge, and where is the audit record of that execution held? security

Validity interval and lifecycle state

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.

1. From which instant until which instant is this contact point valid for use by the owning party? temporal
2. Which lifecycle state does the contact point currently hold, and which state transitions are permitted from it? lifecycle
3. Is a recorded end date an assertion of past fact or a scheduled future change, and how is a still-open interval represented? state
4. Are there recurring windows within the validity interval during which the contact point is available or restricted? requirement

Operational reachability status

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.

1. What is the last recorded reachability status of this endpoint and at which instant was it observed? measurement
2. Which evidence supports the recorded reachability status, and in which model is that evidence held? evidence
3. Does an unreachable status invalidate the contact point, or only suppress its operational use? decision
4. Who may set or override reachability status, and may it be set without an underlying observation? process

Supersession and replacement chain

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.

1. Which contact point replaces this one, and from which effective instant does the replacement apply? relationship
2. Is a superseded contact point retained for historical interpretation, or disposed once the successor is active? retention
3. How is a supersession chain traversed to obtain the currently effective endpoint for a historical reference? process
4. What prevents a supersession cycle or a fork with two concurrent successors? constraint

Preference applicability scope: purpose class, context and capacity

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.

1. Which communication purpose classes does this statement govern, and is the class list closed or extensible? classification
2. Which usage context qualifies the statement, and what does an absent context mean? definition
3. How is an inbound contact request handled when it declares no purpose class at all? exception
4. Which capacity does the statement cover when the same party acts as customer, employee and emergency contact? relationship
5. Which profile-conditional situations must be recorded explicitly instead of being inferred as defaults? requirement

Preferred channel modality and relative preference ordering

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.

1. Which channel kinds are declared preferred within this scope, and how is the preference value expressed numerically? definition
2. What does an absent preference value mean, and may a single valued instance be read on its own? constraint
3. Are preference values comparable between different channel kinds, or only within the same kind? measurement
4. Which channel-kind or endpoint reference does the statement point to, and how is a reference that no longer resolves treated? relationship

Party-stated contact-avoidance preference

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.

1. Which combination of channel, purpose, context and time does the party ask to avoid, and at what precision is that combination stated? definition
2. How is this advisory statement distinguished in data from the legally governed restriction record held in the external registry? authority
3. Can this statement ever widen the set of permitted options relative to an external restriction? decision
4. What firmness does the party attach to the request, and how is that recorded without implying legal weight? quality
5. For how long does the request stay effective, and does it expire by default? temporal

Language, script and locale preference for communication

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.

1. Which language tags does the party prefer for written and for spoken interaction, and in what order? classification
2. When must a script subtag be carried on a preference tag, and when should it be omitted? constraint
3. Does the language preference differ by usage context, and how are competing per-context orders reconciled? composition
4. What is the correct behaviour when no preferred language can be produced on the selected channel? exception
5. Which locale formatting conventions travel with a language preference, and which stay with the rendering system? interoperability

Accessibility accommodation directive for contact

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.

1. Which functional accommodation directives apply to communication with this party, inbound and outbound? requirement
2. How is the directive expressed so that it states a functional need without disclosing or implying a diagnosis? privacy
3. Which channel capabilities must a candidate option possess before the directive counts as satisfiable? validation
4. What must happen when no available channel can satisfy the accommodation directive? exception
5. Which record is the authoritative source of this directive when an external accessibility profile also exists? provenance

Time-zone reference and temporal frame

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.

1. Which time-zone identifier governs interpretation of this party's stated windows? temporal
2. Why is a fixed UTC offset insufficient for a stated window, and in which narrow case may one still be recorded? constraint
3. How are time-zone database releases and renamed or linked zone identifiers handled as the registry changes? lifecycle
4. How is the party's habitual zone distinguished from a temporary zone assumed during travel? spatial

Stated contact windows and declared unavailability

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.

1. Which recurring pattern expresses the party's stated contactable periods, and in which time-zone frame is it read? temporal
2. Is time not covered by any declared window contactable or not contactable by default? decision
3. How is a single-occurrence exception expressed without rewriting the underlying pattern? exception
4. Does a stated window assert anything about the party's actual calendar availability at that time? definition
5. What granularity and minimum duration make a stated window meaningful for routing? measurement

Attempt order and fallback sequence

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.

1. How is a total order derived when several candidate options carry equal or absent preference values? decision
2. Which condition moves routing to the next option in the sequence, and which component evaluates that condition? process
3. Has the party stated a maximum number of attempts or a minimum interval between them? constraint
4. How does the fallback sequence change with purpose class and urgency tier? relationship

Urgency tiering and escalation preference

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.

1. Which urgency tiers are recognised for this profile, and against which vocabulary are they defined? classification
2. Which of the party's own statements may an urgency tier override, and which may it never override? authority
3. Which requesting roles are permitted to assert the highest urgency tier on an outbound request? access
4. Has life-safety routing been declared for this party, and how is its absence interpreted? state
5. What is the outcome when a high urgency tier meets an active external communication restriction? constraint

Delegation and alternate-contact designation

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.

1. Which party is designated as delegate or alternate, and by which reference into the party model? identity
2. Which registered relation type qualifies the designation, and from which registry is it drawn? interoperability
3. For which purpose classes and urgency tiers is the designation valid, and does it replace or supplement contacting the party? composition
4. What authority supports the designation, and where is that evidence held? evidence
5. When does the designation lapse, and what happens to routing already in flight at that moment? lifecycle

Effective intervals and temporary overrides

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.

1. What effective interval bounds this statement, and what does an open-ended end mean? temporal
2. How does a temporary override supersede a standing statement without deleting it? state
3. Is there a maximum permitted duration for a temporary override, and what happens at expiry? lifecycle
4. Which statement applies at an instant when several overrides are effective at once? decision
5. How long is a superseded statement retained so that a past outcome remains explainable? retention

Precedence and conflict-resolution rules

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.

1. In which order are overlapping statements and external inputs combined into a single effective disposition? process
2. Which input may only narrow the result, and which input blocks an option outright? constraint
3. What must be returned when the external communication-restriction reference cannot be resolved at evaluation time? exception
4. How is a genuine contradiction between two statements of equal precedence surfaced rather than silently resolved? validation
5. Which edition of the precedence ruleset produced a given resolution, and how is that recorded on the result? provenance

Provenance, authority and assurance of a preference statement

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.

1. Who asserted this preference, the party or an authorised steward, and under what authority did they act? ownership
2. Through which capture channel was the statement made, and what assurance level does that channel carry? evidence
3. How are the instant of statement and the instant of recording represented when they differ? temporal
4. Which statements may an operator alter on the party's behalf, and what must be recorded when they do? authority
5. How does the advisory resolver treat a statement whose provenance or assurance is weak? quality

Authority to assert or change a contact point

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.

1. On what recorded mandate may an agent other than the data subject assert or change this contact point? authority
2. How is a self-asserted change by the data subject distinguished from a steward-asserted or system-derived change? provenance
3. Which contact-point operations does the mandate permit and which does it explicitly exclude? constraint
4. When does the asserting mandate lapse, and what happens to in-force assertions made under it once it does? lifecycle
5. Which external authorisation model renders the allow or deny decision, and what decision reference is retained here? decision

Ownership, stewardship and custodial roles

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.

1. Which system of record is authoritative for this contact point, and which systems hold non-authoritative copies? ownership
2. Which named steward role is accountable for the accuracy and currency of this contact point? ownership
3. Which party acts as controller and which as processor for this contact point, and does that differ by purpose? relationship
4. How is a change of owning system or steward recorded without losing the prior chain of responsibility? provenance

Provenance of each contact-point assertion

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.

1. Which activity generated this contact-point value, and from what upstream entity was it derived? provenance
2. What are the separate event time, observation time and record-ingestion time for this assertion? temporal
3. To which responsible agent is the assertion attributed, and with what qualification? evidence
4. What reliability grade is attached to the originating source, and how was that grade derived? quality

Proof that an endpoint is controlled

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.

1. By what method and at what assurance was control of this endpoint demonstrated? evidence
2. When did the successful verification occur, and when does the verification state expire or require renewal? temporal
3. What must never be persisted in this model from the verification exchange? security
4. How are failed, abandoned or replayed verification attempts represented without leaking attempt detail? exception
5. How is verified control kept distinct from lawful permission to contact the endpoint? constraint

Linkage to consent, legal basis and communication restrictions

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.

1. Which external consent or legal-basis record authorises use of this endpoint for a named purpose? relationship
2. At what granularity does a permission bind: party, endpoint, channel, purpose or campaign class? composition
3. Which restriction, objection or suppression entries currently block use of this endpoint, and who owns them? constraint
4. How does this model detect that a referenced permission has been withdrawn, expired or superseded? event
5. What consent detail must never be copied into this model? privacy

Lifecycle states, effective dating and record versioning

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.

1. What is the closed set of lifecycle states for a contact point, and which transitions between them are permitted? state
2. Over what real-world interval is this contact point asserted to be valid, independent of when the record was written? temporal
3. How is record-time history preserved when a value is corrected rather than genuinely changed? lifecycle
4. What opaque version token identifies the current revision for optimistic concurrency? identity
5. When one contact point supersedes another, how is the predecessor kept resolvable? relationship

Validation, canonical normalisation and cross-source reconciliation

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.

1. Which syntactic and referential validations must a candidate endpoint pass before it can reach the active state? validation
2. What canonical normalised form is stored for matching, and is the original input preserved verbatim? quality
3. What matching rule and threshold decide that two contact points denote the same endpoint? measurement
4. When sources conflict, which value survives and on what recorded justification? decision
5. How can an incorrect merge be reversed without destroying either original assertion? exception

Staleness decay, endpoint reassignment and compromise handling

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.

1. Which observable signals reduce confidence that an endpoint still reaches the intended party? quality
2. At what age or consecutive-failure count must an endpoint be re-verified or suspended? measurement
3. How is a jurisdiction-specific reassignment check recorded, including the reference date used for the query? temporal
4. When an endpoint is reported compromised or misdirected, what immediate state change is applied here and what is delegated? exception

Sensitivity classification and minimisation of held contact data

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.

1. What sensitivity classification applies to this contact point, and what drives that classification? classification
2. Which purpose makes each stored field necessary, and which fields must be dropped when that purpose ends? requirement
3. How is an at-risk or protected endpoint flagged so that it is never disclosed or printed by default? privacy
4. Which contact attributes could reveal special-category or otherwise protected information by inference? privacy

Field- and purpose-scoped disclosure, redaction and export

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.

1. Which fields are released to a requester operating under a stated purpose and role? access
2. How are withheld values represented: omitted, masked, tokenised or replaced by a proxy endpoint? security
3. What must a subject-facing export contain, and which governance fields are excluded from it? interoperability
4. How is a partial or refused disclosure communicated so the requester can act without learning what was hidden? exception

Retention, erasure and tombstoning of contact records

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.

1. Which retention schedule or disposition authority sets the keeping period for this contact point? retention
2. When erasure is required, is the value destroyed, anonymised or suppressed, and what evidence of the action is kept? retention
3. What tombstone remains after deletion so that inbound references resolve without re-exposing the endpoint? constraint
4. How is a conflict between an erasure request and a legal hold or statutory retention duty resolved and recorded? exception
5. Which recipients must be told of a rectification or erasure, and how is that notification evidenced? process

Canonical service rules for read, add, edit, delete and export

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.

1. What preconditions must hold before a write to a contact point is accepted? process
2. How is a lost update prevented when two agents edit the same profile concurrently? constraint
3. How is a retried create or delete recognised as the same logical request? requirement
4. What patch semantics apply to partial edits, and how are they made all-or-nothing? process
5. What audit reference must every accepted mutation return, and who stores the audit entry? evidence

Interoperability mappings and conformance limits

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.

1. Which external contact vocabularies are mapped, at what version, and in which direction? interoperability
2. Which governed fields have no equivalent in the target vocabulary, and how are they carried? interoperability
3. Where do external vocabularies disagree with this model's semantics, and how is the conflict recorded rather than hidden? constraint
4. What evidence supports any conformance claim, and where is the relationship limited to alignment only? evidence